> -----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?
>
> @Venkateswara, please feel free to give more info to Johannes:)
>
> > johannes
>
> --
> ath11k mailing list
> ath11k@xxxxxxxxxxxxxxxxxxx
> http://lists.infradead.org/mailman/listinfo/ath11k
