Thanks to the new interface combinations code we can safely remove all the
driver specific checks for unsupported modes.
Signed-off-by: Antonio Quartulli <[email protected]>
---
this patch if v2 of "ath9k_htc: allow coexistence of IBSS with other modes". Now
it is more generic.
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 20 --------------------
1 file changed, 20 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
index c32f6e3..51c69f2 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -1040,26 +1040,6 @@ static int ath9k_htc_add_interface(struct ieee80211_hw *hw,
mutex_lock(&priv->mutex);
- if (priv->nvifs >= ATH9K_HTC_MAX_VIF) {
- mutex_unlock(&priv->mutex);
- return -ENOBUFS;
- }
-
- if (priv->num_ibss_vif ||
- (priv->nvifs && vif->type == NL80211_IFTYPE_ADHOC)) {
- ath_err(common, "IBSS coexistence with other modes is not allowed\n");
- mutex_unlock(&priv->mutex);
- return -ENOBUFS;
- }
-
- if (((vif->type == NL80211_IFTYPE_AP) ||
- (vif->type == NL80211_IFTYPE_ADHOC)) &&
- ((priv->num_ap_vif + priv->num_ibss_vif) >= ATH9K_HTC_MAX_BCN_VIF)) {
- ath_err(common, "Max. number of beaconing interfaces reached\n");
- mutex_unlock(&priv->mutex);
- return -ENOBUFS;
- }
-
ath9k_htc_ps_wakeup(priv);
memset(&hvif, 0, sizeof(struct ath9k_htc_target_vif));
memcpy(&hvif.myaddr, vif->addr, ETH_ALEN);
--
1.7.12
Hi,
On Mon, Aug 27, 2012 at 2:25 AM, Antonio Quartulli <[email protected]> wrote:
> Thanks to the new interface combinations code we can safely remove all the
> driver specific checks for unsupported modes.
i had just sent this some time back
http://permalink.gmane.org/gmane.linux.kernel.wireless.general/96443.
please review if something had to be changed.
>
> Signed-off-by: Antonio Quartulli <[email protected]>
> ---
>
> this patch if v2 of "ath9k_htc: allow coexistence of IBSS with other modes". Now
> it is more generic.
>
>
>
> drivers/net/wireless/ath/ath9k/htc_drv_main.c | 20 --------------------
> 1 file changed, 20 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
> index c32f6e3..51c69f2 100644
> --- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
> +++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
> @@ -1040,26 +1040,6 @@ static int ath9k_htc_add_interface(struct ieee80211_hw *hw,
>
> mutex_lock(&priv->mutex);
>
> - if (priv->nvifs >= ATH9K_HTC_MAX_VIF) {
> - mutex_unlock(&priv->mutex);
> - return -ENOBUFS;
> - }
> -
> - if (priv->num_ibss_vif ||
> - (priv->nvifs && vif->type == NL80211_IFTYPE_ADHOC)) {
> - ath_err(common, "IBSS coexistence with other modes is not allowed\n");
> - mutex_unlock(&priv->mutex);
> - return -ENOBUFS;
> - }
> -
> - if (((vif->type == NL80211_IFTYPE_AP) ||
> - (vif->type == NL80211_IFTYPE_ADHOC)) &&
> - ((priv->num_ap_vif + priv->num_ibss_vif) >= ATH9K_HTC_MAX_BCN_VIF)) {
> - ath_err(common, "Max. number of beaconing interfaces reached\n");
> - mutex_unlock(&priv->mutex);
> - return -ENOBUFS;
> - }
> -
> ath9k_htc_ps_wakeup(priv);
> memset(&hvif, 0, sizeof(struct ath9k_htc_target_vif));
> memcpy(&hvif.myaddr, vif->addr, ETH_ALEN);
> --
> 1.7.12
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
thanks,
shafi
Hi Antonio,
>
> On Mon, Aug 27, 2012 at 10:47:29 +0530, Mohammed Shafi wrote:
>> Hi,
>>
>> On Mon, Aug 27, 2012 at 2:25 AM, Antonio Quartulli <[email protected]> wrote:
>> > Thanks to the new interface combinations code we can safely remove all the
>> > driver specific checks for unsupported modes.
>>
>> i had just sent this some time back
>> http://permalink.gmane.org/gmane.linux.kernel.wireless.general/96443.
>>
>> please review if something had to be changed.
>>
>
> Sorry, but I hadn't seen your patch. Otherwise I would have not sent mine.
no issues :-)
>
> Your patch is ok. But, at this point, should patch 2/6 and 3/6 be merged
> together?
an order of interface combinations advertisement(2/6), followed by
removing specific
checks should be fine right ?
>
> Other than that, patch 2/6 should be modified to take into account IBSS mode.
yeah saw your patch, that in ath9k_htc IBSS interface can coexist with
one more interface.
The standalone limitation exists in ath9k too, not sure this is a
limitation to beacon config
for ath9k & ath9k_htc, I will just confirm. If its fine i will resend
the v2 version signing off both
of our names accounting IBSS mode too.
>
>
> Cheers,
>
>
> --
> Antonio Quartulli
>
> ..each of us alone is worth nothing..
> Ernesto "Che" Guevara
--
thanks,
shafi
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
> <[email protected]> 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 <[email protected]> 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,
--
Antonio Quartulli
..each of us alone is worth nothing..
Ernesto "Che" Guevara
Antonio,
On Mon, Aug 27, 2012 at 6:55 AM, Antonio Quartulli <[email protected]> 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,
--
Julian Calaby
Email: [email protected]
Profile: http://www.google.com/profiles/julian.calaby/
.Plan: http://sites.google.com/site/juliancalaby/
On Mon, 2012-08-27 at 09:48 +1000, Julian Calaby wrote:
> Antonio,
>
> On Mon, Aug 27, 2012 at 6:55 AM, Antonio Quartulli <[email protected]> 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
Hi Mohammed,
On Mon, Aug 27, 2012 at 10:47:29 +0530, Mohammed Shafi wrote:
> Hi,
>
> On Mon, Aug 27, 2012 at 2:25 AM, Antonio Quartulli <[email protected]> wrote:
> > Thanks to the new interface combinations code we can safely remove all the
> > driver specific checks for unsupported modes.
>
> i had just sent this some time back
> http://permalink.gmane.org/gmane.linux.kernel.wireless.general/96443.
>
> please review if something had to be changed.
>
Sorry, but I hadn't seen your patch. Otherwise I would have not sent mine.
Your patch is ok. But, at this point, should patch 2/6 and 3/6 be merged
together?
Other than that, patch 2/6 should be modified to take into account IBSS mode.
Cheers,
--
Antonio Quartulli
..each of us alone is worth nothing..
Ernesto "Che" Guevara
Hi Antonio,
On Mon, Aug 27, 2012 at 4:42 PM, Antonio Quartulli <[email protected]> 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
>> <[email protected]> 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 <[email protected]> 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,
--
Julian Calaby
Email: [email protected]
Profile: http://www.google.com/profiles/julian.calaby/
.Plan: http://sites.google.com/site/juliancalaby/
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 <[email protected]>
---
drivers/net/wireless/ath/ath9k/htc_drv_init.c | 30 +++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
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 |
--
1.7.12
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
Hi Mohammed,
On Mon, Aug 27, 2012 at 02:45:36 +0530, Mohammed Shafi wrote:
> Hi Antonio,
>
> > Your patch is ok. But, at this point, should patch 2/6 and 3/6 be merged
> > together?
>
> an order of interface combinations advertisement(2/6), followed by
> removing specific
> checks should be fine right ?
In my opinion this is correct. But maybe Johannes has some arguments against this
order?
>
> >
> > Other than that, patch 2/6 should be modified to take into account IBSS mode.
>
> yeah saw your patch, that in ath9k_htc IBSS interface can coexist with
> one more interface.
> The standalone limitation exists in ath9k too, not sure this is a
> limitation to beacon config
> for ath9k & ath9k_htc, I will just confirm. If its fine i will resend
> the v2 version signing off both
> of our names accounting IBSS mode too.
fine with me :) Thank you!
--
Antonio Quartulli
..each of us alone is worth nothing..
Ernesto "Che" Guevara
Hi Johannes,
On Mon, Aug 27, 2012 at 3:38 PM, Johannes Berg
<[email protected]> 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 <[email protected]> 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,
--
Julian Calaby
Email: [email protected]
Profile: http://www.google.com/profiles/julian.calaby/
.Plan: http://sites.google.com/site/juliancalaby/
Hi Antonio,
>> Other than that, patch 2/6 should be modified to take into account IBSS mode.
>
> yeah saw your patch, that in ath9k_htc IBSS interface can coexist with
> one more interface.
sorry for the delayed response(almost tortoise's pace :) ), the
ath9k_htc maintainer said
TSF sync may be an issue if we have IBSS interface coexistence, any
thoughts about this (or)
this should be fine based on your testing. please let me know!
--
thanks,
shafi
On Mon, Sep 03, 2012 at 07:31:34PM +0530, Mohammed Shafi wrote:
> Hi Antonio,
>
> >> Other than that, patch 2/6 should be modified to take into account IBSS mode.
> >
> > yeah saw your patch, that in ath9k_htc IBSS interface can coexist with
> > one more interface.
>
> sorry for the delayed response(almost tortoise's pace :) ),
no worries :):)
> the
> ath9k_htc maintainer said
> TSF sync may be an issue if we have IBSS interface coexistence, any
> thoughts about this (or)
> this should be fine based on your testing. please let me know!
>
Well, during my test I didn't hit any problem, but since the ath9k_htc
maintainer has much more experience then me I will perform a more stressful test
and see what happens. I'll let you know!
Thanks,
--
Antonio Quartulli
..each of us alone is worth nothing..
Ernesto "Che" Guevara
Hi Antonio,
>
>> the
>> ath9k_htc maintainer said
>> TSF sync may be an issue if we have IBSS interface coexistence, any
>> thoughts about this (or)
>> this should be fine based on your testing. please let me know!
>>
>
> Well, during my test I didn't hit any problem, but since the ath9k_htc
> maintainer has much more experience then me I will perform a more stressful test
> and see what happens. I'll let you know!
sure, thanks a lot!
>
> Thanks,
>
>
>
> --
> Antonio Quartulli
>
> ..each of us alone is worth nothing..
> Ernesto "Che" Guevara
--
thanks,
shafi
On 27 August 2012 00:16, Daniel Doron <[email protected]> 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