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

[Johannes Berg <johannes@sipsolutions.net>]

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.

johannes