Message ID | 1346014505-7554-2-git-send-email-ordex@autistici.org (mailing list archive) |
---|---|
State | Not Applicable, archived |
Headers | show |
Antonio, On Mon, Aug 27, 2012 at 6:55 AM, Antonio Quartulli <ordex@autistici.org> wrote: > This driver now advertises its allowed VIFs combinations to the mac80211 > sublayer. > > Other than that, practical tests shown that ath9k_htc devices allow an IBSS VIF > to coexist with VIF set up on other modes. This patch removes the check which > block the creation of any other VIF whenever an IBSS one is already present. These two patches should really be applied in the opposite order: You should add the interface combination data (this patch) then remove the old checking code. This way there's not a window (admittedly only one patch) where the interface combinations aren't enforced. Thanks,
On Mon, 2012-08-27 at 09:48 +1000, Julian Calaby wrote: > Antonio, > > On Mon, Aug 27, 2012 at 6:55 AM, Antonio Quartulli <ordex@autistici.org> wrote: > > This driver now advertises its allowed VIFs combinations to the mac80211 > > sublayer. > > > > Other than that, practical tests shown that ath9k_htc devices allow an IBSS VIF > > to coexist with VIF set up on other modes. This patch removes the check which > > block the creation of any other VIF whenever an IBSS one is already present. > > These two patches should really be applied in the opposite order: > > You should add the interface combination data (this patch) then remove > the old checking code. > > This way there's not a window (admittedly only one patch) where the > interface combinations aren't enforced. FWIW, it's the other way around, in that window no combinations would be permitted at all... johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Johannes, On Mon, Aug 27, 2012 at 3:38 PM, Johannes Berg <johannes@sipsolutions.net> wrote: > On Mon, 2012-08-27 at 09:48 +1000, Julian Calaby wrote: >> Antonio, >> >> On Mon, Aug 27, 2012 at 6:55 AM, Antonio Quartulli <ordex@autistici.org> wrote: >> > This driver now advertises its allowed VIFs combinations to the mac80211 >> > sublayer. >> > >> > Other than that, practical tests shown that ath9k_htc devices allow an IBSS VIF >> > to coexist with VIF set up on other modes. This patch removes the check which >> > block the creation of any other VIF whenever an IBSS one is already present. >> >> These two patches should really be applied in the opposite order: >> >> You should add the interface combination data (this patch) then remove >> the old checking code. >> >> This way there's not a window (admittedly only one patch) where the >> interface combinations aren't enforced. > > FWIW, it's the other way around, in that window no combinations would be > permitted at all... It's still a problem for bisection then =) Thanks,
On Mon, Aug 27, 2012 at 03:41:09 +1000, Julian Calaby wrote: > Hi Johannes, > > On Mon, Aug 27, 2012 at 3:38 PM, Johannes Berg > <johannes@sipsolutions.net> wrote: > > On Mon, 2012-08-27 at 09:48 +1000, Julian Calaby wrote: > >> Antonio, > >> > >> On Mon, Aug 27, 2012 at 6:55 AM, Antonio Quartulli <ordex@autistici.org> wrote: > >> > This driver now advertises its allowed VIFs combinations to the mac80211 > >> > sublayer. > >> > > >> > Other than that, practical tests shown that ath9k_htc devices allow an IBSS VIF > >> > to coexist with VIF set up on other modes. This patch removes the check which > >> > block the creation of any other VIF whenever an IBSS one is already present. > >> > >> These two patches should really be applied in the opposite order: > >> > >> You should add the interface combination data (this patch) then remove > >> the old checking code. > >> > >> This way there's not a window (admittedly only one patch) where the > >> interface combinations aren't enforced. > > > > FWIW, it's the other way around, in that window no combinations would be > > permitted at all... > > It's still a problem for bisection then =) Shall I merge the two patches and do both the changes in one shot? Cheers,
Hi Antonio, On Mon, Aug 27, 2012 at 4:42 PM, Antonio Quartulli <ordex@autistici.org> wrote: > On Mon, Aug 27, 2012 at 03:41:09 +1000, Julian Calaby wrote: >> Hi Johannes, >> >> On Mon, Aug 27, 2012 at 3:38 PM, Johannes Berg >> <johannes@sipsolutions.net> wrote: >> > On Mon, 2012-08-27 at 09:48 +1000, Julian Calaby wrote: >> >> Antonio, >> >> >> >> On Mon, Aug 27, 2012 at 6:55 AM, Antonio Quartulli <ordex@autistici.org> wrote: >> >> > This driver now advertises its allowed VIFs combinations to the mac80211 >> >> > sublayer. >> >> > >> >> > Other than that, practical tests shown that ath9k_htc devices allow an IBSS VIF >> >> > to coexist with VIF set up on other modes. This patch removes the check which >> >> > block the creation of any other VIF whenever an IBSS one is already present. >> >> >> >> These two patches should really be applied in the opposite order: >> >> >> >> You should add the interface combination data (this patch) then remove >> >> the old checking code. >> >> >> >> This way there's not a window (admittedly only one patch) where the >> >> interface combinations aren't enforced. >> > >> > FWIW, it's the other way around, in that window no combinations would be >> > permitted at all... >> >> It's still a problem for bisection then =) > > Shall I merge the two patches and do both the changes in one shot? You might as well, however you should address Mohammed's comment first. Thanks,
Hi, Newbie question: what is the reason for the limitation of the number of VIFs and their combination that is allowed? Is this a s/w limitation or h/w limitation? Best regards, Daniel Doron Customer Support & FAE Manager Connect One 20 Atir Yeda st. Kfar Saba 44643 Israel Phone: 972-9-7660456 x138 Mobile: 972-54-4959659 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 27 August 2012 00:16, Daniel Doron <danield@connectone.com> wrote: > Hi, > > Newbie question: what is the reason for the limitation of the number of VIFs > and their combination that is allowed? Is this a s/w limitation or h/w > limitation? Short answer: yes. Long answer: there's limited RAM resources on the USB CPU and there's some per-STA state being kept. Sujith knows the details better, I've stayed out of ath9k_htc internals to date. :) Adrian -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_init.c b/drivers/net/wireless/ath/ath9k/htc_drv_init.c index a035a38..6aa2af4 100644 --- a/drivers/net/wireless/ath/ath9k/htc_drv_init.c +++ b/drivers/net/wireless/ath/ath9k/htc_drv_init.c @@ -689,6 +689,33 @@ err_hw: return ret; } +/* it is possible to have at most ATH9K_HTC_MAX_BCN_VIF beaconing interfaces, + * therefore either we have 1 IBSS + ATH9K_HTC_MAX_BCN_VIF - 1 APs, or we have + * only ATH9K_HTC_MAX_BCN_VIF APs */ +static const struct ieee80211_iface_limit if_limits_ibss[] = { + { .max = ATH9K_HTC_MAX_VIF, .types = BIT(NL80211_IFTYPE_STATION) }, + { .max = ATH9K_HTC_MAX_BCN_VIF - 1, .types = BIT(NL80211_IFTYPE_AP) }, + { .max = 1, .types = BIT(NL80211_IFTYPE_ADHOC) }, +}; + +static const struct ieee80211_iface_limit if_limits_noibss[] = { + { .max = ATH9K_HTC_MAX_VIF, .types = BIT(NL80211_IFTYPE_STATION) }, + { .max = ATH9K_HTC_MAX_BCN_VIF, .types = BIT(NL80211_IFTYPE_AP) }, +}; + +static const struct ieee80211_iface_combination if_comb[] = { + { .limits = if_limits_ibss, + .n_limits = ARRAY_SIZE(if_limits_ibss), + .max_interfaces = ATH9K_HTC_MAX_VIF, + .num_different_channels = 1, + }, + { .limits = if_limits_noibss, + .n_limits = ARRAY_SIZE(if_limits_noibss), + .max_interfaces = ATH9K_HTC_MAX_VIF, + .num_different_channels = 1, + }, +}; + static void ath9k_set_hw_capab(struct ath9k_htc_priv *priv, struct ieee80211_hw *hw) { @@ -711,6 +738,9 @@ static void ath9k_set_hw_capab(struct ath9k_htc_priv *priv, BIT(NL80211_IFTYPE_P2P_GO) | BIT(NL80211_IFTYPE_P2P_CLIENT); + hw->wiphy->iface_combinations = if_comb; + hw->wiphy->n_iface_combinations = ARRAY_SIZE(if_comb); + hw->wiphy->flags &= ~WIPHY_FLAG_PS_ON_BY_DEFAULT; hw->wiphy->flags |= WIPHY_FLAG_IBSS_RSN |
This driver now advertises its allowed VIFs combinations to the mac80211 sublayer. Other than that, practical tests shown that ath9k_htc devices allow an IBSS VIF to coexist with VIF set up on other modes. This patch removes the check which block the creation of any other VIF whenever an IBSS one is already present. Signed-off-by: Antonio Quartulli <ordex@autistici.org> --- drivers/net/wireless/ath/ath9k/htc_drv_init.c | 30 +++++++++++++++++++++++++++ 1 file changed, 30 insertions(+)