From: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
To: Kang Yang <kang.yang@oss.qualcomm.com>,
ath12k@lists.infradead.org,
Jeff Johnson <jeff.johnson@oss.qualcomm.com>,
aditya.kumar.singh@oss.qualcomm.com
Cc: linux-wireless@vger.kernel.org
Subject: Re: [PATCH ath-next v2] wifi: ath12k: combine channel list for split-phy devices in single-wiphy
Date: Mon, 19 May 2025 09:06:43 +0530 [thread overview]
Message-ID: <b4138c8a-5b09-4d17-9151-bd60d511aca3@oss.qualcomm.com> (raw)
In-Reply-To: <7db2e4b5-377c-4d3b-b51f-290accc9ddd9@oss.qualcomm.com>
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@oss.qualcomm.com>
>> ---
>>
>> *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.
prev parent reply other threads:[~2025-05-19 3:36 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-06 10:56 [PATCH ath-next v2] wifi: ath12k: combine channel list for split-phy devices in single-wiphy Rameshkumar Sundaram
2025-05-06 14:50 ` Vasanthakumar Thiagarajan
2025-05-15 6:34 ` Kang Yang
2025-05-19 3:36 ` Rameshkumar Sundaram [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=b4138c8a-5b09-4d17-9151-bd60d511aca3@oss.qualcomm.com \
--to=rameshkumar.sundaram@oss.qualcomm.com \
--cc=aditya.kumar.singh@oss.qualcomm.com \
--cc=ath12k@lists.infradead.org \
--cc=jeff.johnson@oss.qualcomm.com \
--cc=kang.yang@oss.qualcomm.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox