| Message ID | 20231220133549.cbfbef9170a9.I432f78438de18aa9f5c9006be12e41dc34cc47c5@changeid |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [v2,01/13] wifi: cfg80211: reg: Support P2P operation on DFS channels | expand |
Miri Korenblit <miriam.rachel.korenblit@intel.com> writes: > From: Mukesh Sisodiya <mukesh.sisodiya@intel.com> > > UHB AP send supported power type(LPI, SP, VLP) > in beacon and probe response IE and STA should > connect to these AP only if their regulatory support > the AP power type. > > Beacon/Probe response are reported to userspace > with reason "STA regulatory not supporting to connect to AP > based on transmitted power type" and it should > not connect to AP. > > Signed-off-by: Mukesh Sisodiya <mukesh.sisodiya@intel.com> > Reviewed-by: Gregory Greenman <gregory.greenman@intel.com> > Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> What's an UHB AP? Never heard of that before.
> -----Original Message----- > From: Kalle Valo <kvalo@kernel.org> > Sent: Friday, December 22, 2023 13:02 > To: Korenblit, Miriam Rachel <miriam.rachel.korenblit@intel.com> > Cc: johannes@sipsolutions.net; linux-wireless@vger.kernel.org; Sisodiya, > Mukesh <mukesh.sisodiya@intel.com>; Greenman, Gregory > <gregory.greenman@intel.com> > Subject: Re: [PATCH v2 05/13] wifi: cfg80211: handle UHB AP and STA power > type > > Miri Korenblit <miriam.rachel.korenblit@intel.com> writes: > > > From: Mukesh Sisodiya <mukesh.sisodiya@intel.com> > > > > UHB AP send supported power type(LPI, SP, VLP) in beacon and probe > > response IE and STA should connect to these AP only if their > > regulatory support the AP power type. > > > > Beacon/Probe response are reported to userspace with reason "STA > > regulatory not supporting to connect to AP based on transmitted power > > type" and it should not connect to AP. > > > > Signed-off-by: Mukesh Sisodiya <mukesh.sisodiya@intel.com> > > Reviewed-by: Gregory Greenman <gregory.greenman@intel.com> > > Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> > > What's an UHB AP? Never heard of that before. Ultra High Band (6 GHz) Aps > > -- > https://patchwork.kernel.org/project/linux-wireless/list/ > > https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatch > es
Hi Miri/ Kalle, Yes, it is Ultra High band(6Ghz) AP. Regards, Mukesh Sisodiya -----Original Message----- From: Korenblit, Miriam Rachel <miriam.rachel.korenblit@intel.com> Sent: Sunday, December 24, 2023 1:23 AM To: Kalle Valo <kvalo@kernel.org> Cc: johannes@sipsolutions.net; linux-wireless@vger.kernel.org; Sisodiya, Mukesh <mukesh.sisodiya@intel.com>; Greenman, Gregory <gregory.greenman@intel.com> Subject: RE: [PATCH v2 05/13] wifi: cfg80211: handle UHB AP and STA power type > -----Original Message----- > From: Kalle Valo <kvalo@kernel.org> > Sent: Friday, December 22, 2023 13:02 > To: Korenblit, Miriam Rachel <miriam.rachel.korenblit@intel.com> > Cc: johannes@sipsolutions.net; linux-wireless@vger.kernel.org; > Sisodiya, Mukesh <mukesh.sisodiya@intel.com>; Greenman, Gregory > <gregory.greenman@intel.com> > Subject: Re: [PATCH v2 05/13] wifi: cfg80211: handle UHB AP and STA > power type > > Miri Korenblit <miriam.rachel.korenblit@intel.com> writes: > > > From: Mukesh Sisodiya <mukesh.sisodiya@intel.com> > > > > UHB AP send supported power type(LPI, SP, VLP) in beacon and probe > > response IE and STA should connect to these AP only if their > > regulatory support the AP power type. > > > > Beacon/Probe response are reported to userspace with reason "STA > > regulatory not supporting to connect to AP based on transmitted > > power type" and it should not connect to AP. > > > > Signed-off-by: Mukesh Sisodiya <mukesh.sisodiya@intel.com> > > Reviewed-by: Gregory Greenman <gregory.greenman@intel.com> > > Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> > > What's an UHB AP? Never heard of that before. Ultra High Band (6 GHz) Aps > > -- > https://patchwork.kernel.org/project/linux-wireless/list/ > > https://wireless.wiki.kernel.org/en/developers/documentation/submittin > gpatch > es
On 12/29/2023 2:51 PM, Sisodiya, Mukesh wrote: > Hi Miri/ Kalle, > Yes, it is Ultra High band(6Ghz) AP. > Regards, > Mukesh Sisodiya > -----Original Message----- > From: Korenblit, Miriam Rachel <miriam.rachel.korenblit@intel.com> > Sent: Sunday, December 24, 2023 1:23 AM > To: Kalle Valo <kvalo@kernel.org> > Cc: johannes@sipsolutions.net; linux-wireless@vger.kernel.org; Sisodiya, Mukesh <mukesh.sisodiya@intel.com>; Greenman, Gregory <gregory.greenman@intel.com> > Subject: RE: [PATCH v2 05/13] wifi: cfg80211: handle UHB AP and STA power type > >> -----Original Message----- >> From: Kalle Valo <kvalo@kernel.org> >> Sent: Friday, December 22, 2023 13:02 >> To: Korenblit, Miriam Rachel <miriam.rachel.korenblit@intel.com> >> Cc: johannes@sipsolutions.net; linux-wireless@vger.kernel.org; >> Sisodiya, Mukesh <mukesh.sisodiya@intel.com>; Greenman, Gregory >> <gregory.greenman@intel.com> >> Subject: Re: [PATCH v2 05/13] wifi: cfg80211: handle UHB AP and STA >> power type >> >> Miri Korenblit <miriam.rachel.korenblit@intel.com> writes: >> >>> From: Mukesh Sisodiya <mukesh.sisodiya@intel.com> >>> >>> UHB AP send supported power type(LPI, SP, VLP) in beacon and probe >>> response IE and STA should connect to these AP only if their >>> regulatory support the AP power type. >>> >>> Beacon/Probe response are reported to userspace with reason "STA >>> regulatory not supporting to connect to AP based on transmitted >>> power type" and it should not connect to AP. >>> >>> Signed-off-by: Mukesh Sisodiya <mukesh.sisodiya@intel.com> >>> Reviewed-by: Gregory Greenman <gregory.greenman@intel.com> >>> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> >> >> What's an UHB AP? Never heard of that before. > > Ultra High Band (6 GHz) Aps Not sure where the term is coming from. It is not in the 802.11 standards nor WFA specifications afaict. Regards, Arend >> >> -- >> https://patchwork.kernel.org/project/linux-wireless/list/ >> >> https://wireless.wiki.kernel.org/en/developers/documentation/submittin >> gpatch >> es > >
On 1/1/2024 4:15 PM, Arend van Spriel wrote: > On 12/29/2023 2:51 PM, Sisodiya, Mukesh wrote: >> Hi Miri/ Kalle, >> Yes, it is Ultra High band(6Ghz) AP. >> Regards, >> Mukesh Sisodiya >> -----Original Message----- >> From: Korenblit, Miriam Rachel <miriam.rachel.korenblit@intel.com> >> Sent: Sunday, December 24, 2023 1:23 AM >> To: Kalle Valo <kvalo@kernel.org> >> Cc: johannes@sipsolutions.net; linux-wireless@vger.kernel.org; Sisodiya, Mukesh <mukesh.sisodiya@intel.com>; Greenman, Gregory <gregory.greenman@intel.com> >> Subject: RE: [PATCH v2 05/13] wifi: cfg80211: handle UHB AP and STA power type >> >>> -----Original Message----- >>> From: Kalle Valo <kvalo@kernel.org> >>> Sent: Friday, December 22, 2023 13:02 >>> To: Korenblit, Miriam Rachel <miriam.rachel.korenblit@intel.com> >>> Cc: johannes@sipsolutions.net; linux-wireless@vger.kernel.org; >>> Sisodiya, Mukesh <mukesh.sisodiya@intel.com>; Greenman, Gregory >>> <gregory.greenman@intel.com> >>> Subject: Re: [PATCH v2 05/13] wifi: cfg80211: handle UHB AP and STA >>> power type >>> >>> Miri Korenblit <miriam.rachel.korenblit@intel.com> writes: >>> >>>> From: Mukesh Sisodiya <mukesh.sisodiya@intel.com> >>>> >>>> UHB AP send supported power type(LPI, SP, VLP) in beacon and probe >>>> response IE and STA should connect to these AP only if their >>>> regulatory support the AP power type. >>>> >>>> Beacon/Probe response are reported to userspace with reason "STA >>>> regulatory not supporting to connect to AP based on transmitted >>>> power type" and it should not connect to AP. >>>> >>>> Signed-off-by: Mukesh Sisodiya <mukesh.sisodiya@intel.com> >>>> Reviewed-by: Gregory Greenman <gregory.greenman@intel.com> >>>> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> >>> >>> What's an UHB AP? Never heard of that before. >> >> Ultra High Band (6 GHz) Aps > > Not sure where the term is coming from. It is not in the 802.11 > standards nor WFA specifications afaict. I have the same concern. We should not introduce "marketing" terminology; please stick to terminology used in the specifications.
Jeff Johnson <quic_jjohnson@quicinc.com> writes: >>>> What's an UHB AP? Never heard of that before. >>> >>> Ultra High Band (6 GHz) Aps >> >> Not sure where the term is coming from. It is not in the 802.11 >> standards nor WFA specifications afaict. > > I have the same concern. We should not introduce "marketing" > terminology; please stick to terminology used in the specifications. Agreed. The commit logs should be understandable by any Linux engineer, not just by wireless engineers.
diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h index 5e5ea216f341..e484d9d10630 100644 --- a/include/linux/ieee80211.h +++ b/include/linux/ieee80211.h @@ -2720,6 +2720,7 @@ static inline bool ieee80211_he_capa_size_ok(const u8 *data, u8 len) #define IEEE80211_6GHZ_CTRL_REG_LPI_AP 0 #define IEEE80211_6GHZ_CTRL_REG_SP_AP 1 +#define IEEE80211_6GHZ_CTRL_REG_VLP_AP 2 /** * struct ieee80211_he_6ghz_oper - HE 6 GHz operation Information field diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h index d8150d8b13e5..427a83c78c8c 100644 --- a/include/net/cfg80211.h +++ b/include/net/cfg80211.h @@ -118,6 +118,10 @@ struct wiphy; * restrictions. * @IEEE80211_CHAN_NO_EHT: EHT operation is not permitted on this channel. * @IEEE80211_CHAN_DFS_CONCURRENT: See %NL80211_RRF_DFS_CONCURRENT + * @IEEE80211_CHAN_NO_UHB_VLP_CLIENT: Client connection with VLP AP + * not permitted using this channel + * @IEEE80211_CHAN_NO_UHB_AFC_CLIENT: Client connection with AFC AP + * not permitted using this channel */ enum ieee80211_channel_flags { IEEE80211_CHAN_DISABLED = 1<<0, @@ -142,6 +146,8 @@ enum ieee80211_channel_flags { IEEE80211_CHAN_NO_320MHZ = 1<<19, IEEE80211_CHAN_NO_EHT = 1<<20, IEEE80211_CHAN_DFS_CONCURRENT = 1<<21, + IEEE80211_CHAN_NO_UHB_VLP_CLIENT= 1<<22, + IEEE80211_CHAN_NO_UHB_AFC_CLIENT= 1<<23, }; #define IEEE80211_CHAN_NO_HT40 \ diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h index 466da830e65f..1ccdcae24372 100644 --- a/include/uapi/linux/nl80211.h +++ b/include/uapi/linux/nl80211.h @@ -4260,6 +4260,10 @@ enum nl80211_wmm_rule { * allowed for peer-to-peer or adhoc communication under the control * of a DFS master which operates on the same channel (FCC-594280 D01 * Section B.3). Should be used together with %NL80211_RRF_DFS only. + * @NL80211_FREQUENCY_ATTR_NO_UHB_VLP_CLIENT: Client connection to VLP AP + * not allowed using this channel + * @NL80211_FREQUENCY_ATTR_NO_UHB_AFC_CLIENT: Client connection to AFC AP + * not allowed using this channel * @NL80211_FREQUENCY_ATTR_MAX: highest frequency attribute number * currently defined * @__NL80211_FREQUENCY_ATTR_AFTER_LAST: internal use @@ -4300,6 +4304,8 @@ enum nl80211_frequency_attr { NL80211_FREQUENCY_ATTR_NO_EHT, NL80211_FREQUENCY_ATTR_PSD, NL80211_FREQUENCY_ATTR_DFS_CONCURRENT, + NL80211_FREQUENCY_ATTR_NO_UHB_VLP_CLIENT, + NL80211_FREQUENCY_ATTR_NO_UHB_AFC_CLIENT, /* keep last */ __NL80211_FREQUENCY_ATTR_AFTER_LAST, @@ -4509,6 +4515,8 @@ enum nl80211_sched_scan_match_attr { peer-to-peer or adhoc communication under the control of a DFS master which operates on the same channel (FCC-594280 D01 Section B.3). Should be used together with %NL80211_RRF_DFS only. + * @NL80211_RRF_NO_UHB_VLP_CLIENT: Client connection to VLP AP not allowed + * @NL80211_RRF_NO_UHB_AFC_CLIENT: Client connection to AFC AP not allowed */ enum nl80211_reg_rule_flags { NL80211_RRF_NO_OFDM = 1<<0, @@ -4531,6 +4539,8 @@ enum nl80211_reg_rule_flags { NL80211_RRF_NO_EHT = 1<<19, NL80211_RRF_PSD = 1<<20, NL80211_RRF_DFS_CONCURRENT = 1<<21, + NL80211_RRF_NO_UHB_VLP_CLIENT = 1<<22, + NL80211_RRF_NO_UHB_AFC_CLIENT = 1<<23, }; #define NL80211_RRF_PASSIVE_SCAN NL80211_RRF_NO_IR @@ -5086,9 +5096,12 @@ enum nl80211_bss_use_for { * BSS isn't possible * @NL80211_BSS_CANNOT_USE_NSTR_NONPRIMARY: NSTR nonprimary links aren't * supported by the device, and this BSS entry represents one. + * @NL80211_BSS_CANNOT_USE_UHB_PWR_MISMATCH: STA is not supporting + * the AP power type (SP, VLP, AP) that the AP uses. */ enum nl80211_bss_cannot_use_reasons { NL80211_BSS_CANNOT_USE_NSTR_NONPRIMARY = 1 << 0, + NL80211_BSS_CANNOT_USE_UHB_PWR_MISMATCH = 1 << 1, }; /** diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c index f64005d62b19..299f2622b00d 100644 --- a/net/wireless/nl80211.c +++ b/net/wireless/nl80211.c @@ -1204,6 +1204,12 @@ static int nl80211_msg_put_channel(struct sk_buff *msg, struct wiphy *wiphy, if ((chan->flags & IEEE80211_CHAN_DFS_CONCURRENT) && nla_put_flag(msg, NL80211_FREQUENCY_ATTR_DFS_CONCURRENT)) goto nla_put_failure; + if ((chan->flags & IEEE80211_CHAN_NO_UHB_VLP_CLIENT) && + nla_put_flag(msg, NL80211_FREQUENCY_ATTR_NO_UHB_VLP_CLIENT)) + goto nla_put_failure; + if ((chan->flags & IEEE80211_CHAN_NO_UHB_AFC_CLIENT) && + nla_put_flag(msg, NL80211_FREQUENCY_ATTR_NO_UHB_AFC_CLIENT)) + goto nla_put_failure; } if (nla_put_u32(msg, NL80211_FREQUENCY_ATTR_MAX_TX_POWER, diff --git a/net/wireless/reg.c b/net/wireless/reg.c index 44684df64734..2741b626919a 100644 --- a/net/wireless/reg.c +++ b/net/wireless/reg.c @@ -1595,6 +1595,10 @@ static u32 map_regdom_flags(u32 rd_flags) channel_flags |= IEEE80211_CHAN_NO_EHT; if (rd_flags & NL80211_RRF_DFS_CONCURRENT) channel_flags |= IEEE80211_CHAN_DFS_CONCURRENT; + if (rd_flags & NL80211_RRF_NO_UHB_VLP_CLIENT) + channel_flags |= IEEE80211_CHAN_NO_UHB_VLP_CLIENT; + if (rd_flags & NL80211_RRF_NO_UHB_AFC_CLIENT) + channel_flags |= IEEE80211_CHAN_NO_UHB_AFC_CLIENT; if (rd_flags & NL80211_RRF_PSD) channel_flags |= IEEE80211_CHAN_PSD; return channel_flags; diff --git a/net/wireless/scan.c b/net/wireless/scan.c index 3d260c99c348..a601f1c7f835 100644 --- a/net/wireless/scan.c +++ b/net/wireless/scan.c @@ -2848,6 +2848,36 @@ cfg80211_inform_bss_data(struct wiphy *wiphy, } EXPORT_SYMBOL(cfg80211_inform_bss_data); +static bool cfg80211_uhb_power_type_valid(const u8 *ie, + size_t ielen, + const u32 flags) +{ + const struct element *tmp; + struct ieee80211_he_operation *he_oper; + + tmp = cfg80211_find_ext_elem(WLAN_EID_EXT_HE_OPERATION, ie, ielen); + if (tmp && tmp->datalen >= sizeof(*he_oper) + 1) { + const struct ieee80211_he_6ghz_oper *he_6ghz_oper; + + he_oper = (void *)&tmp->data[1]; + he_6ghz_oper = ieee80211_he_6ghz_oper(he_oper); + + if (!he_6ghz_oper) + return false; + + switch (u8_get_bits(he_6ghz_oper->control, + IEEE80211_HE_6GHZ_OPER_CTRL_REG_INFO)) { + case IEEE80211_6GHZ_CTRL_REG_LPI_AP: + return true; + case IEEE80211_6GHZ_CTRL_REG_SP_AP: + return !(flags & IEEE80211_CHAN_NO_UHB_AFC_CLIENT); + case IEEE80211_6GHZ_CTRL_REG_VLP_AP: + return !(flags & IEEE80211_CHAN_NO_UHB_VLP_CLIENT); + } + } + return false; +} + /* cfg80211_inform_bss_width_frame helper */ static struct cfg80211_bss * cfg80211_inform_single_bss_frame_data(struct wiphy *wiphy, @@ -2906,6 +2936,14 @@ cfg80211_inform_single_bss_frame_data(struct wiphy *wiphy, if (!channel) return NULL; + if (channel->band == NL80211_BAND_6GHZ && + !cfg80211_uhb_power_type_valid(variable, ielen, channel->flags)) { + data->restrict_use = 1; + data->use_for = 0; + data->cannot_use_reasons = + NL80211_BSS_CANNOT_USE_UHB_PWR_MISMATCH; + } + if (ext) { const struct ieee80211_s1g_bcn_compat_ie *compat; const struct element *elem;