On 5/15/2025 5:04 PM, Johannes Berg wrote:
Oh ... missed this one when I sent the other mail. And really this is
the one that I saw and decided not to continue fixing things up myself.
On Thu, 2025-05-15 at 11:18 +0530, Sarika Sharma wrote:
@@ -6880,7 +7062,8 @@ static int nl80211_send_station(struct sk_buff *msg, u32 cmd, u32 portid,
#undef PUT_SINFO
#undef PUT_SINFO_U64
- if (sinfo->pertid) {
+ if ((sinfo->filled & BIT_ULL(NL80211_STA_INFO_TID_STATS)) &&
+ sinfo->pertid) {
This breaks mac80211 at this point. You also never even mention it in
the commit log.
oops! Yes correct with this the pertid will not be reported to user-space.
Ultimately, I see why you did it, but that's really not how we do
things. If we cannot get away without this, then it really needs to be
split out into separate patch that doesn't break mac80211. The change to
fix mac80211 is also randomly interleaved into a commit that doesn't
even mention it.
Sure, let me introduce this as a separate patch.
Yes, this is needed when we don't really want to report the pertid at
MLO level( as currently pertid is one of links data(deflink) for MLO).
or may be we can directly free the pertid memory in case of MLO in
cfg80211 instead of relying on sinfo->filled bit for tid?
I would prefer to not do this, but if we really need it then you need to
split out this API change and do that properly while fixing all the
users.
johannes
