[PATCH v2] ath10k: remove VHT capabilities from 2.4GHz

[PATCH v2] ath10k: remove VHT capabilities from 2.4GHz

[Kalle Valo]

From: Johannes Berg <johannes.berg@intel.com>

According to the spec, VHT doesn't exist in 2.4GHz.

There are vendor extensions to allow a subset of VHT to work
(notably 256-QAM), but since mac80211 doesn't support those
advertising VHT capability on 2.4GHz leads to the behaviour
of reporting VHT capabilities but not being able to use any
of them due to mac80211's code requiring 80 MHz support.

Remove the VHT capabilities from 2.4GHz for now. If mac80211
gets extended to use the (likely Broadcom) vendor IEs for it
and handles the lack of 80 MHz support, it can be added back.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
---

v2:

* Cc ath10k@lists.infradead.org

 drivers/net/wireless/ath/ath10k/mac.c |    3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index bcf025f51310..d2a852805b07 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -4276,9 +4276,6 @@ static void ath10k_mac_setup_ht_vht_cap(struct ath10k *ar)
 	if (ar->phy_capability & WHAL_WLAN_11G_CAPABILITY) {
 		band = &ar->mac.sbands[NL80211_BAND_2GHZ];
 		band->ht_cap = ht_cap;
-
-		/* Enable the VHT support at 2.4 GHz */
-		band->vht_cap = vht_cap;
 	}
 	if (ar->phy_capability & WHAL_WLAN_11A_CAPABILITY) {
 		band = &ar->mac.sbands[NL80211_BAND_5GHZ];
-- 
1.7.9.5

[PATCH v2] ath10k: remove VHT capabilities from 2.4GHz

[Kalle Valo]

From: Johannes Berg <johannes.berg@intel.com>

According to the spec, VHT doesn't exist in 2.4GHz.

There are vendor extensions to allow a subset of VHT to work
(notably 256-QAM), but since mac80211 doesn't support those
advertising VHT capability on 2.4GHz leads to the behaviour
of reporting VHT capabilities but not being able to use any
of them due to mac80211's code requiring 80 MHz support.

Remove the VHT capabilities from 2.4GHz for now. If mac80211
gets extended to use the (likely Broadcom) vendor IEs for it
and handles the lack of 80 MHz support, it can be added back.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
---

v2:

* Cc ath10k@lists.infradead.org

 drivers/net/wireless/ath/ath10k/mac.c |    3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index bcf025f51310..d2a852805b07 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -4276,9 +4276,6 @@ static void ath10k_mac_setup_ht_vht_cap(struct ath10k *ar)
 	if (ar->phy_capability & WHAL_WLAN_11G_CAPABILITY) {
 		band = &ar->mac.sbands[NL80211_BAND_2GHZ];
 		band->ht_cap = ht_cap;
-
-		/* Enable the VHT support at 2.4 GHz */
-		band->vht_cap = vht_cap;
 	}
 	if (ar->phy_capability & WHAL_WLAN_11A_CAPABILITY) {
 		band = &ar->mac.sbands[NL80211_BAND_5GHZ];
-- 
1.7.9.5


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v2] ath10k: remove VHT capabilities from 2.4GHz

[Ben Greear]

On 04/21/2016 06:17 AM, Kalle Valo wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> According to the spec, VHT doesn't exist in 2.4GHz.
>
> There are vendor extensions to allow a subset of VHT to work
> (notably 256-QAM), but since mac80211 doesn't support those
> advertising VHT capability on 2.4GHz leads to the behaviour
> of reporting VHT capabilities but not being able to use any
> of them due to mac80211's code requiring 80 MHz support.
>
> Remove the VHT capabilities from 2.4GHz for now. If mac80211
> gets extended to use the (likely Broadcom) vendor IEs for it
> and handles the lack of 80 MHz support, it can be added back.
>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

The thing is, it actually works just fine with the patch I posted
to fix mac80211, and at any rate, even if the mac80211 patch isn't
applied, the ath10k driver works just fine in HT mode.

Have you actually found any case where the existing behaviour causes
a real problem?

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: [PATCH v2] ath10k: remove VHT capabilities from 2.4GHz

[Ben Greear]

On 04/21/2016 06:17 AM, Kalle Valo wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> According to the spec, VHT doesn't exist in 2.4GHz.
>
> There are vendor extensions to allow a subset of VHT to work
> (notably 256-QAM), but since mac80211 doesn't support those
> advertising VHT capability on 2.4GHz leads to the behaviour
> of reporting VHT capabilities but not being able to use any
> of them due to mac80211's code requiring 80 MHz support.
>
> Remove the VHT capabilities from 2.4GHz for now. If mac80211
> gets extended to use the (likely Broadcom) vendor IEs for it
> and handles the lack of 80 MHz support, it can be added back.
>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

The thing is, it actually works just fine with the patch I posted
to fix mac80211, and at any rate, even if the mac80211 patch isn't
applied, the ath10k driver works just fine in HT mode.

Have you actually found any case where the existing behaviour causes
a real problem?

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v2] ath10k: remove VHT capabilities from 2.4GHz

