diff mbox

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

Message ID 1346014505-7554-2-git-send-email-ordex@autistici.org (mailing list archive)
State Not Applicable, archived
Headers show

Commit Message

Antonio Quartulli Aug. 26, 2012, 8:55 p.m. UTC
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(+)

Comments

Julian Calaby Aug. 26, 2012, 11:48 p.m. UTC | #1
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,
Johannes Berg Aug. 27, 2012, 5:38 a.m. UTC | #2
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
Julian Calaby Aug. 27, 2012, 5:41 a.m. UTC | #3
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,
Antonio Quartulli Aug. 27, 2012, 6:42 a.m. UTC | #4
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,
Julian Calaby Aug. 27, 2012, 6:45 a.m. UTC | #5
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,
Daniel Doron Aug. 27, 2012, 7:16 a.m. UTC | #6
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
Adrian Chadd Sept. 26, 2012, 8:11 p.m. UTC | #7
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 mbox

Patch

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 |