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@xxxxxxxxxxxxxxxxxxx> On Behalf Of Wen
Gong
Sent: Monday, October 11, 2021 9:36 AM
To: Johannes Berg <johannes@xxxxxxxxxxxxxxxx>
Cc: Venkateswara Naralasetty <vnaralas@xxxxxxxxxxxxxx>;
ath11k@xxxxxxxxxxxxxxxxxxx; linux-wireless@xxxxxxxxxxxxxxx;
wgong=codeaurora.org@xxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/ath11k