[Sebastian Gottschall]

Am 21.04.2016 um 17:15 schrieb Ben Greear:
> On 04/21/2016 06:17 AM, Kalle Valo wrote:
>> From: Johannes Berg <johannes.berg@intel.com>
>>
>> According to the spec, VHT doesn't exist in 2.4GHz.
>>
>> There are vendor extensions to allow a subset of VHT to work
>> (notably 256-QAM), but since mac80211 doesn't support those
>> advertising VHT capability on 2.4GHz leads to the behaviour
>> of reporting VHT capabilities but not being able to use any
>> of them due to mac80211's code requiring 80 MHz support.
>>
>> Remove the VHT capabilities from 2.4GHz for now. If mac80211
>> gets extended to use the (likely Broadcom) vendor IEs for it
>> and handles the lack of 80 MHz support, it can be added back.
>>
>> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
>> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
>
> The thing is, it actually works just fine with the patch I posted
> to fix mac80211, and at any rate, even if the mac80211 patch isn't
> applied, the ath10k driver works just fine in HT mode.
>
> Have you actually found any case where the existing behaviour causes
> a real problem?
i agree. other vendor chipsets to support QAM256 as well in 2.4 ghz 
(notably broadcom)
this is nonstandard, but since all going the same way it wouldnt be a 
great idea to keep QCA out of that extensions.
>
> Thanks,
> Ben
>


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v2] ath10k: remove VHT capabilities from 2.4GHz

[Michael Ney]

Also, several vendors are advertising QCA9980 and QCA9984 based access points with 256QAM support in 2.4GHz, such as the TP-Link AD7200 and the Netgear R7800, both of which advertise 800mbps 4-stream 2.4GHz capabilities.


> On Apr 21, 2016, at 4:09 PM, Sebastian Gottschall <s.gottschall@dd-wrt.com> wrote:
> 
> Am 21.04.2016 um 17:15 schrieb Ben Greear:
>> On 04/21/2016 06:17 AM, Kalle Valo wrote:
>>> From: Johannes Berg <johannes.berg@intel.com>
>>> 
>>> According to the spec, VHT doesn't exist in 2.4GHz.
>>> 
>>> There are vendor extensions to allow a subset of VHT to work
>>> (notably 256-QAM), but since mac80211 doesn't support those
>>> advertising VHT capability on 2.4GHz leads to the behaviour
>>> of reporting VHT capabilities but not being able to use any
>>> of them due to mac80211's code requiring 80 MHz support.
>>> 
>>> Remove the VHT capabilities from 2.4GHz for now. If mac80211
>>> gets extended to use the (likely Broadcom) vendor IEs for it
>>> and handles the lack of 80 MHz support, it can be added back.
>>> 
>>> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
>>> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
>> 
>> The thing is, it actually works just fine with the patch I posted
>> to fix mac80211, and at any rate, even if the mac80211 patch isn't
>> applied, the ath10k driver works just fine in HT mode.
>> 
>> Have you actually found any case where the existing behaviour causes
>> a real problem?
> i agree. other vendor chipsets to support QAM256 as well in 2.4 ghz (notably broadcom)
> this is nonstandard, but since all going the same way it wouldnt be a great idea to keep QCA out of that extensions.
>> 
>> Thanks,
>> Ben
>> 
> 
> 
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v2] ath10k: remove VHT capabilities from 2.4GHz

