The IEEE80211_TX_CTRL_MLO_LINK info is the only part of
ieee80211_tx_control where a 0 value has a specific meaning. Thus this
should always be initialized with IEEE80211_LINK_UNSPECIFIED if there is
no MLO link information associated with the skb, even using when 802.11
hw encap offloading.

Signed-off-by: Remi Pommarel <repk@triplefau.lt>
---
 net/mac80211/tx.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 6fa883a9250d..1d6b976bba72 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -4638,6 +4638,8 @@ static void ieee80211_8023_xmit(struct ieee80211_sub_if_data *sdata,
 
 	info->flags |= IEEE80211_TX_CTL_HW_80211_ENCAP;
 	info->control.vif = &sdata->vif;
+	info->control.flags |= u32_encode_bits(IEEE80211_LINK_UNSPECIFIED,
+					       IEEE80211_TX_CTRL_MLO_LINK);
 
 	if (key)
 		info->control.hw_key = &key->conf;
-- 
2.40.0

On Fri, 2025-07-11 at 12:03 +0200, Remi Pommarel wrote:
> The IEEE80211_TX_CTRL_MLO_LINK info is the only part of
> ieee80211_tx_control where a 0 value has a specific meaning. Thus this
> should always be initialized with IEEE80211_LINK_UNSPECIFIED if there is
> no MLO link information associated with the skb, even using when 802.11
> hw encap offloading.

I'm not against this and the patch looks fine, but I guess I'm surprised
it even matters to anyone. The encap offloading fundamentally requires
that the driver do more work to identify the destination STA, and then
anyway the link is picked by driver/FW? Or is there a case of encap
offload with _multicast_?

Anyway, looks OK and just sets a few bits that I feel like it's weird
that they're even used, so doesn't matter :)

johannes