[RFC 1/2] ath9k_htc: Advertize allowed vif combinations

[RFC 1/2] ath9k_htc: Advertize allowed vif combinations

[Mohammed Shafi Shajakhan]

From: Antonio Quartulli <ordex@autistici.org>

Advertize allowed VIFs combinations to the cfg80211 sublayer.
Other than that, practical tests shown that ath9k_htc devices allow an
IBSS VIF to coexist with VIF set up on other modes, so advertize
that to. We can also further add p2p/mesh mode to be advertized
in the combinations allowed.

Signed-off-by: Antonio Quartulli <ordex@autistici.org>
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
---
 drivers/net/wireless/ath/ath9k/htc_drv_init.c |   35 +++++++++++++++++++++++++
 1 files changed, 35 insertions(+), 0 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_init.c b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
index d98255e..4d65af1 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_init.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
@@ -694,6 +694,38 @@ err_hw:
 	return ret;
 }
 
+/*
+ * It is possible to have atmost ATH9K_HTC_MAX_BCN_VIF beaconing interfaces
+ * therefore either we have 1 IBSS + ATH9K_HTC_MAX_BCN_VIF - 1 AP's, or we
+ * have only ATH9K_HTC_MAX_BCN_VIF AP's
+ */
+
+static const struct ieee80211_iface_limit if_limits_ibss[] = {
+	{.max = ATH9K_HTC_MAX_VIF, .types = BIT(NL80211_IFTYPE_STATION)},
+	{.max = ATH9K_HTC_MAX_VIF - 1, .types = BIT(NL80211_IFTYPE_AP)},
+	{.max = 1, .types = BIT(NL80211_IFTYPE_ADHOC)},
+};
+
+static const struct ieee80211_iface_limit if_limits_no_ibss[] = {
+	{.max = ATH9K_HTC_MAX_VIF, .types = BIT(NL80211_IFTYPE_STATION)},
+	{.max = ATH9K_HTC_MAX_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,
+	 .beacon_int_infra_match = true,
+	},
+	{.limits = if_limits_no_ibss,
+	 .n_limits = ARRAY_SIZE(if_limits_no_ibss),
+	 .max_interfaces = ATH9K_HTC_MAX_VIF,
+	 .num_different_channels = 1,
+	 .beacon_int_infra_match = true,
+	},
+};
+
 static void ath9k_set_hw_capab(struct ath9k_htc_priv *priv,
 			       struct ieee80211_hw *hw)
 {
@@ -716,6 +748,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.0.4

[RFC 2/2] ath9k_htc: Remove interface combination specific checks

[Mohammed Shafi Shajakhan]

From: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>

Once the driver advertizes interface combination logic
based on its firmware/hardware limitation, cfg80211
takes care of all the necessary logic such as maximum
beaconing vifs, standlone interface etc.

Signed-off-by: Antonio Quartulli <ordex@autistici.org>
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
---
 drivers/net/wireless/ath/ath9k/htc_drv_main.c |   20 --------------------
 1 files changed, 0 insertions(+), 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 ca78e33..66f6a74 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -1036,26 +1036,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.0.4

Re: [RFC 1/2] ath9k_htc: Advertize allowed vif combinations

[Mohammed Shafi Shajakhan]

On Thursday 27 September 2012 09:22 PM, Mohammed Shafi Shajakhan wrote:
> From: Antonio Quartulli <ordex@autistici.org>
>
> Advertize allowed VIFs combinations to the cfg80211 sublayer.
> Other than that, practical tests shown that ath9k_htc devices allow an
> IBSS VIF to coexist with VIF set up on other modes, so advertize
> that to. We can also further add p2p/mesh mode to be advertized
> in the combinations allowed.

Antonio tomorrow evening i will just do a sanity test and send these
stuff as patch. thank you so much for your patience!

>
> Signed-off-by: Antonio Quartulli <ordex@autistici.org>
> Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
> ---
>   drivers/net/wireless/ath/ath9k/htc_drv_init.c |   35 +++++++++++++++++++++++++
>   1 files changed, 35 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_init.c b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
> index d98255e..4d65af1 100644
> --- a/drivers/net/wireless/ath/ath9k/htc_drv_init.c
> +++ b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
> @@ -694,6 +694,38 @@ err_hw:
>   	return ret;
>   }
>
> +/*
> + * It is possible to have atmost ATH9K_HTC_MAX_BCN_VIF beaconing interfaces
> + * therefore either we have 1 IBSS + ATH9K_HTC_MAX_BCN_VIF - 1 AP's, or we
> + * have only ATH9K_HTC_MAX_BCN_VIF AP's
> + */
> +
> +static const struct ieee80211_iface_limit if_limits_ibss[] = {
> +	{.max = ATH9K_HTC_MAX_VIF, .types = BIT(NL80211_IFTYPE_STATION)},
> +	{.max = ATH9K_HTC_MAX_VIF - 1, .types = BIT(NL80211_IFTYPE_AP)},
> +	{.max = 1, .types = BIT(NL80211_IFTYPE_ADHOC)},
> +};
> +
> +static const struct ieee80211_iface_limit if_limits_no_ibss[] = {
> +	{.max = ATH9K_HTC_MAX_VIF, .types = BIT(NL80211_IFTYPE_STATION)},
> +	{.max = ATH9K_HTC_MAX_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,
> +	 .beacon_int_infra_match = true,
> +	},
> +	{.limits = if_limits_no_ibss,
> +	 .n_limits = ARRAY_SIZE(if_limits_no_ibss),
> +	 .max_interfaces = ATH9K_HTC_MAX_VIF,
> +	 .num_different_channels = 1,
> +	 .beacon_int_infra_match = true,
> +	},
> +};
> +
>   static void ath9k_set_hw_capab(struct ath9k_htc_priv *priv,
>   			       struct ieee80211_hw *hw)
>   {
> @@ -716,6 +748,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 |
>


-- 
thanks,
shafi

Re: [RFC 1/2] ath9k_htc: Advertize allowed vif combinations

[Antonio Quartulli]

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

On Thu, Sep 27, 2012 at 09:23:35PM +0530, Mohammed Shafi Shajakhan wrote:
> On Thursday 27 September 2012 09:22 PM, Mohammed Shafi Shajakhan wrote:
> > From: Antonio Quartulli <ordex@autistici.org>
> >
> > Advertize allowed VIFs combinations to the cfg80211 sublayer.
> > Other than that, practical tests shown that ath9k_htc devices allow an
> > IBSS VIF to coexist with VIF set up on other modes, so advertize
> > that to. We can also further add p2p/mesh mode to be advertized
> > in the combinations allowed.
> 
> Antonio tomorrow evening i will just do a sanity test and send these
> stuff as patch. thank you so much for your patience!

Mohammed, great! Thank you for your rework!

Cheers,

-- 
Antonio Quartulli

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

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

[RFC 1/2] ath9k_htc: Advertize allowed vif combinations

[Sujith Manoharan]

Mohammed Shafi Shajakhan wrote:
> From: Antonio Quartulli <ordex@autistici.org>
> 
> Advertize allowed VIFs combinations to the cfg80211 sublayer.
> Other than that, practical tests shown that ath9k_htc devices allow an
> IBSS VIF to coexist with VIF set up on other modes, so advertize
> that to. We can also further add p2p/mesh mode to be advertized
> in the combinations allowed.

I don't think IBSS can co-exist with other op-modes.

Sujith

Re: [RFC 1/2] ath9k_htc: Advertize allowed vif combinations

[Mohammed Shafi Shajakhan]

Hi Sujith,

On Friday 28 September 2012 07:53 AM, Sujith Manoharan wrote:
> Mohammed Shafi Shajakhan wrote:
>> From: Antonio Quartulli <ordex@autistici.org>
>>
>> Advertize allowed VIFs combinations to the cfg80211 sublayer.
>> Other than that, practical tests shown that ath9k_htc devices allow an
>> IBSS VIF to coexist with VIF set up on other modes, so advertize
>> that to. We can also further add p2p/mesh mode to be advertized
>> in the combinations allowed.
>
> I don't think IBSS can co-exist with other op-modes.
>

oh yeah, you are saying that we will have some issues with IBSS
coexistence with other modes because of TSF sync.

Antonio seems to be testing this sometime back and came up with the 
following observation :

"ath9k_htc is running since some hours with AP+IBSS without any 
problems.What I think that the maintainer was referring to is a general 
problem of IBSS+AP: in most devices, TFS is unique among VIFs, therefore 
TSF jumps introduced by IBSS can be reflected in a bad way on the AP VIF".

please let us know if you have further thoughts about this.
I will just look into the code if we have some more limitations.
thanks for your review!

-- 
thanks,
shafi

Re: [RFC 1/2] ath9k_htc: Advertize allowed vif combinations

[Sujith Manoharan]

Mohammed Shafi Shajakhan wrote:
> oh yeah, you are saying that we will have some issues with IBSS
> coexistence with other modes because of TSF sync.

Yes, this is a problem.

Sujith

Re: [RFC 1/2] ath9k_htc: Advertize allowed vif combinations

[Antonio Quartulli]

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

On Fri, Sep 28, 2012 at 04:12:40 +0530, Sujith Manoharan wrote:
> Mohammed Shafi Shajakhan wrote:
> > oh yeah, you are saying that we will have some issues with IBSS
> > coexistence with other modes because of TSF sync.
> 
> Yes, this is a problem.

Is there anyway to overcome this problem? Can we bind the single TSF to multiple
virtualTSF? or must the device somehow support us?

Cheers,


-- 
Antonio Quartulli

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

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

Re: [RFC 1/2] ath9k_htc: Advertize allowed vif combinations

[Adrian Chadd]

On 29 September 2012 02:31, Antonio Quartulli <ordex@autistici.org> wrote:
> On Fri, Sep 28, 2012 at 04:12:40 +0530, Sujith Manoharan wrote:
>> Mohammed Shafi Shajakhan wrote:
>> > oh yeah, you are saying that we will have some issues with IBSS
>> > coexistence with other modes because of TSF sync.
>>
>> Yes, this is a problem.
>
> Is there anyway to overcome this problem? Can we bind the single TSF to multiple
> virtualTSF? or must the device somehow support us?

Just total conjecture here, but the problem with TSF mangaement and
multiple VIFs will likely show up the most when you start doing NIC
power save operation.

ISTR there's something which causes the NIC to not queue TX frames
around the beacon interval, to let the AP TX. That will likely be
based on around TSF sync.

So sure, you could implement some form of software TSF but it won't
help for the MAC supported stuff like beacon TX and power save / sleep
state handling.



Adrian

Re: [RFC 1/2] ath9k_htc: Advertize allowed vif combinations

[Mohammed Shafi]

On Sat, Sep 29, 2012 at 3:01 PM, Antonio Quartulli <ordex@autistici.org> wrote:
> On Fri, Sep 28, 2012 at 04:12:40 +0530, Sujith Manoharan wrote:
>> Mohammed Shafi Shajakhan wrote:
>> > oh yeah, you are saying that we will have some issues with IBSS
>> > coexistence with other modes because of TSF sync.
>>
>> Yes, this is a problem.
>
> Is there anyway to overcome this problem? Can we bind the single TSF to multiple
> virtualTSF? or must the device somehow support us?

Antonio, agained i checked with the ath9k_htc maintainer, he said the
IBSS coexistence is not
possible. So i would go with my current patch. Please do feel free to
enhance. Currently
i am working in some other project, not sure i would be able to take this up.

>
> Cheers,
>
>
> --
> Antonio Quartulli
>
> ..each of us alone is worth nothing..
> Ernesto "Che" Guevara



-- 
thanks,
shafi

Re: [RFC 1/2] ath9k_htc: Advertize allowed vif combinations

[Antonio Quartulli]

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

On Mon, Oct 08, 2012 at 09:20:38PM +0530, Mohammed Shafi wrote:
> On Sat, Sep 29, 2012 at 3:01 PM, Antonio Quartulli <ordex@autistici.org> wrote:
> > On Fri, Sep 28, 2012 at 04:12:40 +0530, Sujith Manoharan wrote:
> >> Mohammed Shafi Shajakhan wrote:
> >> > oh yeah, you are saying that we will have some issues with IBSS
> >> > coexistence with other modes because of TSF sync.
> >>
> >> Yes, this is a problem.
> >
> > Is there anyway to overcome this problem? Can we bind the single TSF to multiple
> > virtualTSF? or must the device somehow support us?
> 
> Antonio, agained i checked with the ath9k_htc maintainer, he said the
> IBSS coexistence is not
> possible. So i would go with my current patch. Please do feel free to
> enhance. Currently
> i am working in some other project, not sure i would be able to take this up.

Hi Mohammed,

thank you for having taken care of this. Is it possible to have more details
about this "impossibility"? I still have to understand, because on one side we
all agreed on the fact that IBSS+AP coexistence will create problems on the STA
(connected to the AP) because of the TSF jumps, but this would still "work". On
the other side the maintainer is claiming this would not work at all :-) At this
point, I'd like to clearly understand "why" he is claiming so: is it for the
same reason explained above (TSF jumps) or is there something else?

Cheers,


-- 
Antonio Quartulli

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

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

Re: [RFC 1/2] ath9k_htc: Advertize allowed vif combinations

[Mohammed Shafi]

Hi Antonio,

>
> Hi Mohammed,
>
> thank you for having taken care of this. Is it possible to have more details
> about this "impossibility"? I still have to understand, because on one side we
> all agreed on the fact that IBSS+AP coexistence will create problems on the STA
> (connected to the AP) because of the TSF jumps, but this would still "work". On
> the other side the maintainer is claiming this would not work at all :-) At this
> point, I'd like to clearly understand "why" he is claiming so: is it for the
> same reason explained above (TSF jumps) or is there something else?

completely agree with your point, but one thing I am not sure about is
there something
specific with ath9k_htc firmware/ h/w code limitations(beacon.c). I
need to take a close
look at this. I will just check again with the ath9k_htc maintainer(if
I can reach him !).
But if you had tested this better please go ahead and send the patch,
as it wouldn't be
breaking. Since the maintainer himself has better understanding about
ath9k_htc(also its firmware)
he certainly might have a better reason to say so. Certainly ath9k_htc
has some limitations
in firmware and some know issues too!.

I have limited time as i am working in some other project!

>
> Cheers,
>
>
> --
> Antonio Quartulli
>
> ..each of us alone is worth nothing..
> Ernesto "Che" Guevara



-- 
thanks,
shafi