[Johannes Berg]

On Thu, 2016-04-21 at 08:15 -0700, Ben Greear wrote:

> The thing is, it actually works just fine with the patch I posted
> to fix mac80211, and at any rate, even if the mac80211 patch isn't
> applied, the ath10k driver works just fine in HT mode.

This patch has no implications on HT, and I wasn't planning on applying
the mac80211 patch.

As I said, I have no objections to doing the (Broadcom) vendor specific
IEs for "VHT" in 2.4 GHz band, but I don't think we should advertise
the spec IEs when they're explicitly specified to be used only in the
5.2 GHz band.

johannes

Re: [PATCH v2] ath10k: remove VHT capabilities from 2.4GHz

[Johannes Berg]

On Thu, 2016-04-21 at 08:15 -0700, Ben Greear wrote:

> The thing is, it actually works just fine with the patch I posted
> to fix mac80211, and at any rate, even if the mac80211 patch isn't
> applied, the ath10k driver works just fine in HT mode.

This patch has no implications on HT, and I wasn't planning on applying
the mac80211 patch.

As I said, I have no objections to doing the (Broadcom) vendor specific
IEs for "VHT" in 2.4 GHz band, but I don't think we should advertise
the spec IEs when they're explicitly specified to be used only in the
5.2 GHz band.

johannes

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v2] ath10k: remove VHT capabilities from 2.4GHz

[Valo, Kalle]

Johannes Berg <johannes@sipsolutions.net> writes:

> On Thu, 2016-04-21 at 08:15 -0700, Ben Greear wrote:
>
>> The thing is, it actually works just fine with the patch I posted
>> to fix mac80211, and at any rate, even if the mac80211 patch isn't
>> applied, the ath10k driver works just fine in HT mode.
>
> This patch has no implications on HT, and I wasn't planning on applying
> the mac80211 patch.

Yeah, makes sense. I'm planning to apply this soon.

> As I said, I have no objections to doing the (Broadcom) vendor specific
> IEs for "VHT" in 2.4 GHz band, but I don't think we should advertise
> the spec IEs when they're explicitly specified to be used only in the
> 5.2 GHz band.

But we really should have this, any volunteers? :) I think it shouldn't
be too hard to do so this would be a good project for someone looking
for a simple, but useful, task on wireless stack.

-- 
Kalle Valo

Re: [PATCH v2] ath10k: remove VHT capabilities from 2.4GHz

[Valo, Kalle]

Johannes Berg <johannes@sipsolutions.net> writes:

> On Thu, 2016-04-21 at 08:15 -0700, Ben Greear wrote:
>
>> The thing is, it actually works just fine with the patch I posted
>> to fix mac80211, and at any rate, even if the mac80211 patch isn't
>> applied, the ath10k driver works just fine in HT mode.
>
> This patch has no implications on HT, and I wasn't planning on applying
> the mac80211 patch.

Yeah, makes sense. I'm planning to apply this soon.

> As I said, I have no objections to doing the (Broadcom) vendor specific
> IEs for "VHT" in 2.4 GHz band, but I don't think we should advertise
> the spec IEs when they're explicitly specified to be used only in the
> 5.2 GHz band.

But we really should have this, any volunteers? :) I think it shouldn't
be too hard to do so this would be a good project for someone looking
for a simple, but useful, task on wireless stack.

-- 
Kalle Valo
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v2] ath10k: remove VHT capabilities from 2.4GHz

[Krishna Chaitanya]

On Tue, Apr 26, 2016 at 5:33 PM, Valo, Kalle <kvalo@qca.qualcomm.com> wrote:
> Johannes Berg <johannes@sipsolutions.net> writes:
>
>> On Thu, 2016-04-21 at 08:15 -0700, Ben Greear wrote:
>>
>>> The thing is, it actually works just fine with the patch I posted
>>> to fix mac80211, and at any rate, even if the mac80211 patch isn't
>>> applied, the ath10k driver works just fine in HT mode.
>>
>> This patch has no implications on HT, and I wasn't planning on applying
>> the mac80211 patch.
>
> Yeah, makes sense. I'm planning to apply this soon.
>
>> As I said, I have no objections to doing the (Broadcom) vendor specific
>> IEs for "VHT" in 2.4 GHz band, but I don't think we should advertise
>> the spec IEs when they're explicitly specified to be used only in the
>> 5.2 GHz band.
>
> But we really should have this, any volunteers? :) I think it shouldn't
> be too hard to do so this would be a good project for someone looking
> for a simple, but useful, task on wireless stack.
Are these Broadcom IEs documented somewhere? If yes,
then its a matter of parsing them and adding support to
minstrel_ht, isn't it? major work would be in minstrel.

