Re: [PATCH 3/3] wifi: Transition/Padding delay subfields are for both EMLSR and EMLMR

[Pablo MARTIN-GOMEZ <pmartin-gomez@freebox.fr>]

On 08/04/2026 14:07, Johannes Berg wrote:
> On Tue, 2026-04-07 at 17:47 +0200, Pablo MARTIN-GOMEZ wrote:
>> On 07/04/2026 16:00, Johannes Berg wrote:
>>> On Fri, 2026-03-27 at 21:11 +0100, Pablo Martin-Gomez wrote:
>>>> -#define IEEE80211_EML_CAP_EMLSR_TRANSITION_DELAY	0x0070
>>>> +#define IEEE80211_EML_CAP_EMLSR_EMLMR_TRANSITION_DELAY	0x0070
>>>>  #define  IEEE80211_EML_CAP_EMLSR_TRANSITION_DELAY_0US		0
>>>>  #define  IEEE80211_EML_CAP_EMLSR_TRANSITION_DELAY_16US		1
>>>>  #define  IEEE80211_EML_CAP_EMLSR_TRANSITION_DELAY_32US		2
>>>
>>> I think this is confusing. You have the "EMLSR_EMLMR_" prefix in the
>>> definition for the mask, but not in the values, but also the prefix
>>> itself gets very long, not sure what to do about that. Maybe just
>>> ..._EML_TRANSITION_DELAY even if it doesn't match the spec completely.
>> In the standard, there is two different tables to convert the field
>> value to a delay: 9-417j for EMLSR and 9-417l for EMLMR. E.g. if the
>> field has the value 1, in EMLSR mode, it's a 16 µs delay, in EMLMR mode,
>> it's a 32 µs delay.
> 
> Ouch, good catch. Why do they just want to make everyone's life harder
> all the time...
> 
>> As no driver implements EMLMR, I was expecting the first one to
>> implement it to create the defines:
>> ```
>> #define  IEEE80211_EML_CAP_EMLMR_TRANSITION_DELAY_0US	0
>> #define  IEEE80211_EML_CAP_EMLMR_TRANSITION_DELAY_32US	1
>> [...]
>> ```
> 
> That seems dangerous, you have to really look hard at the spec to really
> notice?
> 
>> If you prefer, I can implement it +
>> `ieee80211_emlmr_[trans/pad]_delay_in_us` but it will be dead code for now.
> 
> Dead code in form of a bunch of defines doesn't seem so bad I guess?
> 
> But I still think the naming is confusing. Maybe we just drop the
> "EMLSR_EMLMR_" from the *mask* define, and have it only for the
> individual defines, as say
> 
> #define IEEE80211_EML_CAP_EML_TRANSITION_DELAY	0x0070
> #define  IEEE80211_EML_CAP_EMLSR_TRANSITION_DELAY_0US	0
> #define  IEEE80211_EML_CAP_EMLSR_TRANSITION_DELAY_16US	1
> #define  IEEE80211_EML_CAP_EMLSR_TRANSITION_DELAY_32US	2
> ...
> #define  IEEE80211_EML_CAP_EMLMR_TRANSITION_DELAY_32US	1
> ...
> 
> I think that'd also call out that in fact those are (needlessly)
> different.
What about `IEEE80211_EML_CAP_EMLSR_EMLMR_PADDING_DELAY`? It also has
two tables for EMLSR (9-417i) and EMLMR (9-417k) but they have the same
content (as of 802.11be). Do I just rename
`IEEE80211_EML_CAP_EMLSR_PADDING_DELAY_XUS` to
`IEEE80211_EML_CAP_EML_PADDING_DELAY_XUS` or do I split it in two
identical `IEEE80211_EML_CAP_EMLSR_PADDING_DELAY_XUS` &
`IEEE80211_EML_CAP_EMLMR_PADDING_DELAY_XUS` to future proof it in case
of a change in a future amendment?
> > johannes

Pablo MG