Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Sender: wgong=codeaurora.org@mg.codeaurora.org
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date:   Wed, 13 Oct 2021 11:33:38 +0800
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
In-Reply-To: <0b05f6e555bcb89c49f56279c077ce63@codeaurora.org>
References: <20210928085211.26186-1-wgong@codeaurora.org>
 <bd649a3d2cf2ea9064d427d633055891@codeaurora.org>
 <cb20427eae96c4551084e4c899618b94@codeaurora.org>
 <2afb1bf6f06cb53f43fe0d354afa4e7c@codeaurora.org>
 <2ed76cff292dcca18326de0407a93821@codeaurora.org>
 <1222384c2bc7d80bf572b65ab17660477bb27300.camel@sipsolutions.net>
 <562080d7fc3b7568811c47a8e8e79156@codeaurora.org>
 <DM8PR02MB8154258563A4F7C805C84B4BE6B59@DM8PR02MB8154.namprd02.prod.outlook.com>
 <0b05f6e555bcb89c49f56279c077ce63@codeaurora.org>
Message-ID: <9bd081863cb53380de8741ec1ab316dd@codeaurora.org>
User-Agent: Roundcube Webmail/1.3.9
Precedence: bulk

Hi Johannes,

Do you think what change is needed for this patch?

It should need another patchset to handle AP+STA... in
same wiphy/ieee80211_hw feature by my understand.

On 2021-10-11 15:48, Wen Gong wrote:
> 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