All of lore.kernel.org
 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: Wed, 13 Oct 2021 11:33:38 +0800	[thread overview]
Message-ID: <9bd081863cb53380de8741ec1ab316dd@codeaurora.org> (raw)
In-Reply-To: <0b05f6e555bcb89c49f56279c077ce63@codeaurora.org>

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

WARNING: multiple messages have this Message-ID (diff)
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: Wed, 13 Oct 2021 11:33:38 +0800	[thread overview]
Message-ID: <9bd081863cb53380de8741ec1ab316dd@codeaurora.org> (raw)
In-Reply-To: <0b05f6e555bcb89c49f56279c077ce63@codeaurora.org>

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

-- 
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k

  reply	other threads:[~2021-10-13  3:33 UTC|newest]

Thread overview: 36+ 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  8:52 ` Wen Gong
2021-09-28 13:12 ` vnaralas
2021-09-28 13:12   ` vnaralas
2021-09-29  3:37   ` Wen Gong
2021-09-29  3:37     ` Wen Gong
2021-09-29 16:46     ` Venkateswara Naralasetty
2021-09-29 16:46       ` Venkateswara Naralasetty
2021-09-30  2:53       ` Wen Gong
2021-09-30  2:53         ` Wen Gong
2021-09-30 12:50         ` Johannes Berg
2021-09-30 12:50           ` Johannes Berg
2021-10-11  4:06           ` Wen Gong
2021-10-11  4:06             ` Wen Gong
2021-10-11  6:43             ` Venkateswara Naralasetty
2021-10-11  6:43               ` Venkateswara Naralasetty
2021-10-11  7:48               ` Wen Gong
2021-10-11  7:48                 ` Wen Gong
2021-10-13  3:33                 ` Wen Gong [this message]
2021-10-13  3:33                   ` Wen Gong
2021-10-25 20:09                 ` Johannes Berg
2021-10-25 20:09                   ` Johannes Berg
2021-10-26 11:26                   ` Wen Gong
2021-10-26 11:26                     ` Wen Gong
2021-11-09  9:57                     ` Wen Gong
2021-11-09  9:57                       ` Wen Gong
2021-12-06  8:48                       ` Wen Gong
2021-12-06  8:48                         ` Wen Gong
2022-03-03  2:13                         ` Wen Gong
2022-03-03  2:13                           ` Wen Gong
2022-04-15  2:27                           ` Wen Gong
2022-04-15  2:27                             ` Wen Gong
2022-05-04 12:00                             ` Johannes Berg
2022-05-04 12:00                               ` Johannes Berg
2022-05-06 10:50                               ` Wen Gong
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=9bd081863cb53380de8741ec1ab316dd@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.