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

[Krishna Chaitanya]

On Wed, Apr 27, 2016 at 2:46 PM, Jouni Malinen <j at 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 at 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.