Re: [PATCH v2] ath10k: remove VHT capabilities from 2.4GHz

[Krishna Chaitanya]

On Tue, Apr 26, 2016 at 5:33 PM, Valo, Kalle <kvalo@qca.qualcomm.com> wrote:
> Johannes Berg <johannes@sipsolutions.net> writes:
>
>> On Thu, 2016-04-21 at 08:15 -0700, Ben Greear wrote:
>>
>>> The thing is, it actually works just fine with the patch I posted
>>> to fix mac80211, and at any rate, even if the mac80211 patch isn't
>>> applied, the ath10k driver works just fine in HT mode.
>>
>> This patch has no implications on HT, and I wasn't planning on applying
>> the mac80211 patch.
>
> Yeah, makes sense. I'm planning to apply this soon.
>
>> As I said, I have no objections to doing the (Broadcom) vendor specific
>> IEs for "VHT" in 2.4 GHz band, but I don't think we should advertise
>> the spec IEs when they're explicitly specified to be used only in the
>> 5.2 GHz band.
>
> But we really should have this, any volunteers? :) I think it shouldn't
> be too hard to do so this would be a good project for someone looking
> for a simple, but useful, task on wireless stack.
Are these Broadcom IEs documented somewhere? If yes,
then its a matter of parsing them and adding support to
minstrel_ht, isn't it? major work would be in minstrel.

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v2] ath10k: remove VHT capabilities from 2.4GHz

[Ben Greear]

On 04/26/2016 01:07 PM, Krishna Chaitanya wrote:
> On Tue, Apr 26, 2016 at 5:33 PM, Valo, Kalle <kvalo@qca.qualcomm.com> wrote:
>> Johannes Berg <johannes@sipsolutions.net> writes:
>>
>>> On Thu, 2016-04-21 at 08:15 -0700, Ben Greear wrote:
>>>
>>>> The thing is, it actually works just fine with the patch I posted
>>>> to fix mac80211, and at any rate, even if the mac80211 patch isn't
>>>> applied, the ath10k driver works just fine in HT mode.
>>>
>>> This patch has no implications on HT, and I wasn't planning on applying
>>> the mac80211 patch.
>>
>> Yeah, makes sense. I'm planning to apply this soon.
>>
>>> As I said, I have no objections to doing the (Broadcom) vendor specific
>>> IEs for "VHT" in 2.4 GHz band, but I don't think we should advertise
>>> the spec IEs when they're explicitly specified to be used only in the
>>> 5.2 GHz band.
>>
>> But we really should have this, any volunteers? :) I think it shouldn't
>> be too hard to do so this would be a good project for someone looking
>> for a simple, but useful, task on wireless stack.
> Are these Broadcom IEs documented somewhere? If yes,
> then its a matter of parsing them and adding support to
> minstrel_ht, isn't it? major work would be in minstrel.
>

For ath10k, rate-ctrl is done in the firmware, so
no work at all in minstrel-ht.

The end result, as far as I can tell,
is you would just have to tell mac80211 to allow
VHT on 2.4Ghz, and revert this patch that Kalle is proposing.

Maybe someone that actually knows about these IEs can explain why
they are worth using?

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: [PATCH v2] ath10k: remove VHT capabilities from 2.4GHz

[Ben Greear]

