mbox series

[0/7] wifi: cfg80211/mac80211: add support for HE BSS color handling with Multi-Link Operation

Message ID 20240416045943.576656-1-quic_adisi@quicinc.com (mailing list archive)
Headers show
Series wifi: cfg80211/mac80211: add support for HE BSS color handling with Multi-Link Operation | expand

Message

Aditya Kumar Singh April 16, 2024, 4:59 a.m. UTC
Currently, deflink (or link_id 0) is always considered while handling HE
BSS color. However, with Multi-Link Operation (MLO), there is a need to
handle link specific data structures based on the actual operational
link_id.

Hence, add support for the same. Non-MLO based operations will continue to
use link_id as 0 or deflink member as applicable.

At the same time, add support for BSS color by mac80211_hwsim.

Aditya Kumar Singh (7):
  wifi: cfg80211: send link id in color_change ops
  wifi: cfg80211: notify link ID in bss_color_notify
  wifi: mac80211: handle set color_change/after_color_change beacon on
    per link basis
  wifi: mac80211: handle color_change_abort and bss_config_notify on per
    link
  wifi: mac80211: start and finalize color change on link basis
  wifi: mac80211: add support to call color_change and OBSS collision on
    a link
  wifi: mac80211_hwsim: add support for BSS color
---
 drivers/net/wireless/ath/ath11k/mac.c         |   2 +-
 drivers/net/wireless/ath/ath11k/wmi.c         |   3 +-
 .../net/wireless/mediatek/mt76/mt7915/mcu.c   |   2 +-
 .../net/wireless/mediatek/mt76/mt7996/mcu.c   |   2 +-
 drivers/net/wireless/virtual/mac80211_hwsim.c |   6 +
 include/net/cfg80211.h                        |  29 ++--
 include/net/mac80211.h                        |   6 +-
 net/mac80211/cfg.c                            | 138 ++++++++++++------
 net/mac80211/rx.c                             |   7 +-
 net/wireless/nl80211.c                        |  10 +-
 net/wireless/trace.h                          |   6 +-
 11 files changed, 144 insertions(+), 67 deletions(-)


base-commit: d26a0a66f9290a3665e283826637722507af5ce3

Comments

Johannes Berg April 19, 2024, 9:12 a.m. UTC | #1
Sparse complains on these patches. I think everyone at QCA should be
able to *consistently* run that.

Jeff, do you really have no internal processes, it all depends on people
running checks manually? We have our own internal tree first, where CI
enforces a whole bunch of things, and *then* we send patches out.

That obviously *still* misses things and I need to review etc., but
getting the trivial bits sorted out before the patches even hit the list
would be useful.

(Also not sure why no bots complained about this set, it's been a few
days, but who knows, maybe they're just behind.)

Also this set needs a rebase now with the kernel-doc update, but I was
even willing to do that.

johannes
Aditya Kumar Singh April 22, 2024, 4:58 a.m. UTC | #2
On 4/19/24 14:42, Johannes Berg wrote:
> Sparse complains on these patches. I think everyone at QCA should be
> able to *consistently* run that.
> 

Oops! I don't know for some reason, this got missed in my manual run. Or 
well I was using sparse from Ubuntu (apt-get install sparse) which might 
not be the latest (and that prints a lot of warnings on ToT itself).

However, now I tested on ToT from sparse.git and I see it complaining. 
Let me fix that and send next version.

> (Also not sure why no bots complained about this set, it's been a few
> days, but who knows, maybe they're just behind.)
>

Yeah even I'm surprised how come bot is not able to catch it. But yeah, 
missed from my side as well, sorry for that.


> Also this set needs a rebase now with the kernel-doc update, but I was
> even willing to do that.
> 

Sure will rebase it.
Jeff Johnson April 23, 2024, 6:37 p.m. UTC | #3
On 4/19/2024 2:12 AM, Johannes Berg wrote:
> Sparse complains on these patches. I think everyone at QCA should be
> able to *consistently* run that.
> 
> Jeff, do you really have no internal processes, it all depends on people
> running checks manually? We have our own internal tree first, where CI
> enforces a whole bunch of things, and *then* we send patches out.

We are trying to get there but, as the community knows, Qualcomm has
historically had a "downstream first" mentality, so all of our automation is
built around that.

The good news is that there has recently been a massive shift in philosophy
(and one reason why after many years of working on the downstream Android
driver I moved to the upstream driver).

At Linaro Connect 2023
(<https://www.qualcomm.com/developer/blog/2023/06/highlights-linaro-connect-2023>)
Leendert van Doorn, SVP of Engineering, announced "Qualcomm is about to adopt
a developer first strategy" and "embrace open source and its upstream
contribution model."

So more resources are being directed at upstream, including updating CI to
support that.

In the meantime, in my personal semi-automated review workflow I run sparse
via ath1*k-check, but unfortunately that only looks in
drivers/net/wireless/ath/ath1*k. I have now updated my workflow to check all
of the files that are modified by a given patchset, and that flagged:

net/mac80211/cfg.c:4847:1: warning: context imbalance in
'ieee80211_obss_color_collision_notify' - different lock contexts for basic block

So hopefully in the future I'll catch issues like these internally, before
they escape into public.

/jeff