And another thing - separately because it's not related to puncturing, but in the same thread because it's related to the channel context handling... We also realized that a very similar thing might happen for the OFDMA trigger frame processing. Obviously I don't know if this is hardware or firmware in ath12k, but given the speed this happens at, at least in our device we can't really control it up-front. As a client, you might (for various reasons) connect to an AP with a lower bandwidth than the AP has configured. In this case, OFDMA UL/DL is still mostly mandatory (80 MHz STA in a 160/320 MHz BSS, 160 MHz STA in a 320 MHz BSS). As a result, if you end up being a STA with two EH connections (*), you have to be able to parse the trigger frame / downlink OFDMA RU allocation according to the *AP bandwidth* (**). (*) And expect OFDMA on them, so RU allocations are relative to the AP bandwidth; we're assuming for now that P2P will not use OFDMA. (**) See 36.3.2.7 80 MHz operating non-AP EHT STAs participating in wider bandwidth OFDMA and 36.3.2.8 for 160 MHz. As a result, I'm thinking of adding the OFDMA bandwidth to the chandef, and then treating two different ones as incompatible, though due to (*) we might want driver-local decision on whether OFDMA is possible or not, at least unless you agree that we should ignore it in P2P. For HE, OFDMA exists but you don't participate in wider-than-your-bandwidth OFMDA, so I guess we'd treat it as not relevant there. Then we might end up with a situation where we have two different say 80 MHz channel contexts in mac80211 because one is with a 320 MHz AP and the other with a 160 MHz AP, but that's necessary, I think. Thoughts? johannes
