Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) client-ip=2620:137:e000::3:5;
Message-ID: <dfb80594f144fd4ad4cfc7ef205ec0590ce6ca2f.camel@sipsolutions.net>
Subject: Re: [PATCH 2/3] cfg80211: validate RU puncturing bitmap
From:   Johannes Berg <johannes@sipsolutions.net>
To:     Aloka Dixit <quic_alokad@quicinc.com>,
        linux-wireless@vger.kernel.org
Cc:     Jeff Johnson <quic_jjohnson@quicinc.com>
Date:   Thu, 12 Oct 2023 14:13:43 +0200
In-Reply-To: <9fd4a3097e078c1fe2acd5fbd0c559b0390daa49.camel@sipsolutions.net>
References: <20220214223051.3610-1-quic_alokad@quicinc.com>
         <20220214223051.3610-3-quic_alokad@quicinc.com>
         <a9813545a25cd63f71cc31476230514a80350802.camel@sipsolutions.net>
         <6cf56be5-16d6-2bcd-150f-bf29f98b7f1b@quicinc.com>
         <58fdd62041c0388740cabea5a421c5417f959124.camel@sipsolutions.net>
         <9fd4a3097e078c1fe2acd5fbd0c559b0390daa49.camel@sipsolutions.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.48.4 (3.48.4-1.fc38) 
MIME-Version: 1.0
Precedence: bulk

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