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 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





[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