On 04/26/2016 01:07 PM, Krishna Chaitanya wrote:
> On Tue, Apr 26, 2016 at 5:33 PM, Valo, Kalle <kvalo@qca.qualcomm.com> wrote:
>> Johannes Berg <johannes@sipsolutions.net> writes:
>>
>>> On Thu, 2016-04-21 at 08:15 -0700, Ben Greear wrote:
>>>
>>>> The thing is, it actually works just fine with the patch I posted
>>>> to fix mac80211, and at any rate, even if the mac80211 patch isn't
>>>> applied, the ath10k driver works just fine in HT mode.
>>>
>>> This patch has no implications on HT, and I wasn't planning on applying
>>> the mac80211 patch.
>>
>> Yeah, makes sense. I'm planning to apply this soon.
>>
>>> As I said, I have no objections to doing the (Broadcom) vendor specific
>>> IEs for "VHT" in 2.4 GHz band, but I don't think we should advertise
>>> the spec IEs when they're explicitly specified to be used only in the
>>> 5.2 GHz band.
>>
>> But we really should have this, any volunteers? :) I think it shouldn't
>> be too hard to do so this would be a good project for someone looking
>> for a simple, but useful, task on wireless stack.
> Are these Broadcom IEs documented somewhere? If yes,
> then its a matter of parsing them and adding support to
> minstrel_ht, isn't it? major work would be in minstrel.
>

For ath10k, rate-ctrl is done in the firmware, so
no work at all in minstrel-ht.

The end result, as far as I can tell,
is you would just have to tell mac80211 to allow
VHT on 2.4Ghz, and revert this patch that Kalle is proposing.

Maybe someone that actually knows about these IEs can explain why
they are worth using?

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v2] ath10k: remove VHT capabilities from 2.4GHz

[Krishna Chaitanya]

On Wed, Apr 27, 2016 at 1:40 AM, Ben Greear <greearb@candelatech.com> wrote:
> On 04/26/2016 01:07 PM, Krishna Chaitanya wrote:
>>
>> On Tue, Apr 26, 2016 at 5:33 PM, Valo, Kalle <kvalo@qca.qualcomm.com>
>> wrote:
>>>
>>> Johannes Berg <johannes@sipsolutions.net> writes:
>>>
>>>> On Thu, 2016-04-21 at 08:15 -0700, Ben Greear wrote:
>>>>
>>>>> The thing is, it actually works just fine with the patch I posted
>>>>> to fix mac80211, and at any rate, even if the mac80211 patch isn't
>>>>> applied, the ath10k driver works just fine in HT mode.
>>>>
>>>>
>>>> This patch has no implications on HT, and I wasn't planning on applying
>>>> the mac80211 patch.
>>>
>>>
>>> Yeah, makes sense. I'm planning to apply this soon.
>>>
>>>> As I said, I have no objections to doing the (Broadcom) vendor specific
>>>> IEs for "VHT" in 2.4 GHz band, but I don't think we should advertise
>>>> the spec IEs when they're explicitly specified to be used only in the
>>>> 5.2 GHz band.
>>>
>>>
>>> But we really should have this, any volunteers? :) I think it shouldn't
>>> be too hard to do so this would be a good project for someone looking
>>> for a simple, but useful, task on wireless stack.
>>
>> Are these Broadcom IEs documented somewhere? If yes,
>> then its a matter of parsing them and adding support to
>> minstrel_ht, isn't it? major work would be in minstrel.
>>
>
> For ath10k, rate-ctrl is done in the firmware, so
> no work at all in minstrel-ht.

Right, i think this might become more common.
So may we need to change minstrel_ht as well?

> The end result, as far as I can tell,
> is you would just have to tell mac80211 to allow
> VHT on 2.4Ghz, and revert this patch that Kalle is proposing.

Ideally as this is vendor specific it makes sense to implement this
at Driver/FW level rather than implementing it at a common stack
like mac80211.

> Maybe someone that actually knows about these IEs can explain why
> they are worth using?

These IE's can be parsed in the driver without any mac80211 involvement.

Re: [PATCH v2] ath10k: remove VHT capabilities from 2.4GHz

[Krishna Chaitanya]

