Re: [PATCH wireless-next v4 04/21] wifi: cfg80211: define layouts for SMD BSS Transition context

[Pooventhiran G <pooventhiran.g@oss.qualcomm.com>]

On 11/11/2026 12:09 am, Johannes Berg wrote:
> On Fri, 2026-11-06 at 13:28 +0530, Pooventhiran G wrote:
>> IEEE P802.11bn/D2.0
>>
> 
> It probably didn't change here, but there's D2.1 :)
> 

From the looks of it, D2.1 doesn't seem to modify the context layout but Dual
BA :)

>> +#define IEEE80211_SMD_CTX_MAX_PN_LEN 16
> 
> Huh?
> 

There is no cfg80211-equivalent for IEEE80211_MAX_PN_LEN as defined in mac80211.

>> +/**
>> + * struct ieee80211_smd_ctx_ba - BlockAck parameters for DL and UL
>> + *
>> + * @amsdu_supported: Peer's capability to support A-MSDU within A-MPDU.
>> + * @ba_policy: BlockAck policy (0 = delayed BlockAck, 1 = immediate BlockAck)
>> + * @buffer_size: Reorder buffer size from ADDBA Request (10-bit, max 1023)
> 
> It's probably literally in this spec this way, but I see absolutely no
> reason to split it up like that (with ext_buffer_size) in what's
> effectively an internal API?!
> 

Buffer size was sent this way so that hostapd can directly use that to report
the DL BA Info and UL BA Info in the ST Preparation Response frame (Figure
9-aa53 — Extended BA Parameters Info field format).

I can combine these into one single @buffer_size and let hostapd split it for
preparing the OTA frame (as it is only needed there) but would still need to
send ext_no_frag and extfrag_level as part of the context. Would it be okay?

>> +/**
>> + * struct ieee80211_smd_ctx - IEEE 802.11bn SMD Roaming Context (refer
>> + *	IEEE P802.11bn/D2.0, Aug 2026, subclause 37.16.9)
>> + *
>> + * @dl_sn_valid: if downlink (DL) SN Transfer is requested or not
>> + * @ul_sn_valid: if uplink (UL) SN Transfer is requested or not
> 
> Hmm. It might make more sense to invert that like in the frames?
> 

Sure, will reorder this as UL, DL.

>> + * @pn_valid: if PN is transferred or not
> 
> This being false is not a thing (any more)?
> 

PN is still defined to be transferred in the Prep context (at least as per
D2.0 37.16.9). Even if drivers choose to send this in the Exec context, it may
not be present in both Prep and Exec contexts? Should we make it so that PN is
transferred in both?

>> + * @ba_params_valid: if BlockAck parameters are transferred or not
>> + * @mgmt_tid_valid: if management information is transferred or not.
>> + *	@{d,u}l.mgmt_sn and @ul.mgmt_pn are still bounded by @{d,u}l_sn_valid
>> + *	and @pn_valid fields.
>> + * @pn_len: Length of PN in bytes; varies by cipher type
>> + *	(e.g. CCMP (6), GCMP-256 (16))
> 
> ??
> 

Especially while filling in the data in nl80211 to report to userspace or when
we parse the SET_SMD_CTX from userspace, this eliminates the dependency on
key_conf to derive the length from the cipher type. But is the preference here
exactly that?

> johannes