[PATCH 0/3] EML Capabilities compliance changes

[PATCH 0/3] EML Capabilities compliance changes

[Pablo Martin-Gomez]

There is some discrepencies between our codebase and the final version
of 802.11be-2024 regarding the EML Capabilities field. Given that no
driver supports EMLMR or tries to use 128TUs transition timeout, those
changes should not have any real impact. 

Pablo Martin-Gomez (3):
  wifi: Transition Timeout of 128TUs is not defined
  wifi: EMLMR Delay subfield has been removed
  wifi: Transition/Padding delay subfields are for both EMLSR and EMLMR

 .../net/wireless/intel/iwlwifi/mld/iface.c    |  2 +-
 .../net/wireless/intel/iwlwifi/mld/mac80211.c |  4 +--
 .../net/wireless/intel/iwlwifi/mvm/mac80211.c |  4 +--
 .../net/wireless/mediatek/mt76/mt7925/mcu.c   |  4 +--
 include/linux/ieee80211-eht.h                 | 29 +++++++++++--------
 net/mac80211/eht.c                            |  4 +--
 6 files changed, 26 insertions(+), 21 deletions(-)

-- 
2.43.0

[PATCH 1/3] wifi: Transition Timeout of 128TUs is not defined

[Pablo Martin-Gomez]

In Table 9-417m of 802.11be-2024, Transition Timeout is defined up
to value 10 for a Transition Timeout of 64TUs. The value 11 is reserved
and does not correspond to a Transition Timeout of 128TUs.

Signed-off-by: Pablo Martin-Gomez <pmartin-gomez@freebox.fr>
---
 drivers/net/wireless/intel/iwlwifi/mld/iface.c | 2 +-
 include/linux/ieee80211-eht.h                  | 3 +--
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/mld/iface.c b/drivers/net/wireless/intel/iwlwifi/mld/iface.c
index 46c8d943fd55..756b3ca36105 100644
--- a/drivers/net/wireless/intel/iwlwifi/mld/iface.c
+++ b/drivers/net/wireless/intel/iwlwifi/mld/iface.c
@@ -220,7 +220,7 @@ static void iwl_mld_fill_mac_cmd_sta(struct iwl_mld *mld,
 				     IEEE80211_EML_CAP_TRANSITION_TIMEOUT);
 
 		cmd->client.esr_transition_timeout =
