]> git.ipfire.org Git - thirdparty/kernel/linux.git/commit
wifi: cfg80211: don't apply HT flags to S1G channels
authorLachlan Hodges <lachlan.hodges@morsemicro.com>
Tue, 13 Jan 2026 03:09:34 +0000 (14:09 +1100)
committerJohannes Berg <johannes.berg@intel.com>
Tue, 13 Jan 2026 09:44:26 +0000 (10:44 +0100)
commit24a57985670e9dac5547e5b7731bf8e7b03d5be8
tree1e3214a0636c166dc68375453fd1e74694543573
parent669aa3e3faa8ae876c169cde5b234828275caef8
wifi: cfg80211: don't apply HT flags to S1G channels

HT flags don't really make sense when applied to S1G channels
especially given the bandwidths both used for calculations and
conveyed (i.e 20MHz). Similarly with the 80/160/..MHz channels,
each bonded subchannel is validated individually within
cfg80211_s1g_usable(), so the regulatory validation is similarly
redundant. Additionally, usermode application output (such as iwinfo
below) doesn't particularly make sense when enumerating S1G channels:

before:

925.500 MHz (Band: 900 MHz, Channel 47) [NO_HT40+, NO_HT40-, NO_16MHZ]
926.500 MHz (Band: 900 MHz, Channel 49) [NO_HT40+, NO_HT40-, NO_16MHZ]
927.500 MHz (Band: 900 MHz, Channel 51) [NO_HT40+, NO_HT40-, NO_16MHZ, NO_PRIMARY]

after:

925.500 MHz (Band: 900 MHz, Channel 47) [NO_16MHZ]
926.500 MHz (Band: 900 MHz, Channel 49) [NO_16MHZ]
927.500 MHz (Band: 900 MHz, Channel 51) [NO_16MHZ, NO_PRIMARY]

Don't process the S1G band when applying HT flags as both the regulatory
component is redundant and the flags don't make sense for S1G channels.

Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com>
Link: https://patch.msgid.link/20260113030934.18726-1-lachlan.hodges@morsemicro.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
net/wireless/reg.c