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@xxxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
