Re: [PATCH wireless-next v2 10/16] wifi: nl80211: Define attributes to pack SMD BSS Transition context

[Johannes Berg <johannes@sipsolutions.net>]

On Thu, 2026-09-24 at 08:10 +0530, Pooventhiran G wrote:
> Define nl80211 attributes and policies required to pack SMD BSS Transition
> context along with NL80211_CMD_FRAME to be sent to userspace, and to set
> and get the context during roaming via current AP MLD and roaming via
> target AP MLD. Without these, userspace will not be able to transport the
> context to the target AP MLD, program the context on the target AP MLD TX
> and RX queues, nor fetch the context on behalf of the target AP MLD if
> the ST Execution frame is sent directly to the target.

The commit subject and message don't really seem right - you're also
adding all the commands.

> + * @NL80211_CMD_SET_SMD_CTX: Set the SMD BSS Transition dynamic context for a
> + *	non-AP MLD sent from the current AP MLD on the target AP MLD managed by
> + *	an SMD-ME. This command carries %NL80211_ATTR_MLD_ADDR,
> + *	%NL80211_ATTR_SMD_CTX_TYPE and %NL80211_ATTR_SMD_CTX.

This is a bit ... brief. Incomplete, I'd even say. How is it meant to
work, e.g. this carries PN data which fundamentally maps to a key, so it
seems the key must be there before it. Surely the station must be, and
it must be in the right state (whichever that is) etc.

> + * @NL80211_CMD_GET_SMD_CTX: Get the SMD BSS Transition dynamic context for a
> + *	non-AP MLD associated to an AP MLD managed by an SMD-ME. This command
> + *	carries %NL80211_ATTR_MLD_ADDR and %NL80211_ATTR_SMD_CTX_TYPE.
> + * @NL80211_CMD_SMD_CTX_EVENT: Event reporting the collected SMD context
> + *	(requested via %NL80211_CMD_GET_SMD_CTX) to userspace. It carries
> + *	%NL80211_ATTR_MLD_ADDR, %NL80211_ATTR_SMD_CTX_TYPE, and
> + *	%NL80211_ATTR_SMD_CTX.

Why would this be async?

> + * @NL80211_SMD_CTX_ATTR_DRV_DATA: Optional (binary) driver-specific blob.
> + *	Passed through nl80211 as a blob; parsed only at the driver layer of
> + *	the current AP MLD and target AP MLD. First 3 bytes shall be driver OUI
> + *	for the driver to parse as required.

That's just a vendor command through the back-door?

What do you envision this carries, and why couldn't that be defined
properly? Is the intent to have some kind of optional data there, or
would the target possibly refuse the operation if it's not present?

johannes