From: Johannes Berg <johannes@sipsolutions.net>
To: Pooventhiran G <pooventhiran.g@oss.qualcomm.com>
Cc: linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH wireless-next v4 10/21] wifi: nl80211/cfg80211: add support for querying SMD context for target AP MLD
Date: Tue, 10 Nov 2026 20:00:34 +0100 [thread overview]
Message-ID: <29b38fc6c8a5f1b2b58d81c1a9046308d2ca9e2d.camel@sipsolutions.net> (raw)
In-Reply-To: <20261106-smd-v4-10-62e39487f51a@oss.qualcomm.com>
On Fri, 2026-11-06 at 13:28 +0530, Pooventhiran G wrote:
>
> +/**
> + * struct cfg80211_smd_get_ctx_pending - pending async GET_SMD_CTX request
> + * @list: linkage on wireless_dev::smd_get_ctx_pending_list
> + * @sta_addr: non-AP MLD address for which context was requested
> + * @dev_tracker: tracker object for the netdev referenced
> + */
> +struct cfg80211_smd_get_ctx_pending {
> + struct list_head list;
> + u8 sta_addr[ETH_ALEN];
> + netdevice_tracker dev_tracker;
> +};
This seems ridiculous, if userspace sets the interface down it might get
a stale response, but you're writing dozens of lines of code just to
avoid _that_?
Maybe also to avoid querying the same STA twice but if the firmware
can't cope with it then it can still reject it (or the driver), is there
really a good reason to have all this complexity to prevent it?
Tracing on the output path, on the other hand, would be useful?
johannes
next prev parent reply other threads:[~2026-11-10 19:00 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-06 7:58 [PATCH wireless-next v4 00/21] wifi: Add Seamless Mobility Domain (SMD) AP support Pooventhiran G
2026-11-06 7:58 ` [PATCH wireless-next v4 01/21] wifi: nl80211: define Seamless Mobility Domain (SMD) device capability Pooventhiran G
2026-11-10 14:15 ` Johannes Berg
2026-11-10 14:26 ` Johannes Berg
2026-11-06 7:58 ` [PATCH wireless-next v4 02/21] wifi: nl80211/cfg80211: define interfaces for SMD setup and STA update Pooventhiran G
2026-11-10 18:18 ` Johannes Berg
2026-11-06 7:58 ` [PATCH wireless-next v4 03/21] wifi: nl80211: add SMD BSS Transition sub-state STA flags Pooventhiran G
2026-11-10 18:27 ` Johannes Berg
2026-11-06 7:58 ` [PATCH wireless-next v4 04/21] wifi: cfg80211: define layouts for SMD BSS Transition context Pooventhiran G
2026-11-10 18:39 ` Johannes Berg
2026-11-06 7:58 ` [PATCH wireless-next v4 05/21] wifi: nl80211: define interfaces for SMD BSS Transition context transfer Pooventhiran G
2026-11-10 18:45 ` Johannes Berg
2026-11-06 7:58 ` [PATCH wireless-next v4 06/21] wifi: ieee80211: define APIs for UHR Link Reconfiguration frame checks Pooventhiran G
2026-11-06 7:58 ` [PATCH wireless-next v4 07/21] wifi: ieee80211: define API to check if frame is class 3 Pooventhiran G
2026-11-06 7:58 ` [PATCH wireless-next v4 08/21] wifi: nl80211/cfg80211: pack SMD dynamic context along with frame Pooventhiran G
2026-11-10 18:51 ` Johannes Berg
2026-11-06 7:58 ` [PATCH wireless-next v4 09/21] wifi: nl80211/cfg80211: add support for SMD context programming Pooventhiran G
2026-11-10 18:55 ` Johannes Berg
2026-11-06 7:58 ` [PATCH wireless-next v4 10/21] wifi: nl80211/cfg80211: add support for querying SMD context for target AP MLD Pooventhiran G
2026-11-10 19:00 ` Johannes Berg [this message]
2026-11-06 7:58 ` [PATCH wireless-next v4 11/21] wifi: nl80211/cfg80211: define API to notify SMD Drain completion Pooventhiran G
2026-11-10 19:01 ` Johannes Berg
2026-11-06 7:58 ` [PATCH wireless-next v4 12/21] wifi: mac80211: set SMD parameters for AP setup and STA update Pooventhiran G
2026-11-06 7:58 ` [PATCH wireless-next v4 13/21] wifi: mac80211: apply SMD BSS Transition STA sub-states Pooventhiran G
2026-11-06 7:58 ` [PATCH wireless-next v4 14/21] wifi: mac80211: add driver_op for SMD substate changes Pooventhiran G
2026-11-06 7:58 ` [PATCH wireless-next v4 15/21] wifi: mac80211: filter uplink and downlink frames based on SMD states Pooventhiran G
2026-11-06 7:58 ` [PATCH wireless-next v4 16/21] wifi: mac80211: send BlockAck policy in AMPDU action Pooventhiran G
2026-11-06 7:58 ` [PATCH wireless-next v4 17/21] wifi: mac80211: pass rx_data directly from ieee80211_rx_list() Pooventhiran G
2026-11-06 7:58 ` [PATCH wireless-next v4 18/21] wifi: mac80211: handle UHR Link Reconfiguration frame Pooventhiran G
2026-11-06 7:58 ` [PATCH wireless-next v4 19/21] wifi: mac80211: add mac80211 support to handle NL80211_CMD_SET_SMD_CTX Pooventhiran G
2026-11-06 7:58 ` [PATCH wireless-next v4 20/21] wifi: mac80211: add mac80211 support to handle NL80211_CMD_GET_SMD_CTX Pooventhiran G
2026-11-06 7:58 ` [PATCH wireless-next v4 21/21] wifi: mac80211: define API to invoke SMD Drain Completion event Pooventhiran G
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=29b38fc6c8a5f1b2b58d81c1a9046308d2ca9e2d.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=pooventhiran.g@oss.qualcomm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®