From: Wen Gong <wgong@codeaurora.org>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: Venkateswara Naralasetty <vnaralas@qti.qualcomm.com>,
Venkateswara Naralasetty <vnaralas@codeaurora.org>,
ath11k@lists.infradead.org, linux-wireless@vger.kernel.org,
wgong=codeaurora.org@codeaurora.org
Subject: Re: [PATCH v5] cfg80211: save power spectral density(psd) of regulatory rule
Date: Tue, 26 Oct 2021 19:26:46 +0800 [thread overview]
Message-ID: <67936afa5545b9a5d6eb5ad6931026d7@codeaurora.org> (raw)
In-Reply-To: <18363bc18538ea9b7e8fe28f4c5595c54f3b93d3.camel@sipsolutions.net>
On 2021-10-26 04:09, Johannes Berg wrote:
> On Mon, 2021-10-11 at 15:48 +0800, Wen Gong wrote:
>>
>> > IMO, Only power rules and PSD info might vary for AP and STATION. Rest
>> > of the rules will remains same right?
>> >
>> The freq_range may also be different for AP and STATION.
>> and reg_rules number also may also be different for AP and STATION.
>>
>> for example:
>> SUBORDINATE CLIENT of STANDARD POWER reg rules number 2
>> reg rule 1: (5945 - 6425 @ 160) (0, 30) (FLAGS 0) (psd flag 1 EIRP 17
>> dB/MHz)
>> reg rule 2: (6525 - 6885 @ 160) (0, 30) (FLAGS 0) (psd flag 1 EIRP 17
>> dB/MHz)
>>
>> INDOOR AP reg rules number 1
>> reg rule 1: (5945 - 7125 @ 160) (0, 24) (FLAGS 0) (psd flag 0 EIRP 0
>> dB/MHz)
>
> That seems right, but isn't that an orthogonal question?
>
> Here, on this patch, we're discussing what data we should have in the
> channel information, and it would seem that if it's different for
> AP/client, then we do need both information stored, so that we can cope
> with concurrency between AP and client?
>
> If we additionally need to have different data for the regulatory rules
> for AP and client, that might mean we need to go back and actually
> change the code there *as well*, and then fill in the right fields in
> this patch?
>
> Unless somehow we're convinced that for this feature we don't need to
> worry about concurrently using AP and client modes?
>
> johannes
Currently these patches of mac80211/cfg80211/ieee80211 for LPI/SP/VLP is
the base patches, to enable the feature of LPI/SP/VLP, it still need
other
patches of lower drivers such as ath11k to enable it. It will not have
LPI/SP/VLP without patches of ath11k, it means all these patches will
not take effect.
When lower driver such as ath11k set max_interfaces of
ieee80211_iface_combination
to 1, then it can not start more than 1 interface on the same
ieee80211_hw/wiphy.
When STATION interface is up, then AP interface can not start up. AP
interface
can start up after STATION interfacedown. Also when AP interface is up,
STATION interface can not start up. STATION interface can start up after
AP interface down.
I have sent out my ath11k
patches(https://lore.kernel.org/linux-wireless/20211026111913.7346-1-quic_wgong@quicinc.com/),
it will allow only one interface
up simultaneously for the chip which enable LPI/SP/VLP feature in this
patch: "ath11k: allow only one interface up simultaneously for WCN6855"
https://lore.kernel.org/linux-wireless/20211026111913.7346-5-quic_wgong@quicinc.com/
It means it will not have both AP/STA together and these patches of
mac80211/
cfg80211/ieee80211 not need changes and it will not have bugs.
If there are some chip want to both enable LPI/SP/VLP feature and
enable AP/STA simultaneously in same ieee80211_hw/wiphy in future,
then he/she need to refine reg rules and channels of mac80211/cfg80211/
ieee80211, but at that moment, this patch "cfg80211: save power
spectral density(psd) of regulatory rule" still not need change.
Because this patch is change in each reg rule/each channel in a
low layer, the refine reg rules and channels is a high layer, they
have no intersection.
next prev parent reply other threads:[~2021-10-26 11:26 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-28 8:52 [PATCH v5] cfg80211: save power spectral density(psd) of regulatory rule Wen Gong
2021-09-28 13:12 ` vnaralas
2021-09-29 3:37 ` Wen Gong
2021-09-29 16:46 ` Venkateswara Naralasetty
2021-09-30 2:53 ` Wen Gong
2021-09-30 12:50 ` Johannes Berg
2021-10-11 4:06 ` Wen Gong
2021-10-11 6:43 ` Venkateswara Naralasetty
2021-10-11 7:48 ` Wen Gong
2021-10-13 3:33 ` Wen Gong
2021-10-25 20:09 ` Johannes Berg
2021-10-26 11:26 ` Wen Gong [this message]
2021-11-09 9:57 ` Wen Gong
2021-12-06 8:48 ` Wen Gong
2022-03-03 2:13 ` Wen Gong
2022-04-15 2:27 ` Wen Gong
2022-05-04 12:00 ` Johannes Berg
2022-05-06 10:50 ` Wen Gong
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=67936afa5545b9a5d6eb5ad6931026d7@codeaurora.org \
--to=wgong@codeaurora.org \
--cc=ath11k@lists.infradead.org \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=vnaralas@codeaurora.org \
--cc=vnaralas@qti.qualcomm.com \
--cc=wgong=codeaurora.org@codeaurora.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 NNTP newsgroup(s).