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

[Pooventhiran G]

On 10/02/2026 01:49 am, Johannes Berg wrote:
> 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.
> 

True, I will fix it.

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

I will update the documentation to mention the required STA state.

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

In ath12k implementation, firmware and hardware are queried to get these
information (SN, PN, etc.,) and the time to collate all these data across all
valid TIDs varies based on system loads. So, not to hold the NL socket for
(arbitrary) longer periods, I have made this asynchronous to cleanly report
back with all the required data once they are available.

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

Driver data had mgmt information and WinStartO equivalents. But I will move
these to generic definitions so that this can be eliminated.

> johannes