| Message ID | 20241213121146.2398269-1-quic_vjakkam@quicinc.com |
|---|---|
| State | New |
| Headers | show |
| Series | wifi: ieee80211: update Indoor AFC standard power type definition | expand |
On Fri, 2024-12-13 at 17:41 +0530, Veerendranath Jakkam wrote: > Update 6 GHz regulatory info subfield mask and Indoor AFC standard power > type definitions to align with spec changes introduced in the Draft > P802.11Revme_D4.2, Figure 9-896 and Table E-13. > Huh. That seems like a change explicitly *designed* to break backward compatibility? Should we accept the old value from older APs or so? Otherwise we can't connect in some scenarios, I think? Or at least should we say here in the commit message or so why backward compatibility was broken, and that it was for other clients that didn't behave well or something but our code was already fine? Or am I completely confused about it? johannes
On 12/13/2024 4:16 AM, Johannes Berg wrote: > On Fri, 2024-12-13 at 17:41 +0530, Veerendranath Jakkam wrote: >> Update 6 GHz regulatory info subfield mask and Indoor AFC standard power >> type definitions to align with spec changes introduced in the Draft >> P802.11Revme_D4.2, Figure 9-896 and Table E-13. >> > > Huh. That seems like a change explicitly *designed* to break backward > compatibility? Should we accept the old value from older APs or so? > Otherwise we can't connect in some scenarios, I think? > > Or at least should we say here in the commit message or so why backward > compatibility was broken, and that it was for other clients that didn't > behave well or something but our code was already fine? > > Or am I completely confused about it? IEEE Drafts sometimes make non-backward-compatible changes. This change brings us up to date with the language in Draft 7.0 that was ratified and will be published as IEEE 802.11be-2024. So if anything breaks, it is because it hasn't been updated from the draft to the ratified standard. /jeff
On 12/16/2024 2:54 AM, Johannes Berg wrote: > On Fri, 2024-12-13 at 12:11 -0800, Jeff Johnson wrote: >> On 12/13/2024 4:16 AM, Johannes Berg wrote: >>> On Fri, 2024-12-13 at 17:41 +0530, Veerendranath Jakkam wrote: >>>> Update 6 GHz regulatory info subfield mask and Indoor AFC standard power >>>> type definitions to align with spec changes introduced in the Draft >>>> P802.11Revme_D4.2, Figure 9-896 and Table E-13. >>>> >>> >>> Huh. That seems like a change explicitly *designed* to break backward >>> compatibility? Should we accept the old value from older APs or so? >>> Otherwise we can't connect in some scenarios, I think? >>> >>> Or at least should we say here in the commit message or so why backward >>> compatibility was broken, and that it was for other clients that didn't >>> behave well or something but our code was already fine? >>> >>> Or am I completely confused about it? >> >> IEEE Drafts sometimes make non-backward-compatible changes. > > Umm. Me voicing confusion isn't a reason to state obvious things back to > me as if that explained anything at all? > > In any case, they actually do that _very_ rarely (these days at least, > that was different 20 years ago I'd say) without taking existing > deployed things into account though. > >> This change brings >> us up to date with the language in Draft 7.0 that was ratified and will be >> published as IEEE 802.11be-2024.> > That's not what this claimed in the commit log. You are correct. When writing my response I referenced IEEE 802.11be Draft 7.0 when I meant to reference P802.11Revme_D7.0 (since that is the latest Revme) I've been so focused on 11be that I completely messed up the reference. > > It also _cannot_ be correct since this stuff is in baseline as far as > 802.11be is concerned, so it really cannot make incompatible changes > that suddenly make all HE stations non-compliant. > > And now that you're forcing me to look into it, I see that of course it > doesn't do that. This has nothing to do with Draft 802.11be in any > version which only makes one simple change to Annex E to add 320 MHz. > > The commit log claims that REVme changes it, and while that might be > true, looking at REVme (I don't have a redline version at hand right > now) indicates that certainly it didn't make it backward incompatible, > it now accepts multiple values and accepts the old values. > >> So if anything breaks, it is because it >> hasn't been updated from the draft to the ratified standard. > > Clearly not. > > Suggest you go back to the drawing board with these changes. Veerendranath, can you follow up on this part. /jeff
diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h index 05dedc45505c..2091af5e8b8c 100644 --- a/include/linux/ieee80211.h +++ b/include/linux/ieee80211.h @@ -2764,7 +2764,7 @@ static inline bool ieee80211_he_capa_size_ok(const u8 *data, u8 len) #define IEEE80211_6GHZ_CTRL_REG_SP_AP 1 #define IEEE80211_6GHZ_CTRL_REG_VLP_AP 2 #define IEEE80211_6GHZ_CTRL_REG_INDOOR_LPI_AP 3 -#define IEEE80211_6GHZ_CTRL_REG_INDOOR_SP_AP 4 +#define IEEE80211_6GHZ_CTRL_REG_INDOOR_SP_AP 8 /** * struct ieee80211_he_6ghz_oper - HE 6 GHz operation Information field @@ -2782,7 +2782,7 @@ struct ieee80211_he_6ghz_oper { #define IEEE80211_HE_6GHZ_OPER_CTRL_CHANWIDTH_80MHZ 2 #define IEEE80211_HE_6GHZ_OPER_CTRL_CHANWIDTH_160MHZ 3 #define IEEE80211_HE_6GHZ_OPER_CTRL_DUP_BEACON 0x4 -#define IEEE80211_HE_6GHZ_OPER_CTRL_REG_INFO 0x38 +#define IEEE80211_HE_6GHZ_OPER_CTRL_REG_INFO 0x78 u8 control; u8 ccfs0; u8 ccfs1;
Update 6 GHz regulatory info subfield mask and Indoor AFC standard power type definitions to align with spec changes introduced in the Draft P802.11Revme_D4.2, Figure 9-896 and Table E-13. Signed-off-by: Veerendranath Jakkam <quic_vjakkam@quicinc.com> --- include/linux/ieee80211.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)