Search Linux Wireless

Re: [PATCH] wifi: ieee80211: update Indoor AFC standard power type definition

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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.

johannes





[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Wireless Regulations]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux