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

[Johannes Berg]

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 :)

> +#define IEEE80211_SMD_CTX_MAX_PN_LEN 16

Huh?

> +/**
> + * 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?!

> +/**
> + * 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?

> + * @pn_valid: if PN is transferred or not

This being false is not a thing (any more)?

> + * @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))

??

johannes