From: Harshitha Prem <quic_hprem@quicinc.com>
To: Johannes Berg <johannes@sipsolutions.net>, <ath12k@lists.infradead.org>
Cc: <linux-wireless@vger.kernel.org>
Subject: Re: [PATCH] cfg80211: Allow pre-CAC for self-managed wiphy
Date: Mon, 6 May 2024 22:31:25 +0530 [thread overview]
Message-ID: <01e690ab-6b41-f976-1e83-d3840ef5ff7c@quicinc.com> (raw)
In-Reply-To: <21cd883ea7d3a7735bbba2c85f5d9e5d5803b5d6.camel@sipsolutions.net>
On 5/3/2024 1:56 PM, Johannes Berg wrote:
> On Mon, 2024-04-29 at 09:57 +0530, Harshitha Prem wrote:
>> Currently, to allow pre-CAC it requires both driver's regulatory domain
>> in wiphy and cfg80211 local regulatory domain to be same, along with the
>> region to be in ETSI.
>
> Any idea why that is?
>
>> But, for self-managed driver, some countries have mismatch between these
>> two regulatory domains and it would not allow for a pre-CAC. For example,
>> in ath12k driver (self-managed), country Sri Lanka (LK) is classified as
>> FCC domain as per cfg80211 local regulatory database but as per ath12k
>> driver it falls under ETSI domain then because of this mismatch, the
>> driver might not be able to do a pre-CAC.
>>
>> Hence, add changes to allow pre-CAC based on wiphy's regulatory setting
>> if it is a self-managed wiphy.
>
> I don't see how that's really all that much more helpful than simply
> removing the restriction? But then why is the restriction there?
>
> johannes
Hi Johannes,
Seems like, there can be a possibility to have two wiphy devices with
two different regulatory domains to be present on a single system and
for cfg80211 to respect it. In this case, a core central regulatory
domain will consist of the intersection between the two wiphy's
regulatory domains. Because of this mostly, in case of DFS, in cfg80211
apis like reg_get_dfs_region() , there is a check to ensure like if both
the core central regulatory and device's regulatory are same.
Drivers which are not self managed can have this restriction, just to
ensure to allow precac only if both matches or May be should we relax
this restriction? but I am quite not sure on the impact. Will try to
analyze on this.
Thanks,
Harshitha.
prev parent reply other threads:[~2024-05-06 17:01 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-29 4:27 [PATCH] cfg80211: Allow pre-CAC for self-managed wiphy Harshitha Prem
2024-04-29 7:35 ` Kalle Valo
2024-04-29 10:16 ` Harshitha Prem
2024-05-03 8:26 ` Johannes Berg
2024-05-06 17:01 ` Harshitha Prem [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=01e690ab-6b41-f976-1e83-d3840ef5ff7c@quicinc.com \
--to=quic_hprem@quicinc.com \
--cc=ath12k@lists.infradead.org \
--cc=johannes@sipsolutions.net \
--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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).