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

[Jouni Malinen <j@w1.fi>]

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