On Mon, Sep 12, 2016 at 12:09:42PM +0200, Johannes Berg wrote: > I have no major objections to this. However, a few things: > > 1) are you planning to add support for this into a kernel driver at > all, anyway? > 2) are you planning to have a driver upstream that contains the now > necessary parsing? > > Depending on the answers, I suppose we could/should merge this: > > no * : don't merge > yes no : merge > yes yes: don't merge, put parsing into cfg80211 > > I guess? The main goal of this was to see if we can reduce actual driver implementation size and maybe even more so to prepare for 802.11ax changes (i.e., see what we are doing currently for configuring HT/VHT in a way that could be done better). As you noted earlier, this would not really allow the driver to drop its HT/VHT related parsing operations without making sure user space components were updated as well. The approach to avoid that is that "parsing into cfg80211". Looking at the current in-tree drivers, it looks like following approaches have been used: ath6kl: Use cfg80211_get_chandef_type(&info->chandef) != NL80211_CHAN_NO_HT to determine whether HT is enabled. No VHT support. HT-required case not covered. No parsing of HT/VHT IEs used. brcmfmac: Uses info->chandef. Not clear how HT/VHT could be disabled or required. Note: Parses Beacon IEs for Country and SSID (as backup for ssid == NULL!?), RSN, WPA. mwifiex: Uses info->chandef. Parses Beacon tail: Enables VHT based on searching info->beacon.tail for VHT Capability element. Parses HT Capability to determine whether HT is to be supported and also to set various HT parameters. Does not seem to have support for HT/VHT-required. So I guess there could be some code sharing and cleanup done with the existing in-tree drivers. Especially the mwifiex example looks like something that triggered us to look at this. I'm not sure we'd propose adding any new driver with the driver code itself doing HT/VHT IE parsing and since ath6kl did not do this either, I don't see us changing existing in-tree drivers to use this either. I'm not sure there would really be enough justification to add this specific patch due to the assumed user space update. Adding some of the HT/VHT element parsing in cfg80211 might benefit on or two of the in-tree drivers if their maintainers are interested in that. That said, without additional interest, I'm starting to lean towards using this as an example of what type of parameters we need to add for HE from the beginning and not merge this patch. -- Jouni Malinen PGP id EFC895FA
