Re: [PATCH wireless-next v4 08/21] wifi: nl80211/cfg80211: pack SMD dynamic context along with frame

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

On 11/11/2026 02:44 pm, Allen Ye wrote:
> On Fri, 2026-11-06 at 13:28 +0530, Pooventhiran G wrote:
> 
> Hi Pooventhiran,
> 
> A question on how the context is collected here.
> 
>> While packing the received management frame in nl80211_send_mgmt() to
>> send to userspace, nest the SMD dynamic context along with the frame
>> message.
> 
> On MediaTek chipsets (mt76), the dynamic context is kept in FW/HW, so
> the driver has to fetch it from the firmware with an MCU command. This
> means the driver has to hold the ST request frame until the firmware
> replies with an event, and only then pass the frame up. Holding RX
> frames in the driver is the problematic part: the frame has to be kept
> outside the normal RX path, kept in order with the frames that follow
> it, and handled if the firmware reply is delayed or never arrives.
> 
> 1. With the context attached to the frame, how it gets collected
> depends on each vendor driver's own implementation (on mt76, this may
> mean holding the frame in the driver as described above). If userspace
> instead queried it via GET_SMD_CTX / SMD_CTX_EVENT for ST preparation
> and ST execution via the current AP MLD, as it already does for ST
> execution via the target AP MLD, the flow would be the same for every
> driver, regardless of where the context is kept. Would that be
> acceptable?
> 
> 2. If not, could the frame-attached context be optional (e.g. behind a
> capability flag), with userspace falling back to GET_SMD_CTX?
> 

Hi Allen. Sure, that option could also be added if some drivers choose not to
pack in the rx_mgmt frame itself. Since it will be a fallback, I can change
hostapd to directly query the driver for context using GET_SMD_CTX if it does
not find the context attached to the received frame?

> Thanks,
> Allen