-			min_t(u16, IEEE80211_EML_CAP_TRANSITION_TIMEOUT_128TU,
+			min_t(u16, IEEE80211_EML_CAP_TRANSITION_TIMEOUT_64TU,
 			      esr_transition_timeout);
 		cmd->client.medium_sync_delay =
 			cpu_to_le16(vif->cfg.eml_med_sync_delay);
diff --git a/include/linux/ieee80211-eht.h b/include/linux/ieee80211-eht.h
index a97b1d01f3ac..bbff10a05b48 100644
--- a/include/linux/ieee80211-eht.h
+++ b/include/linux/ieee80211-eht.h
@@ -517,7 +517,6 @@ struct ieee80211_multi_link_elem {
 #define  IEEE80211_EML_CAP_TRANSITION_TIMEOUT_16TU		8
 #define  IEEE80211_EML_CAP_TRANSITION_TIMEOUT_32TU		9
 #define  IEEE80211_EML_CAP_TRANSITION_TIMEOUT_64TU		10
-#define  IEEE80211_EML_CAP_TRANSITION_TIMEOUT_128TU		11
 
 #define IEEE80211_MLD_CAP_OP_MAX_SIMUL_LINKS		0x000f
 #define IEEE80211_MLD_CAP_OP_SRS_SUPPORT		0x0010
@@ -1178,7 +1177,7 @@ static inline u32 ieee80211_eml_trans_timeout_in_us(u16 eml_cap)
 				  IEEE80211_EML_CAP_TRANSITION_TIMEOUT);
 
 	/* invalid values also just use 0 */
-	if (!timeout || timeout > IEEE80211_EML_CAP_TRANSITION_TIMEOUT_128TU)
+	if (!timeout || timeout > IEEE80211_EML_CAP_TRANSITION_TIMEOUT_64TU)
 		return 0;
 
 	return 128 * (1 << (timeout - 1));
-- 
2.43.0

[PATCH 2/3] wifi: EMLMR Delay subfield has been removed

[Pablo Martin-Gomez]

In the finalized version of 802.11be-2024, the EMLMR delay values have
been merged in the EMLSR Padding/Transition Delay subfields and
therefore the subfield EMLMR Delay has been converted to a reserved field.

Signed-off-by: Pablo Martin-Gomez <pmartin-gomez@freebox.fr>
---
 include/linux/ieee80211-eht.h | 6 ------
 1 file changed, 6 deletions(-)

diff --git a/include/linux/ieee80211-eht.h b/include/linux/ieee80211-eht.h
index bbff10a05b48..6324d888073b 100644
--- a/include/linux/ieee80211-eht.h
+++ b/include/linux/ieee80211-eht.h
@@ -499,12 +499,6 @@ struct ieee80211_multi_link_elem {
 #define  IEEE80211_EML_CAP_EMLSR_TRANSITION_DELAY_128US		4
 #define  IEEE80211_EML_CAP_EMLSR_TRANSITION_DELAY_256US		5
 #define IEEE80211_EML_CAP_EMLMR_SUPPORT			0x0080
-#define IEEE80211_EML_CAP_EMLMR_DELAY			0x0700
-#define  IEEE80211_EML_CAP_EMLMR_DELAY_0US			0
-#define  IEEE80211_EML_CAP_EMLMR_DELAY_32US			1
-#define  IEEE80211_EML_CAP_EMLMR_DELAY_64US			2
-#define  IEEE80211_EML_CAP_EMLMR_DELAY_128US			3
-#define  IEEE80211_EML_CAP_EMLMR_DELAY_256US			4
 #define IEEE80211_EML_CAP_TRANSITION_TIMEOUT		0x7800
 #define  IEEE80211_EML_CAP_TRANSITION_TIMEOUT_0			0
 #define  IEEE80211_EML_CAP_TRANSITION_TIMEOUT_128US		1
-- 
2.43.0

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

[Pablo Martin-Gomez]

In the final version of 802.11be-2024, Transition Delay and Padding
Delay subfield are for both EMLSR and EMLMR. Check the EMLSR Support
subfield is set before assuming the delays values are for EMLSR.

Signed-off-by: Pablo Martin-Gomez <pmartin-gomez@freebox.fr>
---
 .../net/wireless/intel/iwlwifi/mld/mac80211.c |  4 ++--
 .../net/wireless/intel/iwlwifi/mvm/mac80211.c |  4 ++--
 .../net/wireless/mediatek/mt76/mt7925/mcu.c   |  4 ++--
 include/linux/ieee80211-eht.h                 | 20 +++++++++++++++----
 net/mac80211/eht.c                            |  4 ++--
 5 files changed, 24 insertions(+), 12 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/mld/mac80211.c b/drivers/net/wireless/intel/iwlwifi/mld/mac80211.c
index e3aec814aa0d..8becd80689d8 100644
--- a/drivers/net/wireless/intel/iwlwifi/mld/mac80211.c
+++ b/drivers/net/wireless/intel/iwlwifi/mld/mac80211.c
@@ -115,9 +115,9 @@ static const u8 ext_capa_base[IWL_MLD_STA_EXT_CAPA_SIZE] = {
 
 #define IWL_MLD_EMLSR_CAPA	(IEEE80211_EML_CAP_EMLSR_SUPP | \
 				 IEEE80211_EML_CAP_EMLSR_PADDING_DELAY_32US << \
-					__bf_shf(IEEE80211_EML_CAP_EMLSR_PADDING_DELAY) | \
+					__bf_shf(IEEE80211_EML_CAP_EMLSR_EMLMR_PADDING_DELAY) | \
 				 IEEE80211_EML_CAP_EMLSR_TRANSITION_DELAY_64US << \
-					__bf_shf(IEEE80211_EML_CAP_EMLSR_TRANSITION_DELAY))
+					__bf_shf(IEEE80211_EML_CAP_EMLSR_EMLMR_TRANSITION_DELAY))
 #define IWL_MLD_CAPA_OPS (FIELD_PREP_CONST( \
 			IEEE80211_MLD_CAP_OP_TID_TO_LINK_MAP_NEG_SUPP, \
 			IEEE80211_MLD_CAP_OP_TID_TO_LINK_MAP_NEG_SUPP_SAME) | \
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
index 1ec9807e4827..099c0dbfd4eb 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
@@ -264,9 +264,9 @@ static const u8 tm_if_types_ext_capa_sta[] = {
 
 #define IWL_MVM_EMLSR_CAPA	(IEEE80211_EML_CAP_EMLSR_SUPP | \
 				 IEEE80211_EML_CAP_EMLSR_PADDING_DELAY_32US << \
-					__bf_shf(IEEE80211_EML_CAP_EMLSR_PADDING_DELAY) | \
+					__bf_shf(IEEE80211_EML_CAP_EMLSR_EMLMR_PADDING_DELAY) | \
 				 IEEE80211_EML_CAP_EMLSR_TRANSITION_DELAY_64US << \
-					__bf_shf(IEEE80211_EML_CAP_EMLSR_TRANSITION_DELAY))
+					__bf_shf(IEEE80211_EML_CAP_EMLSR_EMLMR_TRANSITION_DELAY))
 #define IWL_MVM_MLD_CAPA_OPS (FIELD_PREP_CONST( \
 			IEEE80211_MLD_CAP_OP_TID_TO_LINK_MAP_NEG_SUPP, \
 			IEEE80211_MLD_CAP_OP_TID_TO_LINK_MAP_NEG_SUPP_SAME) | \
diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c
index 37cdf3e8a067..b54a10418ce3 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c
@@ -1880,8 +1880,8 @@ mt7925_mcu_sta_eht_mld_tlv(struct sk_buff *skb,
 
 	eml_cap = (vif->cfg.eml_cap & (IEEE80211_EML_CAP_EMLSR_SUPP |
 				       IEEE80211_EML_CAP_TRANSITION_TIMEOUT)) |
-		  (ext_capa->eml_capabilities & (IEEE80211_EML_CAP_EMLSR_PADDING_DELAY |
-						IEEE80211_EML_CAP_EMLSR_TRANSITION_DELAY));
+		  (ext_capa->eml_capabilities & (IEEE80211_EML_CAP_EMLSR_EMLMR_PADDING_DELAY |
+						IEEE80211_EML_CAP_EMLSR_EMLMR_TRANSITION_DELAY));
 
 	if (eml_cap & IEEE80211_EML_CAP_EMLSR_SUPP) {
 		eht_mld->eml_cap[0] = u16_get_bits(eml_cap, GENMASK(7, 0));
diff --git a/include/linux/ieee80211-eht.h b/include/linux/ieee80211-eht.h
index 6324d888073b..b52cab33bcf1 100644
--- a/include/linux/ieee80211-eht.h
+++ b/include/linux/ieee80211-eht.h
@@ -485,13 +485,13 @@ struct ieee80211_multi_link_elem {
 #define IEEE80211_MED_SYNC_DELAY_DEFAULT		0x10ac
 
 #define IEEE80211_EML_CAP_EMLSR_SUPP			0x0001
-#define IEEE80211_EML_CAP_EMLSR_PADDING_DELAY		0x000e
+#define IEEE80211_EML_CAP_EMLSR_EMLMR_PADDING_DELAY		0x000e
 #define  IEEE80211_EML_CAP_EMLSR_PADDING_DELAY_0US		0
 #define  IEEE80211_EML_CAP_EMLSR_PADDING_DELAY_32US		1
 #define  IEEE80211_EML_CAP_EMLSR_PADDING_DELAY_64US		2
 #define  IEEE80211_EML_CAP_EMLSR_PADDING_DELAY_128US		3
 #define  IEEE80211_EML_CAP_EMLSR_PADDING_DELAY_256US		4
-#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
@@ -1114,11 +1114,17 @@ static inline bool ieee80211_tid_to_link_map_size_ok(const u8 *data, size_t len)
 
 static inline u32 ieee80211_emlsr_pad_delay_in_us(u16 eml_cap)
 {
+	u32 elmsr_supp =
+		u16_get_bits(eml_cap, IEEE80211_EML_CAP_EMLSR_SUPP);
+
+	if (!elmsr_supp)
+		return 0;
+
 	/* IEEE Std 802.11be-2024 Table 9-417i—Encoding of the EMLSR
 	 * Padding Delay subfield.
 	 */
 	u32 pad_delay = u16_get_bits(eml_cap,
-				     IEEE80211_EML_CAP_EMLSR_PADDING_DELAY);
+				     IEEE80211_EML_CAP_EMLSR_EMLMR_PADDING_DELAY);
 
 	if (!pad_delay ||
 	    pad_delay > IEEE80211_EML_CAP_EMLSR_PADDING_DELAY_256US)
@@ -1138,12 +1144,18 @@ static inline u32 ieee80211_emlsr_pad_delay_in_us(u16 eml_cap)
 
 static inline u32 ieee80211_emlsr_trans_delay_in_us(u16 eml_cap)
 {
+	u32 elmsr_supp =
+		u16_get_bits(eml_cap, IEEE80211_EML_CAP_EMLSR_SUPP);
+
+	if (!elmsr_supp)
+		return 0;
+
 	/* IEEE Std 802.11be-2024 Table 9-417j—Encoding of the EMLSR
 	 * Transition Delay subfield.
 	 */
 	u32 trans_delay =
 		u16_get_bits(eml_cap,
-			     IEEE80211_EML_CAP_EMLSR_TRANSITION_DELAY);
+			     IEEE80211_EML_CAP_EMLSR_EMLMR_TRANSITION_DELAY);
 
 	/* invalid values also just use 0 */
 	if (!trans_delay ||
diff --git a/net/mac80211/eht.c b/net/mac80211/eht.c
index 768bfc4e737d..89c4b7b7e8c8 100644
--- a/net/mac80211/eht.c
+++ b/net/mac80211/eht.c
@@ -217,11 +217,11 @@ void ieee80211_rx_eml_op_mode_notif(struct ieee80211_sub_if_data *sdata,
 			sta->sta.eml_cap =
 				u8_replace_bits(sta->sta.eml_cap,
 						pad_delay,
-						IEEE80211_EML_CAP_EMLSR_PADDING_DELAY);
+						IEEE80211_EML_CAP_EMLSR_EMLMR_PADDING_DELAY);
 			sta->sta.eml_cap =
 				u8_replace_bits(sta->sta.eml_cap,
 						trans_delay,
-						IEEE80211_EML_CAP_EMLSR_TRANSITION_DELAY);
+						IEEE80211_EML_CAP_EMLSR_EMLMR_TRANSITION_DELAY);
 		}
 	}
 
-- 
2.43.0

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

[Johannes Berg]

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.

And then another thing - I was going to apply the other two patches, but
really then looked at my git log and saw that no, really, the subjects
are stating a spec thing rather than describing a change, so please fix
that too.

johannes

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

[Pablo MARTIN-GOMEZ]

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.

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
[...]
```

If you prefer, I can implement it +
`ieee80211_emlmr_[trans/pad]_delay_in_us` but it will be dead code for now.

> 
> And then another thing - I was going to apply the other two patches, but
> really then looked at my git log and saw that no, really, the subjects
> are stating a spec thing rather than describing a change, so please fix
> that too.
I'll fix that in a v2
> 
> johannes

Pablo MG

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

[Johannes Berg]

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

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

[Pablo MARTIN-GOMEZ]

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

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

[Johannes Berg]

On Thu, 2026-04-09 at 11:04 +0200, Pablo MARTIN-GOMEZ wrote:
> 
> 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?
> > 

It isn't going to change, this field will need to stay around like this
forever, only thing the spec could do is add new values (i.e. use some
currently reserved values), but even that is tricky ... So I don't think
we need to consider future changes here. I'd probably just rename it,
but it doesn't matter all that much?

johannes

Re: [PATCH 0/3] EML Capabilities compliance changes

[Johannes Berg]

On Fri, 2026-03-27 at 21:11 +0100, Pablo Martin-Gomez wrote:
> There is some discrepencies between our codebase and the final version
> of 802.11be-2024 regarding the EML Capabilities field. Given that no
> driver supports EMLMR or tries to use 128TUs transition timeout, those
> changes should not have any real impact. 

Heh, funny, I noticed this a while ago too - it must've been in an
earlier draft. And UHR has the same - but *does* (for now :) ) define
128 TU (which is why I noticed it.)

johannes