On Wed, Apr 27, 2016 at 1:40 AM, Ben Greear <greearb@candelatech.com> wrote:
> On 04/26/2016 01:07 PM, Krishna Chaitanya wrote:
>>
>> On Tue, Apr 26, 2016 at 5:33 PM, Valo, Kalle <kvalo@qca.qualcomm.com>
>> wrote:
>>>
>>> Johannes Berg <johannes@sipsolutions.net> writes:
>>>
>>>> On Thu, 2016-04-21 at 08:15 -0700, Ben Greear wrote:
>>>>
>>>>> The thing is, it actually works just fine with the patch I posted
>>>>> to fix mac80211, and at any rate, even if the mac80211 patch isn't
>>>>> applied, the ath10k driver works just fine in HT mode.
>>>>
>>>>
>>>> This patch has no implications on HT, and I wasn't planning on applying
>>>> the mac80211 patch.
>>>
>>>
>>> Yeah, makes sense. I'm planning to apply this soon.
>>>
>>>> As I said, I have no objections to doing the (Broadcom) vendor specific
>>>> IEs for "VHT" in 2.4 GHz band, but I don't think we should advertise
>>>> the spec IEs when they're explicitly specified to be used only in the
>>>> 5.2 GHz band.
>>>
>>>
>>> But we really should have this, any volunteers? :) I think it shouldn't
>>> be too hard to do so this would be a good project for someone looking
>>> for a simple, but useful, task on wireless stack.
>>
>> Are these Broadcom IEs documented somewhere? If yes,
>> then its a matter of parsing them and adding support to
>> minstrel_ht, isn't it? major work would be in minstrel.
>>
>
> For ath10k, rate-ctrl is done in the firmware, so
> no work at all in minstrel-ht.

Right, i think this might become more common.
So may we need to change minstrel_ht as well?

> The end result, as far as I can tell,
> is you would just have to tell mac80211 to allow
> VHT on 2.4Ghz, and revert this patch that Kalle is proposing.

Ideally as this is vendor specific it makes sense to implement this
at Driver/FW level rather than implementing it at a common stack
like mac80211.

> Maybe someone that actually knows about these IEs can explain why
> they are worth using?

These IE's can be parsed in the driver without any mac80211 involvement.

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v2] ath10k: remove VHT capabilities from 2.4GHz

[Jouni Malinen]

On Wed, Apr 27, 2016 at 12:13:46PM +0530, Krishna Chaitanya wrote:
> On Wed, Apr 27, 2016 at 1:40 AM, Ben Greear <greearb@candelatech.com> wrote:
> > On 04/26/2016 01:07 PM, Krishna Chaitanya wrote:
> >> Are these Broadcom IEs documented somewhere? If yes,
> >> then its a matter of parsing them and adding support to
> >> minstrel_ht, isn't it? major work would be in minstrel.

> > The end result, as far as I can tell,
> > is you would just have to tell mac80211 to allow
> > VHT on 2.4Ghz, and revert this patch that Kalle is proposing.
> 
> Ideally as this is vendor specific it makes sense to implement this
> at Driver/FW level rather than implementing it at a common stack
> like mac80211.
> 
> > Maybe someone that actually knows about these IEs can explain why
> > they are worth using?
> 
> These IE's can be parsed in the driver without any mac80211 involvement.

Sure, these are vendor specific elements, but they are simply
encapsulating the standard VHT elements that we already handle within
mac80211 for STA functionality and hostapd for AP functionality. I don't
see why we would make this any more complex for 2.4 GHz 256-QAM support
than extending the existing locations that support the VHT elements.

The main reason for me in using these particular vendor specific
elements is in them being already supported by number of deployed
devices. There is also support for these in hostapd (vendor_vht=1 in
hostapd.conf) and as far as I know, this used to work with ath10k for AP
mode (and this patch we discuss here may break that). The main missing
functionality is for the matching STA side support with mac80211 and
that's where the changes, IMHO, would fit in nicely in mac80211 next to
the places where we handle the matching standard VHT elements in the 5
GHz band.
 
-- 
Jouni Malinen                                            PGP id EFC895FA

Re: [PATCH v2] ath10k: remove VHT capabilities from 2.4GHz

[Jouni Malinen]

On Wed, Apr 27, 2016 at 12:13:46PM +0530, Krishna Chaitanya wrote:
> On Wed, Apr 27, 2016 at 1:40 AM, Ben Greear <greearb@candelatech.com> wrote:
> > On 04/26/2016 01:07 PM, Krishna Chaitanya wrote:
> >> Are these Broadcom IEs documented somewhere? If yes,
> >> then its a matter of parsing them and adding support to
> >> minstrel_ht, isn't it? major work would be in minstrel.

