From: Ping-Ke Shih <pkshih@realtek.com>
To: Johannes Berg <johannes@sipsolutions.net>,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: RE: [PATCH 2/2] wifi: mac80211: improve station iteration ergonomics
Date: Wed, 11 Feb 2026 08:08:35 +0000 [thread overview]
Message-ID: <1f97fc3a40304dd49e494f2eaa35973d@realtek.com> (raw)
In-Reply-To: <ba29951035ed17f666687db24debbb9c2dd6f30f.camel@sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> wrote:
> On Wed, 2026-02-11 at 06:49 +0000, Ping-Ke Shih wrote:
> > Hi Johannes,
> >
> > > +/**
> > > + * for_each_station - iterate stations under wiphy mutex
> > > + * @sta: the iterator variable
> > > + * @hw: the HW to iterate for
> > > + */
> > > +#define for_each_station(sta, hw) \
> > > + for (sta = __ieee80211_iterate_stations(hw, NULL); \
> > > + sta; \
> > > + sta = __ieee80211_iterate_stations(hw, sta))
> > > +
> >
> > I'm going to use for_each_station() in rtw89 driver, and the code in driver side
> > looks very simple! Thanks for this new API.
> >
> > However, without other callers rather than ieee80211_iterate_xxx(), I'd like
> > to know if it is expected that driver uses for_each_station()? Since help
> > text is added, I think it can be, right?
>
> Yeah definitely, I wouldn't have added it to mac80211.h otherwise. I'm
> already using it in our driver, those patches just haven't gone upstream
> yet.
>
> > Another question is that adding ieee80211_ prefix would be consistent with
> > other API? If you agree, I can make patches.
> >
> > As well as for_each_interface().
>
> Yeah that's a good question I guess. There's some precedent either way,
> e.g. for_each_netdev() and netdev_for_each_uc_addr(), though it's a bit
> more along the lines of "object_for_each_member()" rather than
> "subsystem_for_each_something()" - which would be more like
> ieee80211_hw_for_each_station() here? The notable exception to this
> being damon_*. And objects are also missing, we have for_each_netdev(),
> not netns_for_each_netdev().
>
> Oh and the order of arguments is also not consistent anywhere it seems.
> list_for_each_entry() is "iter, list, member", whereas for_each_netdev()
> is "net, iter".
>
> I suppose I have no strong opinion about it, there doesn't really seem
> to be _any_ consistency around it. Maybe we should be consistent overall
> with them though in mac80211.h, and if renaming not just do the new
> ones? And maybe that's not worth the churn?
>
> Yeah I don't know what to say I guess, I suppose that means if you feel
> strongly one or the other is better I'm happy to adjust :)
I don't have strong opinion to either one. Let's keep as it was. :)
Ping-Ke
prev parent reply other threads:[~2026-02-11 8:08 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-08 13:34 [PATCH 1/2] wifi: mac80211: improve interface iteration ergonomics Johannes Berg
2026-01-08 13:34 ` [PATCH 2/2] wifi: mac80211: improve station " Johannes Berg
2026-02-11 6:49 ` Ping-Ke Shih
2026-02-11 7:54 ` Johannes Berg
2026-02-11 8:08 ` Ping-Ke Shih [this message]
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=1f97fc3a40304dd49e494f2eaa35973d@realtek.com \
--to=pkshih@realtek.com \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.