linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Wen Gong <wgong@codeaurora.org>
To: Venkateswara Naralasetty <vnaralas@qti.qualcomm.com>
Cc: Johannes Berg <johannes@sipsolutions.net>,
	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: Mon, 11 Oct 2021 15:48:27 +0800	[thread overview]
Message-ID: <0b05f6e555bcb89c49f56279c077ce63@codeaurora.org> (raw)
In-Reply-To: <DM8PR02MB8154258563A4F7C805C84B4BE6B59@DM8PR02MB8154.namprd02.prod.outlook.com>

On 2021-10-11 14:43, Venkateswara Naralasetty wrote:
>> -----Original Message-----
>> From: ath11k <ath11k-bounces@lists.infradead.org> On Behalf Of Wen 
>> Gong
>> Sent: Monday, October 11, 2021 9:36 AM
>> To: Johannes Berg <johannes@sipsolutions.net>
>> Cc: 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
>> 
>> WARNING: This email originated from outside of Qualcomm. Please be 
>> wary
>> of any links or attachments, and do not enable macros.
>> 
>> On 2021-09-30 20:50, Johannes Berg wrote:
>> > On Thu, 2021-09-30 at 10:53 +0800, Wen Gong wrote:
>> >> > >
>> >> > >          chan->max_reg_power =
>> >> > >                  min_t(int, MBM_TO_DBM(power_rule1->max_eirp),
>> >> > >                        MBM_TO_DBM(power_rule2->max_eirp));
>> >> > >
>> >> > > For AP + STA concurrency, it should to maintain 2 group of reg
>> >> > > rules, one is for AP, another is for STA.
>> >> >
>> >> > Can we maintain two power rules in the same channel one for AP and
>> >> > one for STA. In this way, we can update the power rules in the same
>> >> > channel for both AP and STA from the reg rules.
>> >> >
>> >> > Otherwise, we need to maintain multiple channel lists in sband for
>> >> > all supported power mode combinations to apply the respective power
>> >> > rules and build channel flags from the multiple reg rules.
>> >> > right?
>> >>
>> >> If AP+STA is up in the same wiphy/ieee80211_hw, and AP's reg rules is
>> >> different with STA, then it should maintain muti channel list for
>> >> each band of the wiphy/ieee80211_hw by my understand.
>> >
>> > I don't think that's how it works. You can today have AP/STA
>> > concurrency on a single wiphy with different netdevs, even with mesh
>> > or whatever.
>> >
>> >> Currently there is only one "struct ieee80211_supported_band
>> >> *bands[NUM_NL80211_BANDS]"
>> >> in "struct wiphy".
>> >>
>> >> I advise to discuss the AP + STA concurrency in another mail thread
>> >> since it is not relative with this patch.
>> >
>> > I actually explicitly pointed to this thread, but I'm not sure it's so
>> > clear cut?
>> >
>> > If we have completely separate rules here for AP and STA, we probably
>> > should have different "max_reg_power" values for AP and STA? Maybe
>> > mesh is treated like AP, maybe not?
>> >
>> > But I don't know - does PSD really differ between AP and STA?
>> >
>> > Maybe this discussion belongs rather to the power type patch? But that
>> > didn't add any state!
>> >
>> >
>> > So - does this PSD depend on mode? It kind of seems like it shouldn't
>> > and then this *isn't* the right place to be discussing this, but if
>> > PSD does in fact depend on the mode then we should be discussing it
>> here?
>> >
>> > Venkatesh seemed to be worried more about LPI/client power etc. as in
>> > commit 405fca8a9461 ("ieee80211: add power type definition for 6
>> > GHz"), but that doesn't add state?
>> >
>> > So what gives? From a regulatory POV it seems PSD should be
>> > independent, but some other things might be dependent on mode?
>> >
>> 
>> As I know, below values maybe all different for the AP and
>> STATION in the same wiphy/ieee80211_hw, not only PSD.
>> 
>> struct ieee80211_reg_rule {
>>         struct ieee80211_freq_range freq_range;
>>         struct ieee80211_power_rule power_rule;
>>         struct ieee80211_wmm_rule wmm_rule;
>>         u32 flags;
>>         u32 dfs_cac_ms;
>>         bool has_wmm;
>>         s8 psd;
>> };
> 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)

>> 
>> @Venkateswara, please feel free to give more info to Johannes:)
>> 
>> > johannes
>> 
>> --
>> ath11k mailing list
>> ath11k@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/ath11k

  reply	other threads:[~2021-10-11  7:48 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 [this message]
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
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=0b05f6e555bcb89c49f56279c077ce63@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).