> > The end result, as far as I can tell,
> > is you would just have to tell mac80211 to allow
> > VHT on 2.4Ghz, and revert this patch that Kalle is proposing.
> 
> Ideally as this is vendor specific it makes sense to implement this
> at Driver/FW level rather than implementing it at a common stack
> like mac80211.
> 
> > Maybe someone that actually knows about these IEs can explain why
> > they are worth using?
> 
> These IE's can be parsed in the driver without any mac80211 involvement.

Sure, these are vendor specific elements, but they are simply
encapsulating the standard VHT elements that we already handle within
mac80211 for STA functionality and hostapd for AP functionality. I don't
see why we would make this any more complex for 2.4 GHz 256-QAM support
than extending the existing locations that support the VHT elements.

The main reason for me in using these particular vendor specific
elements is in them being already supported by number of deployed
devices. There is also support for these in hostapd (vendor_vht=1 in
hostapd.conf) and as far as I know, this used to work with ath10k for AP
mode (and this patch we discuss here may break that). The main missing
functionality is for the matching STA side support with mac80211 and
that's where the changes, IMHO, would fit in nicely in mac80211 next to
the places where we handle the matching standard VHT elements in the 5
GHz band.
 
-- 
Jouni Malinen                                            PGP id EFC895FA

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v2] ath10k: remove VHT capabilities from 2.4GHz

[Krishna Chaitanya]

On Wed, Apr 27, 2016 at 2:46 PM, Jouni Malinen <j@w1.fi> wrote:
> On Wed, Apr 27, 2016 at 12:13:46PM +0530, Krishna Chaitanya wrote:
>> On Wed, Apr 27, 2016 at 1:40 AM, Ben Greear <greearb@candelatech.com> wrote:
>> > On 04/26/2016 01:07 PM, Krishna Chaitanya wrote:
>> >> Are these Broadcom IEs documented somewhere? If yes,
>> >> then its a matter of parsing them and adding support to
>> >> minstrel_ht, isn't it? major work would be in minstrel.
>
>> > The end result, as far as I can tell,
>> > is you would just have to tell mac80211 to allow
>> > VHT on 2.4Ghz, and revert this patch that Kalle is proposing.
>>
>> Ideally as this is vendor specific it makes sense to implement this
>> at Driver/FW level rather than implementing it at a common stack
>> like mac80211.
>>
>> > Maybe someone that actually knows about these IEs can explain why
>> > they are worth using?
>>
>> These IE's can be parsed in the driver without any mac80211 involvement.
>
> Sure, these are vendor specific elements, but they are simply
> encapsulating the standard VHT elements that we already handle within
> mac80211 for STA functionality and hostapd for AP functionality. I don't
> see why we would make this any more complex for 2.4 GHz 256-QAM support
> than extending the existing locations that support the VHT elements.
>
> The main reason for me in using these particular vendor specific
> elements is in them being already supported by number of deployed
> devices. There is also support for these in hostapd (vendor_vht=1 in
> hostapd.conf) and as far as I know, this used to work with ath10k for AP
> mode (and this patch we discuss here may break that). The main missing
> functionality is for the matching STA side support with mac80211 and
> that's where the changes, IMHO, would fit in nicely in mac80211 next to
> the places where we handle the matching standard VHT elements in the 5
> GHz band.
If many vendors need this support, then mac80211 appraoch would be good.
If not, we should stick to driver approach.

Re: [PATCH v2] ath10k: remove VHT capabilities from 2.4GHz

[Krishna Chaitanya]

