On 5/15/2025 12:04 PM, Kang Yang wrote:
On 5/6/2025 6:56 PM, Rameshkumar Sundaram wrote:
When two split-phy devices that support overlapping frequency ranges
within
the same band are grouped into an ath12k hardware (HW) setup, they
share a
common wiphy instance. Consequently, the channel list (wiphy->bands[])
becomes unified across all associated radios (ar).
For reference, the devices are:
2.4 GHz + 5 GHz Low Band
5 GHz High Band + 6 GHz
The first radio probed within the 5 GHz range (say 5 GHz Low Band)
updates
its sband reference (&ar->mac.sbands[NL80211_BAND_5GHZ]) within
wiphy->bands[]. However, when the second 5 GHz radio (5 GHz High Band) is
probed, it replaces the existing wiphy->bands[] entry with its own
sub-band
reference. As a result, wiphy->bands[] always reflects the channel list
from the most recently probed radio in that band, restricting supported
channels to those within its specific range for upper-layer.
Fix this by updating the wiphy->bands[] to just enable the channels of
current radio when there exist a radio which already has set it.
This will make sure wiphy->bands[] holds reference of first radio which
got probed in 5 GHz band and subsequent radio just updates the channel
list
in the same address space.
Since same sband memory space is shared between radios of a band, while
determining the allowed frequency range of radio, its frequency limits
(ar->freq_range.start_freq, end_freq) should be used.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1
Offline sync with aditya:
This patch and patch [1][2] will make WCN7850 update regulatory rules
and trigger scan incorrectly.
They are based on the design that one chip only supports one band.
This design will limit WCN7850 to one band.
During init, WCN7850 will be limited to one band(such as 5G band) due to
patch[1]. Then will only update 5G regulatory rules and trigger 5G scan.
If manually set country code by "iw reg set XX", WCN7850 will be limited
to 2G band due to patch[2]. Then similar issue will happen.
If QCN supports multi bands like WCN i think you will have the same
problem.
WIN team needs to figure a new design for this issue to support multi
bands on one chip too.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git/commit/?
h=pending&id=b7544de8a2984e61b95c58c1c6c1e8ce659b1021
[2] https://git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git/commit/?
h=pending&id=13324cecbb2c390a11f1fbfe87f3a5e62d6e4591
Thanks for pointing this out. we're working on a new change which fixes
the frequency range marking in [1] & [2] for multi-band ar's, Will re
base this patch on top it once it lands in public.
Signed-off-by: Rameshkumar Sundaram
<rameshkumar.sundaram@xxxxxxxxxxxxxxxx>
---
*v2:
- Fixed frequency conversion from KHZ to MHZ in freq_to_idx()
---
drivers/net/wireless/ath/ath12k/mac.c | 93 +++++++++++++++++++++++++--
drivers/net/wireless/ath/ath12k/reg.c | 13 ++++
drivers/net/wireless/ath/ath12k/wmi.c | 9 ++-
3 files changed, 109 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ath/ath12k/mac.c b/drivers/net/
wireless/ath/ath12k/mac.c
index 4dae941c9615..23cbf348e836 100644
--- a/drivers/net/wireless/ath/ath12k/mac.c
+++ b/drivers/net/wireless/ath/ath12k/mac.c
@@ -4131,8 +4131,9 @@ ath12k_mac_select_scan_device(struct
ieee80211_hw *hw,
band = NL80211_BAND_6GHZ;
for_each_ar(ah, ar, i) {
- /* TODO 5 GHz low high split changes */
- if (ar->mac.sbands[band].channels)
+ if (ar->mac.sbands[band].channels &&
+ center_freq >= KHZ_TO_MHZ(ar->freq_range.start_freq) &&
+ center_freq <= KHZ_TO_MHZ(ar->freq_range.end_freq))
Though WCN7850 won't reach here, but this is also not good for those
chips who support multi bands.
