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, 09 Nov 2021 17:57:10 +0800 [thread overview]
Message-ID: <6053b0963612057267f00b89e14b9e15@codeaurora.org> (raw)
In-Reply-To: <67936afa5545b9a5d6eb5ad6931026d7@codeaurora.org>
Hi Johannes,
do you have comments about my description for PSD?
On 2021-10-26 19:26, Wen Gong wrote:
> 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-11-09 9:57 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
2021-11-09 9:57 ` Wen Gong [this message]
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=6053b0963612057267f00b89e14b9e15@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).