[PATCHv2 1/2] ath9k_htc: remove driver specific checks for interfaces combinations

[PATCHv2 1/2] ath9k_htc: remove driver specific checks for interfaces combinations

[Antonio Quartulli]

Thanks to the new interface combinations code we can safely remove all the
driver specific checks for unsupported modes.

Signed-off-by: Antonio Quartulli <ordex@autistici.org>
---

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

[PATCHv2 2/2] ath9k_htc: advertise allowed VIFs combination

[Antonio Quartulli]

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(+)

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

Re: [PATCHv2 2/2] ath9k_htc: advertise allowed VIFs combination

[Julian Calaby]

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,

-- 
Julian Calaby

Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
.Plan: http://sites.google.com/site/juliancalaby/

Re: [PATCHv2 2/2] ath9k_htc: advertise allowed VIFs combination

[Johannes Berg]

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

Re: [PATCHv2 2/2] ath9k_htc: advertise allowed VIFs combination

[Julian Calaby]

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,

-- 
Julian Calaby

Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
.Plan: http://sites.google.com/site/juliancalaby/

Re: [PATCHv2 2/2] ath9k_htc: advertise allowed VIFs combination

[Antonio Quartulli]

[-- Attachment #1: Type: text/plain, Size: 1349 bytes --]

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,

-- 
Antonio Quartulli

..each of us alone is worth nothing..
Ernesto "Che" Guevara

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [PATCHv2 2/2] ath9k_htc: advertise allowed VIFs combination

[Julian Calaby]

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,

-- 
Julian Calaby

Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
.Plan: http://sites.google.com/site/juliancalaby/

ath9k_htc: number of VIFs limitation

[Daniel Doron]

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

Re: ath9k_htc: number of VIFs limitation

[Adrian Chadd]

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

Re: [PATCHv2 1/2] ath9k_htc: remove driver specific checks for interfaces combinations

[Mohammed Shafi]

Hi,

On Mon, Aug 27, 2012 at 2:25 AM, Antonio Quartulli <ordex@autistici.org> 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 <ordex@autistici.org>
> ---
>
> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
thanks,
shafi

Re: [PATCHv2 1/2] ath9k_htc: remove driver specific checks for interfaces combinations

[Antonio Quartulli]

[-- Attachment #1: Type: text/plain, Size: 828 bytes --]

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 <ordex@autistici.org> 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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [PATCHv2 1/2] ath9k_htc: remove driver specific checks for interfaces combinations

[Mohammed 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 <ordex@autistici.org> 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

Re: [PATCHv2 1/2] ath9k_htc: remove driver specific checks for interfaces combinations

[Antonio Quartulli]

[-- Attachment #1: Type: text/plain, Size: 981 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [PATCHv2 1/2] ath9k_htc: remove driver specific checks for interfaces combinations

[Mohammed Shafi]

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

Re: [PATCHv2 1/2] ath9k_htc: remove driver specific checks for interfaces combinations

[Antonio Quartulli]

[-- Attachment #1: Type: text/plain, Size: 870 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [PATCHv2 1/2] ath9k_htc: remove driver specific checks for interfaces combinations

[Mohammed Shafi]

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