On Wed, Apr 27, 2016 at 2:46 PM, Jouni Malinen <j@w1.fi> wrote:
> On Wed, Apr 27, 2016 at 12:13:46PM +0530, Krishna Chaitanya wrote:
>> On Wed, Apr 27, 2016 at 1:40 AM, Ben Greear <greearb@candelatech.com> wrote:
>> > On 04/26/2016 01:07 PM, Krishna Chaitanya wrote:
>> >> Are these Broadcom IEs documented somewhere? If yes,
>> >> then its a matter of parsing them and adding support to
>> >> minstrel_ht, isn't it? major work would be in minstrel.
>
>> > The end result, as far as I can tell,
>> > is you would just have to tell mac80211 to allow
>> > VHT on 2.4Ghz, and revert this patch that Kalle is proposing.
>>
>> Ideally as this is vendor specific it makes sense to implement this
>> at Driver/FW level rather than implementing it at a common stack
>> like mac80211.
>>
>> > Maybe someone that actually knows about these IEs can explain why
>> > they are worth using?
>>
>> These IE's can be parsed in the driver without any mac80211 involvement.
>
> Sure, these are vendor specific elements, but they are simply
> encapsulating the standard VHT elements that we already handle within
> mac80211 for STA functionality and hostapd for AP functionality. I don't
> see why we would make this any more complex for 2.4 GHz 256-QAM support
> than extending the existing locations that support the VHT elements.
>
> The main reason for me in using these particular vendor specific
> elements is in them being already supported by number of deployed
> devices. There is also support for these in hostapd (vendor_vht=1 in
> hostapd.conf) and as far as I know, this used to work with ath10k for AP
> mode (and this patch we discuss here may break that). The main missing
> functionality is for the matching STA side support with mac80211 and
> that's where the changes, IMHO, would fit in nicely in mac80211 next to
> the places where we handle the matching standard VHT elements in the 5
> GHz band.
If many vendors need this support, then mac80211 appraoch would be good.
If not, we should stick to driver approach.

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v2] ath10k: remove VHT capabilities from 2.4GHz

[Johannes Berg]

On Wed, 2016-04-27 at 15:07 +0530, Krishna Chaitanya wrote:
> 
> If many vendors need this support, then mac80211 appraoch would be
> good. If not, we should stick to driver approach.

Trying to do this in the driver gets practically impossible, so no, it
really should be done in mac80211 either way. Drivers have to opt in by
reporting VHT caps for 2.4 GHz, at which point we simply revert this
patch, but get the right over-the-air behaviour.

johannes

Re: [PATCH v2] ath10k: remove VHT capabilities from 2.4GHz

[Johannes Berg]

On Wed, 2016-04-27 at 15:07 +0530, Krishna Chaitanya wrote:
> 
> If many vendors need this support, then mac80211 appraoch would be
> good. If not, we should stick to driver approach.

Trying to do this in the driver gets practically impossible, so no, it
really should be done in mac80211 either way. Drivers have to opt in by
reporting VHT caps for 2.4 GHz, at which point we simply revert this
patch, but get the right over-the-air behaviour.

johannes

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v2] ath10k: remove VHT capabilities from 2.4GHz

[Valo, Kalle]

Kalle Valo <kvalo@qca.qualcomm.com> writes:

> From: Johannes Berg <johannes.berg@intel.com>
>
> According to the spec, VHT doesn't exist in 2.4GHz.
>
> There are vendor extensions to allow a subset of VHT to work
> (notably 256-QAM), but since mac80211 doesn't support those
> advertising VHT capability on 2.4GHz leads to the behaviour
> of reporting VHT capabilities but not being able to use any
> of them due to mac80211's code requiring 80 MHz support.
>
> Remove the VHT capabilities from 2.4GHz for now. If mac80211
> gets extended to use the (likely Broadcom) vendor IEs for it
> and handles the lack of 80 MHz support, it can be added back.
>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

Applied, thanks.

-- 
Kalle Valo

Re: [PATCH v2] ath10k: remove VHT capabilities from 2.4GHz

[Valo, Kalle]

Kalle Valo <kvalo@qca.qualcomm.com> writes:

> From: Johannes Berg <johannes.berg@intel.com>
>
> According to the spec, VHT doesn't exist in 2.4GHz.
>
> There are vendor extensions to allow a subset of VHT to work
> (notably 256-QAM), but since mac80211 doesn't support those
> advertising VHT capability on 2.4GHz leads to the behaviour
> of reporting VHT capabilities but not being able to use any
> of them due to mac80211's code requiring 80 MHz support.
>
> Remove the VHT capabilities from 2.4GHz for now. If mac80211
> gets extended to use the (likely Broadcom) vendor IEs for it
> and handles the lack of 80 MHz support, it can be added back.
>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

Applied, thanks.

-- 
Kalle Valo
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k