Re: [PATCH wireless-next v4 05/21] wifi: nl80211: define interfaces for SMD BSS Transition context transfer

From: Johannes Berg

Date: Tue Nov 10 2026 - 14:00:09 EST


On Fri, 2026-11-06 at 13:28 +0530, Pooventhiran G wrote:
>
> +/**
> + * enum nl80211_smd_ctx_type - SMD Request Type values

This is more "ST request type" or something.

You're conflating "SMD" with "SMD transition" throughout, and the "BSS"
in the subject isn't really supposed to be there

> + * Used with %NL80211_ATTR_SMD_CTX_TYPE.
> + *
> + * @NL80211_SMD_CTX_TYPE_PREP: SMD BSS Transition (ST) Preparation.

(as here)

> + * @NL80211_SMD_CTX_TYPE_EXEC: ST Execution.
> + * @NUM_SMD_CTX_TYPES: internal.
> + * @NL80211_SMD_CTX_TYPE_MAX: Max type of ST context.
> + */
> +enum nl80211_smd_ctx_type {
> + NL80211_SMD_CTX_TYPE_PREP,
> + NL80211_SMD_CTX_TYPE_EXEC,
> +
> + NUM_SMD_CTX_TYPES,
> + NL80211_SMD_CTX_TYPE_MAX = NUM_SMD_CTX_TYPES - 1,
> +};
> +
> +/**
> + * enum nl80211_smd_ctx_ba_param - SMD Block Ack Context attributes
> + *
> + * @__NL80211_SMD_CTX_BA_ATTR_INVALID: Invalid attribute.
> + * @NL80211_SMD_CTX_BA_ATTR_BUFF_SIZE: Required (u16) BA buffer size.
> + * @NL80211_SMD_CTX_BA_ATTR_POLICY: Required (u8) BA policy.
> + * @NL80211_SMD_CTX_BA_ATTR_AMSDU_SUPPORT: Flag attribute to indicate
> + * AMSDU support.
> + * @NL80211_SMD_CTX_BA_ATTR_TIMEOUT: Required (u16) Block Ack timeout.
> + * @NL80211_SMD_CTX_BA_ATTR_EXT_NO_FRAG: Flag attribute to indicate
> + * fragmentation support.
> + * @NL80211_SMD_CTX_BA_ATTR_EXT_FRAG_LEVEL: Required (u8) HE fragmentation
> + * level.
> + * @NL80211_SMD_CTX_BA_ATTR_EXT_BUFF_SIZE: Required (u16) extended buffer size.

Same here as in the other patch - splitting the buffer size into two
variables or attributes seems ridiculous.

> + * @NL80211_SMD_CTX_DL_ATTR_VALID_TID_BITMAP: Optional (u8) TIDs included.

That doesn't really make sense, it just introduces a place where things
can drift - the per TID nested values below already implicitly say which
TIDs are valid.

> +/**
> + * enum nl80211_smd_ctx_ul - SMD Dynamic Context - UL direction

Right now I don't see a lot of value in splitting UL/DL attributes when
they're basically mostly the same - we can probably unify that into one
space and maybe have a few that are one direction or the other only?

johannes