HACK/RFC: Fix link_sta->rx_nss == 0 in iwlwifi upon eMLSR link change.

Commit Message

Ben Greear July 16, 2024, 11:25 p.m. UTC

While poking around at some instability and poor performance seen in download
direction, I noticed that the rate-ctrl was probably set incorrectly in
the iwlwifi driver due to link_sta->rx_nss being zero when changing active link
to the secondary link (the one we didn't originally associate with).

After debugging, I found that the hack below will make this problem
go away.  I sincerely doubt this is the correct approach, but I'm not
sure how it is all supposed to work in the first place.

And as a side note, even once this is fixed, download throughput still suffers
much of the time.  AP may be buggy, it is hard to tell where the fault lies.

Thanks,
Ben

Patch

diff --git a/net/mac80211/rate.c b/net/mac80211/rate.c
index 4dc1def69548..b69d0eb250d6 100644
--- a/net/mac80211/rate.c
+++ b/net/mac80211/rate.c
@@ -39,6 +39,27 @@  void rate_control_rate_init(struct sta_info *sta)

         ieee80211_sta_init_nss(&sta->deflink);

+       pr_info("rate: sta-init-nss called from rate-control-rate-init, nss: %d\n",
+               sta->deflink.pub->rx_nss);
+
+       {
+               int z;
+
+               for (z = 0; z<IEEE80211_MLD_MAX_NUM_LINKS; z++) {
+                       struct link_sta_info *ls =
+                               rcu_dereference_protected(sta->link[z],
+                                                         lockdep_is_held(&local->hw.wiphy->mtx));
+                       if (!ls)
+                               continue;
+                       if (ls == &sta->deflink)
+                               continue;
+
+                       pr_info("rate: rate-control-rate-init, setting other link rx_nss from: %d to %d  link-id: %d\n",
+                               ls->pub->rx_nss, sta->deflink.pub->rx_nss, z);
+                       ls->pub->rx_nss = sta->deflink.pub->rx_nss;
+               }
+       }
+
         if (!ref)
                 return;