Hi, So I'm looking at UHR NPCA and DSO, mostly wrt. the configuration in mac80211 (and perhaps to some extent cfg80211, for sniffer.) Let me look at NPCA first. For NPCA with a device that's capable of supporting the full channel width (e.g. 320 MHz with non-primary 160 MHz being used in that case, or non-primary 80 MHz out of overall 160 MHz) this seems fairly straight-forward: - the chandef or chanreq can simply contain a value/pointer for the non-primary control channel location, if any - the channel context in mac80211 cannot be shared any more, since transmissions on the other vif would be seen as OBSS for NCPA purposes, and the AP might try to use NPCA with the station that's actually doing the OBSS transmission on the other vif That's about it for the simple case? Not sure if it should be in the chandef like puncturing or in the chanreq like the full AP channel for EHT triggering, what does the AP side for NPCA look like in terms of configuration? Seems like probably it would be configured via hostapd and then it should be in the chandef? However, there's another case, say you have a device that only supports 160 MHz, but then connects to an AP with 320 MHz. In this case, it's meant to still support NPCA. This is not relevant for an AP, I believe. But this case is more tricky: - Should we set the chandef to 320 MHz, but indicate somehow separately that only the two 160 MHz channels are really used, since the HW is incapable of 320 MHz? That seems ... strange. - Should instead the chandef be for 160 MHz, and the non-primary control channel is actually outside the 160 MHz channel? That's somewhat plausible, but hard to decode? - Intel firmware is going to require two PHY contexts, but should that really be reflected in mac80211 as two channel contexts? Right now my gut feeling is no, and the second channel context also couldn't be shared with other vifs since the device really isn't active there. Or maybe in this case we only put the non-primary control channel into the *AP* chandef inside the chanreq (struct ieee80211_chan_req::ap) and not into struct ieee80211_chan_req::oper, since that actually reflects the full 320 MHz, and let the driver figure out the rest? I think right now I'd probably consider this option most sane, since this case doesn't apply to AP mode? And in the "easy" case above obviously the non-primary control channel would be in both then in the channel request. As for DSO, that's only relevant for the second kind of device (which connects to an AP with a higher bandwidth than it can support), so maybe if the struct ieee80211_chan_req::ap gives the information, the driver can sort it out just like I was outlining in the previous paragraph for NPCA? For sniffer also I guess it's just part of the chandef, which might also require configuring/tracking the BSS color. Even if the sniffer could listen on both control channels it'd still have to decide which to decode, unless it's actually fully dual-channel. Anyone have any other thoughts? johannes
