Hi Johannes,
On Thu, Jul 3, 2025 at 8:09 AM Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote:
>
> I'm not entirely sure that'd be correct. 320 MHz can only be used on the
> 6 GHz band, so clients must be at least HE, but I'm not sure that VHT
> opmode notification frames are completely illegal for them, even if
> they'd like use OMI instead.
>
Understood. That clarifies the case for not filtering out 320 MHz, even when a
VHT opmode notification is present.
On Thu, Jul 3, 2025 at 8:11 AM Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote:
>
> n/m, it just did that quite explicitly. I really want to get rid of all
> that 5/10 MHz code, but we still have S1G so that might still happen
> anyway, and I expect for S1G VHT operating mode notification frames
> _are_ invalid.
To address this, I plan to reject the set of channel widths that are not valid
with VHT opmode. This includes all channel widths below 20 MHz, as well as
20 MHz without HT (20_NOHT), which is also incompatible.
Would the following logic for v2 be acceptable?
/* reject channel widths not valid with VHT opmode */
switch (width) {
case NL80211_CHAN_WIDTH_5:
case NL80211_CHAN_WIDTH_10:
case NL80211_CHAN_WIDTH_1:
case NL80211_CHAN_WIDTH_2:
case NL80211_CHAN_WIDTH_4:
case NL80211_CHAN_WIDTH_8:
case NL80211_CHAN_WIDTH_16:
case NL80211_CHAN_WIDTH_20_NOHT:
return -EINVAL;
default:
break;
}
This allows valid HT/VHT channel widths, including 20, 40, 80, 80+80, 160, and
320, to pass through while filtering out values that would otherwise trigger a
WARN_ON.
Best regards,
Moonhee
