| Message ID | iwlwifi.20210331121101.7c7bd00e0aeb.Ib226ad57e416b43a710c36a78a617d4243458b99@changeid (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 59bb220d560c72ca8b65852c4885eaab74006f84 |
| Delegated to: | Luca Coelho |
| Headers | show |
| Series | iwlwifi: updates intended for v5.13 2021-03-31 | expand |
On 3/31/21 2:14 AM, Luca Coelho wrote: > From: Ilan Peer <ilan.peer@intel.com> > > When doing scan while 6GHz channels are not enabled, the 6GHz band > is not scanned. Thus, if there are no APs on the 2GHz and 5GHz bands > (that will allow discovery of geographic location etc. that would > allow enabling the 6GHz channels) but there are non collocated APs > on 6GHz PSC channels these would never be discovered. > > To overcome this, FW added support for performing passive UHB scan > in case no APs were discovered during scan on the 2GHz and 5GHz > channels. > > Add support for enabling such scan when the following conditions are > met: > > - 6GHz channels are supported but not enabled by regulatory. > - Station interface is not associated or less than a defined time > interval passed from the last resume or HW reset flows. > - At least 4 channels are included in the scan request > - The scan request includes the widlcard SSID. > - At least 50 minutes passed from the last 6GHz passive scan. Why are you trying so hard to not do passive scans? This seems like it is set up for all sorts of frustration. Thanks, Ben
On Wed, 2021-03-31 at 05:03 -0700, Ben Greear wrote: > On 3/31/21 2:14 AM, Luca Coelho wrote: > > From: Ilan Peer <ilan.peer@intel.com> > > > > When doing scan while 6GHz channels are not enabled, the 6GHz band > > is not scanned. Thus, if there are no APs on the 2GHz and 5GHz bands > > (that will allow discovery of geographic location etc. that would > > allow enabling the 6GHz channels) but there are non collocated APs > > on 6GHz PSC channels these would never be discovered. > > > > To overcome this, FW added support for performing passive UHB scan > > in case no APs were discovered during scan on the 2GHz and 5GHz > > channels. > > > > Add support for enabling such scan when the following conditions are > > met: > > > > - 6GHz channels are supported but not enabled by regulatory. > > - Station interface is not associated or less than a defined time > > interval passed from the last resume or HW reset flows. > > - At least 4 channels are included in the scan request > > - The scan request includes the widlcard SSID. > > - At least 50 minutes passed from the last 6GHz passive scan. > > Why are you trying so hard to not do passive scans? This seems like it > is set up for all sorts of frustration. This is because of regulatory restrictions. Maybe Ilan can clarify more. -- Cheers, Luca.
Hi Ben, > -----Original Message----- > From: Ben Greear <greearb@candelatech.com> > Sent: Wednesday, March 31, 2021 15:04 > To: Luca Coelho <luca@coelho.fi>; kvalo@codeaurora.org > Cc: linux-wireless@vger.kernel.org > Subject: Re: [PATCH 06/12] iwlwifi: mvm: Add support for 6GHz passive scan > > On 3/31/21 2:14 AM, Luca Coelho wrote: > > From: Ilan Peer <ilan.peer@intel.com> > > > > When doing scan while 6GHz channels are not enabled, the 6GHz band is > > not scanned. Thus, if there are no APs on the 2GHz and 5GHz bands > > (that will allow discovery of geographic location etc. that would > > allow enabling the 6GHz channels) but there are non collocated APs on > > 6GHz PSC channels these would never be discovered. > > > > To overcome this, FW added support for performing passive UHB scan in > > case no APs were discovered during scan on the 2GHz and 5GHz channels. > > > > Add support for enabling such scan when the following conditions are > > met: > > > > - 6GHz channels are supported but not enabled by regulatory. > > - Station interface is not associated or less than a defined time > > interval passed from the last resume or HW reset flows. > > - At least 4 channels are included in the scan request > > - The scan request includes the widlcard SSID. > > - At least 50 minutes passed from the last 6GHz passive scan. > > Why are you trying so hard to not do passive scans? This seems like it is set > up for all sorts of frustration. > This logic enables a special 'passive' scan which is not directly intended for discovery of APs for connection etc. but for discovery of APs with country information in the beacons/probe responses, so the fw could use this information as an input that might allow it to enable 6GHz channels (which are supported but are disabled). This special scan is intended for cases that the device does not have any other regulatory information that allows it to enable the 6GHz channels. Once these channels are enabled, we use passive scan as needed. We generally try to avoid passive scan on all the 6GHz channels as this is a long flow that takes at least 6 seconds (as there are such 64 channels) and with the discovery mechanisms defined for the 6GHz is not really needed. Hope this clarifies things. Regards, Ilan.
On 4/11/21 3:14 AM, Peer, Ilan wrote: > Hi Ben, > >> -----Original Message----- >> From: Ben Greear <greearb@candelatech.com> >> Sent: Wednesday, March 31, 2021 15:04 >> To: Luca Coelho <luca@coelho.fi>; kvalo@codeaurora.org >> Cc: linux-wireless@vger.kernel.org >> Subject: Re: [PATCH 06/12] iwlwifi: mvm: Add support for 6GHz passive scan >> >> On 3/31/21 2:14 AM, Luca Coelho wrote: >>> From: Ilan Peer <ilan.peer@intel.com> >>> >>> When doing scan while 6GHz channels are not enabled, the 6GHz band is >>> not scanned. Thus, if there are no APs on the 2GHz and 5GHz bands >>> (that will allow discovery of geographic location etc. that would >>> allow enabling the 6GHz channels) but there are non collocated APs on >>> 6GHz PSC channels these would never be discovered. >>> >>> To overcome this, FW added support for performing passive UHB scan in >>> case no APs were discovered during scan on the 2GHz and 5GHz channels. >>> >>> Add support for enabling such scan when the following conditions are >>> met: >>> >>> - 6GHz channels are supported but not enabled by regulatory. >>> - Station interface is not associated or less than a defined time >>> interval passed from the last resume or HW reset flows. >>> - At least 4 channels are included in the scan request >>> - The scan request includes the widlcard SSID. >>> - At least 50 minutes passed from the last 6GHz passive scan. >> >> Why are you trying so hard to not do passive scans? This seems like it is set >> up for all sorts of frustration. >> > > This logic enables a special 'passive' scan which is not directly intended for discovery of APs for connection etc. but > for discovery of APs with country information in the beacons/probe responses, so the fw could use this information > as an input that might allow it to enable 6GHz channels (which are supported but are disabled). This special scan > is intended for cases that the device does not have any other regulatory information that allows it to enable the 6GHz channels. > Once these channels are enabled, we use passive scan as needed. > > We generally try to avoid passive scan on all the 6GHz channels as this is a long flow that takes at least 6 seconds (as there are > such 64 channels) and with the discovery mechanisms defined for the 6GHz is not really needed. If the station comes up and does a 6E passive scan and does not find any AP, perhaps because 6Ghz AP was turned on 1 minute after the station tried to initially scan, this means that it will take 50 minutes before it can have a chance to scan the AP and connect to the Internet? If station cannot connect after a relatively short time, then I think it should scan as widely as it can in order find some possible way to connect. And why care about 'at least 4 channels'. If we know the AP channel, and can scan exactly there, then your concern about taking a long time is resolved. How else can we tell the radio that 6E is allowed? I previously tried all sorts of things to enable 6E channels so that I could more easily set the radio to sniff one of those channels in monitor mode, and I had no luck. If all of the 6E channels are marked as passive, what harm is it to enable the channels in the regdom from the beginning? Thanks, Ben > > Hope this clarifies things. > > Regards, > > Ilan. >
Hi, > > This logic enables a special 'passive' scan which is not directly > > intended for discovery of APs for connection etc. but for discovery of > > APs with country information in the beacons/probe responses, so the fw > > could use this information as an input that might allow it to enable 6GHz > channels (which are supported but are disabled). This special scan is intended > for cases that the device does not have any other regulatory information that > allows it to enable the 6GHz channels. > > Once these channels are enabled, we use passive scan as needed. > > > > We generally try to avoid passive scan on all the 6GHz channels as > > this is a long flow that takes at least 6 seconds (as there are such 64 > channels) and with the discovery mechanisms defined for the 6GHz is not > really needed. > > If the station comes up and does a 6E passive scan and does not find any AP, > perhaps because 6Ghz AP was turned on 1 minute after the station tried to > initially scan, this means that it will take 50 minutes before it can have a > chance to scan the AP and connect to the Internet? If station cannot connect > after a relatively short time, then I think it should scan as widely as it can in > order find some possible way to connect. > The purpose of this heuristic was to handle a very specific corner case where there are no APs on the 2GHz/5GHz bands and there are only one or more non-collocated APs on the 6GHz band. Based on our understanding, this is not a very likely situation and thus, due to other consideration e.g., power KPIs etc., the above conditions were defined. However, as you can see in the patch, there are options to tune the heuristic to be more aggressive, and if it would indeed be needed we can change the behavior such cases. > And why care about 'at least 4 channels'. If we know the AP channel, and can > scan exactly there, then your concern about taking a long time is resolved. > The assumption was that while a connection was not established a full scan is expected, so that's why the above condition was set. However, I'll take this with my colleagues and see if this condition can be removed or defined differently. > How else can we tell the radio that 6E is allowed? I previously tried all sorts of > things to enable 6E channels so that I could more easily set the radio to sniff > one of those channels in monitor mode, and I had no luck. > Are you asking specifically for iwlwifi devices? I'm not familiar with a simple way to do so other the one described here, but I can check if you need it. > If all of the 6E channels are marked as passive, what harm is it to enable the > channels in the regdom from the beginning? > AFAIK, as the 6GHz regulatory is still evolving, we are not yet allowed to do so. But once again, If you are interested I can further check this our regulatory team. Regards, Ilan.
On 4/11/21 5:14 AM, Peer, Ilan wrote: > Hi, > >>> This logic enables a special 'passive' scan which is not directly >>> intended for discovery of APs for connection etc. but for discovery of >>> APs with country information in the beacons/probe responses, so the fw >>> could use this information as an input that might allow it to enable 6GHz >> channels (which are supported but are disabled). This special scan is intended >> for cases that the device does not have any other regulatory information that >> allows it to enable the 6GHz channels. >>> Once these channels are enabled, we use passive scan as needed. >>> >>> We generally try to avoid passive scan on all the 6GHz channels as >>> this is a long flow that takes at least 6 seconds (as there are such 64 >> channels) and with the discovery mechanisms defined for the 6GHz is not >> really needed. >> >> If the station comes up and does a 6E passive scan and does not find any AP, >> perhaps because 6Ghz AP was turned on 1 minute after the station tried to >> initially scan, this means that it will take 50 minutes before it can have a >> chance to scan the AP and connect to the Internet? If station cannot connect >> after a relatively short time, then I think it should scan as widely as it can in >> order find some possible way to connect. >> > > The purpose of this heuristic was to handle a very specific corner case where there are > no APs on the 2GHz/5GHz bands and there are only one or more non-collocated APs > on the 6GHz band. Based on our understanding, this is not a very likely situation and thus, > due to other consideration e.g., power KPIs etc., the above conditions were defined. However, > as you can see in the patch, there are options to tune the heuristic to be more aggressive, > and if it would indeed be needed we can change the behavior such cases. Yes, and I can tweak the code myself if needed. But better if upstream driver is already nice as possible. >> And why care about 'at least 4 channels'. If we know the AP channel, and can >> scan exactly there, then your concern about taking a long time is resolved. >> > > The assumption was that while a connection was not established a full scan > is expected, so that's why the above condition was set. However, I'll take this > with my colleagues and see if this condition can be removed or defined > differently. The complexity of the restrictions are going to silently break certain configs that a user can reasonable expect to work I think. > >> How else can we tell the radio that 6E is allowed? I previously tried all sorts of >> things to enable 6E channels so that I could more easily set the radio to sniff >> one of those channels in monitor mode, and I had no luck. >> > > Are you asking specifically for iwlwifi devices? I'm not familiar with a simple > way to do so other the one described here, but I can check if you need it. Yes. ax210 in particular. > >> If all of the 6E channels are marked as passive, what harm is it to enable the >> channels in the regdom from the beginning? >> > > AFAIK, as the 6GHz regulatory is still evolving, we are not yet allowed to do so. But once again, > If you are interested I can further check this our regulatory team. Your patch enables passive scan of 6Ghz when no regulatory specifically allows it. I think just enabling the band as passive is the same thing, but significantly simplifies things. If there are regulatory reasons to not allow even passsive scanning on 6E, then your patch breaks that. If not, then just always allow 6E channels to be available in passive mode. The logic to optimize scanning time and channels belongs up in the supplicant and other higher level code that can take user input/config and make decisions using info that the driver will never have. Thanks, Ben > > Regards, > > Ilan. >
Hi Ben, > -----Original Message----- > From: Ben Greear <greearb@candelatech.com> > Sent: Sunday, April 11, 2021 19:15 > To: Peer, Ilan <ilan.peer@intel.com>; Luca Coelho <luca@coelho.fi>; > kvalo@codeaurora.org > Cc: linux-wireless@vger.kernel.org > Subject: Re: [PATCH 06/12] iwlwifi: mvm: Add support for 6GHz passive scan > > On 4/11/21 5:14 AM, Peer, Ilan wrote: > > Hi, > > > >>> This logic enables a special 'passive' scan which is not directly > >>> intended for discovery of APs for connection etc. but for discovery > >>> of APs with country information in the beacons/probe responses, so > >>> the fw could use this information as an input that might allow it to > >>> enable 6GHz > >> channels (which are supported but are disabled). This special scan is > >> intended for cases that the device does not have any other regulatory > >> information that allows it to enable the 6GHz channels. > >>> Once these channels are enabled, we use passive scan as needed. > >>> > >>> We generally try to avoid passive scan on all the 6GHz channels as > >>> this is a long flow that takes at least 6 seconds (as there are such > >>> 64 > >> channels) and with the discovery mechanisms defined for the 6GHz is > >> not really needed. > >> > >> If the station comes up and does a 6E passive scan and does not find > >> any AP, perhaps because 6Ghz AP was turned on 1 minute after the > >> station tried to initially scan, this means that it will take 50 > >> minutes before it can have a chance to scan the AP and connect to the > >> Internet? If station cannot connect after a relatively short time, > >> then I think it should scan as widely as it can in order find some possible > way to connect. > >> > > > > The purpose of this heuristic was to handle a very specific corner > > case where there are no APs on the 2GHz/5GHz bands and there are only > > one or more non-collocated APs on the 6GHz band. Based on our > > understanding, this is not a very likely situation and thus, due to > > other consideration e.g., power KPIs etc., the above conditions were > > defined. However, as you can see in the patch, there are options to tune > the heuristic to be more aggressive, and if it would indeed be needed we can > change the behavior such cases. > > Yes, and I can tweak the code myself if needed. But better if upstream > driver is already nice as possible. > As I emphasized above, this entire 6GHz passive scan concept is only targeting a very specific corner case that tries to handle the case that we have no information about the current MCC. I've raised your points with our regulatory team and they further emphasized that for the common use case of station operation, as this is expected to be a rare case, they prefer have this logic as it is implemented. > >> And why care about 'at least 4 channels'. If we know the AP channel, > >> and can scan exactly there, then your concern about taking a long time is > resolved. > >> > > > > The assumption was that while a connection was not established a full > > scan is expected, so that's why the above condition was set. However, > > I'll take this with my colleagues and see if this condition can be > > removed or defined differently. > > The complexity of the restrictions are going to silently break certain configs > that a user can reasonable expect to work I think. Based on the intended use of this flow, we do not think that this is going to break user configurations. > > > > >> How else can we tell the radio that 6E is allowed? I previously > >> tried all sorts of things to enable 6E channels so that I could more > >> easily set the radio to sniff one of those channels in monitor mode, and I > had no luck. > >> > > > > Are you asking specifically for iwlwifi devices? I'm not familiar with > > a simple way to do so other the one described here, but I can check if you > need it. > > Yes. ax210 in particular. > With the current regulatory settings that our NICs ships with, the regulatory team stated that if the device finds enough APs with consistent country code in their beacons (also on legacy bands), e.g., US country code, then the FW would be able to update the MCC, and if the MCC enables the 6GHz channels then they would be enabled. Thus, the special case of 6GHz passive scan would not be needed. > > > >> If all of the 6E channels are marked as passive, what harm is it to > >> enable the channels in the regdom from the beginning? > >> > > > > AFAIK, as the 6GHz regulatory is still evolving, we are not yet > > allowed to do so. But once again, If you are interested I can further check > this our regulatory team. > > Your patch enables passive scan of 6Ghz when no regulatory specifically > allows it. > I think just enabling the band as passive is the same thing, but significantly > simplifies things. If there are regulatory reasons to not allow even passsive > scanning on 6E, then your patch breaks that. If not, then just always allow 6E > channels to be available in passive mode. > The decision was not to enable 6GHz passive scan if not needed as it has a high penalty in terms on time and power KPIs. When the 6GHz channels are enabled, our device follows the discovery mechanisms define in Draft IEEE802.11ax which minimize the scan time and out of channel activity, which is the preferable way. > The logic to optimize scanning time and channels belongs up in the supplicant > and other higher level code that can take user input/config and make > decisions using info that the driver will never have. > Agree on this point, but since current wpa_supplicant version and older ones have no such support than in practice enabling all the 6GHz channels to allow passive scanning by default would incur penalties in scan/connection time and power. Hope this helps. Regards, Ilan.
diff --git a/drivers/net/wireless/intel/iwlwifi/fw/api/scan.h b/drivers/net/wireless/intel/iwlwifi/fw/api/scan.h index 6b8ca35cec1a..b2605aefc290 100644 --- a/drivers/net/wireless/intel/iwlwifi/fw/api/scan.h +++ b/drivers/net/wireless/intel/iwlwifi/fw/api/scan.h @@ -634,6 +634,12 @@ enum iwl_umac_scan_general_flags2 { * @IWL_UMAC_SCAN_GEN_FLAGS_V2_TRIGGER_UHB_SCAN: at the end of 2.4GHz and * 5.2Ghz bands scan, trigger scan on 6GHz band to discover * the reported collocated APs + * @IWL_UMAC_SCAN_GEN_FLAGS_V2_6GHZ_PASSIVE_SCAN: at the end of 2.4GHz and 5GHz + * bands scan, if not APs were discovered, allow scan to conitnue and scan + * 6GHz PSC channels in order to discover country information. + * @IWL_UMAC_SCAN_GEN_FLAGS_V2_6GHZ_PASSIVE_SCAN_FILTER_IN: in case + * &IWL_UMAC_SCAN_GEN_FLAGS_V2_6GHZ_PASSIVE_SCAN is enabled and scan is + * activated over 6GHz PSC channels, filter in beacons and probe responses. */ enum iwl_umac_scan_general_flags_v2 { IWL_UMAC_SCAN_GEN_FLAGS_V2_PERIODIC = BIT(0), @@ -649,6 +655,8 @@ enum iwl_umac_scan_general_flags_v2 { IWL_UMAC_SCAN_GEN_FLAGS_V2_MULTI_SSID = BIT(10), IWL_UMAC_SCAN_GEN_FLAGS_V2_FORCE_PASSIVE = BIT(11), IWL_UMAC_SCAN_GEN_FLAGS_V2_TRIGGER_UHB_SCAN = BIT(12), + IWL_UMAC_SCAN_GEN_FLAGS_V2_6GHZ_PASSIVE_SCAN = BIT(13), + IWL_UMAC_SCAN_GEN_FLAGS_V2_6GHZ_PASSIVE_SCAN_FILTER_IN = BIT(14), }; /** diff --git a/drivers/net/wireless/intel/iwlwifi/fw/file.h b/drivers/net/wireless/intel/iwlwifi/fw/file.h index 35dffcaf5aba..f9c5cf538ad1 100644 --- a/drivers/net/wireless/intel/iwlwifi/fw/file.h +++ b/drivers/net/wireless/intel/iwlwifi/fw/file.h @@ -362,6 +362,8 @@ typedef unsigned int __bitwise iwl_ucode_tlv_capa_t; * @IWL_UCODE_TLV_CAPA_PROTECTED_TWT: Supports protection of TWT action frames * @IWL_UCODE_TLV_CAPA_FW_RESET_HANDSHAKE: Supports the firmware handshake in * reset flow + * @IWL_UCODE_TLV_CAPA_PASSIVE_6GHZ_SCAN: Support for passive scan on 6GHz PSC + * channels even when these are not enabled. * * @NUM_IWL_UCODE_TLV_CAPA: number of bits used */ @@ -408,6 +410,7 @@ enum iwl_ucode_tlv_capa { IWL_UCODE_TLV_CAPA_SESSION_PROT_CMD = (__force iwl_ucode_tlv_capa_t)54, IWL_UCODE_TLV_CAPA_PROTECTED_TWT = (__force iwl_ucode_tlv_capa_t)56, IWL_UCODE_TLV_CAPA_FW_RESET_HANDSHAKE = (__force iwl_ucode_tlv_capa_t)57, + IWL_UCODE_TLV_CAPA_PASSIVE_6GHZ_SCAN = (__force iwl_ucode_tlv_capa_t)58, /* set 2 */ IWL_UCODE_TLV_CAPA_EXTENDED_DTS_MEASURE = (__force iwl_ucode_tlv_capa_t)64, diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/constants.h b/drivers/net/wireless/intel/iwlwifi/mvm/constants.h index 45634302801f..1343f25f1090 100644 --- a/drivers/net/wireless/intel/iwlwifi/mvm/constants.h +++ b/drivers/net/wireless/intel/iwlwifi/mvm/constants.h @@ -117,5 +117,7 @@ #define IWL_MVM_FTM_INITIATOR_SMOOTH_OVERSHOOT 20016 #define IWL_MVM_FTM_INITIATOR_SMOOTH_AGE_SEC 2 #define IWL_MVM_DISABLE_AP_FILS false +#define IWL_MVM_6GHZ_PASSIVE_SCAN_TIMEOUT 3000 /* in seconds */ +#define IWL_MVM_6GHZ_PASSIVE_SCAN_ASSOC_TIMEOUT 60 /* in seconds */ #endif /* __MVM_CONSTANTS_H */ diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/d3.c b/drivers/net/wireless/intel/iwlwifi/mvm/d3.c index a7dc85c704a9..2e28cf299ef4 100644 --- a/drivers/net/wireless/intel/iwlwifi/mvm/d3.c +++ b/drivers/net/wireless/intel/iwlwifi/mvm/d3.c @@ -2028,6 +2028,8 @@ static int __iwl_mvm_resume(struct iwl_mvm *mvm, bool test) mutex_lock(&mvm->mutex); + mvm->last_reset_or_resume_time_jiffies = jiffies; + /* get the BSS vif pointer again */ vif = iwl_mvm_get_bss_vif(mvm); if (IS_ERR_OR_NULL(vif)) diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c index fd35dd31613e..607d5d564928 100644 --- a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c +++ b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c @@ -1099,6 +1099,8 @@ int __iwl_mvm_mac_start(struct iwl_mvm *mvm) iwl_dbg_tlv_time_point(&mvm->fwrt, IWL_FW_INI_TIME_POINT_PERIODIC, NULL); + mvm->last_reset_or_resume_time_jiffies = jiffies; + if (ret && test_bit(IWL_MVM_STATUS_IN_HW_RESTART, &mvm->status)) { /* Something went wrong - we need to finish some cleanup * that normally iwl_mvm_mac_restart_complete() below diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h b/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h index e607ad713f88..e2a37ac7c4b1 100644 --- a/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h +++ b/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h @@ -1096,6 +1096,9 @@ struct iwl_mvm { /* sniffer data to include in radiotap */ __le16 cur_aid; u8 cur_bssid[ETH_ALEN]; + + unsigned long last_6ghz_passive_scan_jiffies; + unsigned long last_reset_or_resume_time_jiffies; }; /* Extract MVM priv from op_mode and _hw */ diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/scan.c b/drivers/net/wireless/intel/iwlwifi/mvm/scan.c index caf87f320094..5a0696c44f6d 100644 --- a/drivers/net/wireless/intel/iwlwifi/mvm/scan.c +++ b/drivers/net/wireless/intel/iwlwifi/mvm/scan.c @@ -43,6 +43,9 @@ /* adaptive dwell number of APs override for social channels */ #define IWL_SCAN_ADWELL_N_APS_SOCIAL_CHS 2 +/* minimal number of 2GHz and 5GHz channels in the regular scan request */ +#define IWL_MVM_6GHZ_PASSIVE_SCAN_MIN_CHANS 4 + struct iwl_mvm_scan_timing_params { u32 suspend_time; u32 max_out_time; @@ -94,6 +97,7 @@ struct iwl_mvm_scan_params { struct cfg80211_scan_6ghz_params *scan_6ghz_params; u32 n_6ghz_params; bool scan_6ghz; + bool enable_6ghz_passive; }; static inline void *iwl_mvm_get_scan_req_umac_data(struct iwl_mvm *mvm) @@ -1873,6 +1877,98 @@ static u8 iwl_mvm_scan_umac_chan_flags_v2(struct iwl_mvm *mvm, return flags; } +static void iwl_mvm_scan_6ghz_passive_scan(struct iwl_mvm *mvm, + struct iwl_mvm_scan_params *params, + struct ieee80211_vif *vif) +{ + struct ieee80211_supported_band *sband = + &mvm->nvm_data->bands[NL80211_BAND_6GHZ]; + u32 n_disabled, i; + + params->enable_6ghz_passive = false; + + if (params->scan_6ghz) + return; + + if (!fw_has_capa(&mvm->fw->ucode_capa, + IWL_UCODE_TLV_CAPA_PASSIVE_6GHZ_SCAN)) { + IWL_DEBUG_SCAN(mvm, + "6GHz passive scan: Not supported by FW\n"); + return; + } + + /* 6GHz passive scan allowed only on station interface */ + if (vif->type != NL80211_IFTYPE_STATION) { + IWL_DEBUG_SCAN(mvm, + "6GHz passive scan: not station interface\n"); + return; + } + + /* + * 6GHz passive scan is allowed while associated in a defined time + * interval following HW reset or resume flow + */ + if (vif->bss_conf.assoc && + (time_before(mvm->last_reset_or_resume_time_jiffies + + (IWL_MVM_6GHZ_PASSIVE_SCAN_ASSOC_TIMEOUT * HZ), + jiffies))) { + IWL_DEBUG_SCAN(mvm, "6GHz passive scan: associated\n"); + return; + } + + /* No need for 6GHz passive scan if not enough time elapsed */ + if (time_after(mvm->last_6ghz_passive_scan_jiffies + + (IWL_MVM_6GHZ_PASSIVE_SCAN_TIMEOUT * HZ), jiffies)) { + IWL_DEBUG_SCAN(mvm, + "6GHz passive scan: timeout did not expire\n"); + return; + } + + /* not enough channels in the regular scan request */ + if (params->n_channels < IWL_MVM_6GHZ_PASSIVE_SCAN_MIN_CHANS) { + IWL_DEBUG_SCAN(mvm, + "6GHz passive scan: not enough channels\n"); + return; + } + + for (i = 0; i < params->n_ssids; i++) { + if (!params->ssids[i].ssid_len) + break; + } + + /* not a wildcard scan, so cannot enable passive 6GHz scan */ + if (i == params->n_ssids) { + IWL_DEBUG_SCAN(mvm, + "6GHz passive scan: no wildcard SSID\n"); + return; + } + + if (!sband || !sband->n_channels) { + IWL_DEBUG_SCAN(mvm, + "6GHz passive scan: no 6GHz channels\n"); + return; + } + + for (i = 0, n_disabled = 0; i < sband->n_channels; i++) { + if (sband->channels[i].flags & (IEEE80211_CHAN_DISABLED)) + n_disabled++; + } + + /* + * Not all the 6GHz channels are disabled, so no need for 6GHz passive + * scan + */ + if (n_disabled != sband->n_channels) { + IWL_DEBUG_SCAN(mvm, + "6GHz passive scan: 6GHz channels enabled\n"); + return; + } + + /* all conditions to enable 6ghz passive scan are satisfied */ + IWL_DEBUG_SCAN(mvm, "6GHz passive scan: can be enabled\n"); + params->enable_6ghz_passive = true; +} + static u16 iwl_mvm_scan_umac_flags_v2(struct iwl_mvm *mvm, struct iwl_mvm_scan_params *params, struct ieee80211_vif *vif, @@ -1911,6 +2007,9 @@ static u16 iwl_mvm_scan_umac_flags_v2(struct iwl_mvm *mvm, params->flags & NL80211_SCAN_FLAG_COLOCATED_6GHZ) flags |= IWL_UMAC_SCAN_GEN_FLAGS_V2_TRIGGER_UHB_SCAN; + if (params->enable_6ghz_passive) + flags |= IWL_UMAC_SCAN_GEN_FLAGS_V2_6GHZ_PASSIVE_SCAN; + return flags; } @@ -2183,6 +2282,30 @@ iwl_mvm_scan_umac_fill_ch_p_v6(struct iwl_mvm *mvm, params->n_channels, channel_cfg_flags, vif->type); + + if (params->enable_6ghz_passive) { + struct ieee80211_supported_band *sband = + &mvm->nvm_data->bands[NL80211_BAND_6GHZ]; + u32 i; + + for (i = 0; i < sband->n_channels; i++) { + struct ieee80211_channel *channel = + &sband->channels[i]; + + struct iwl_scan_channel_cfg_umac *cfg = + &cp->channel_config[cp->count]; + + if (!cfg80211_channel_is_psc(channel)) + continue; + + cfg->flags = 0; + cfg->v2.channel_num = channel->hw_value; + cfg->v2.band = PHY_BAND_6; + cfg->v2.iter_count = 1; + cfg->v2.iter_interval = 0; + cp->count++; + } + } } static int iwl_mvm_scan_umac_v12(struct iwl_mvm *mvm, struct ieee80211_vif *vif, @@ -2500,6 +2623,8 @@ int iwl_mvm_reg_scan_start(struct iwl_mvm *mvm, struct ieee80211_vif *vif, iwl_mvm_build_scan_probe(mvm, vif, ies, ¶ms); + iwl_mvm_scan_6ghz_passive_scan(mvm, ¶ms, vif); + uid = iwl_mvm_build_scan_cmd(mvm, vif, &hcmd, ¶ms, IWL_MVM_SCAN_REGULAR); @@ -2524,6 +2649,9 @@ int iwl_mvm_reg_scan_start(struct iwl_mvm *mvm, struct ieee80211_vif *vif, mvm->scan_status |= IWL_MVM_SCAN_REGULAR; mvm->scan_vif = iwl_mvm_vif_from_mac80211(vif); + if (params.enable_6ghz_passive) + mvm->last_6ghz_passive_scan_jiffies = jiffies; + schedule_delayed_work(&mvm->scan_timeout_dwork, msecs_to_jiffies(SCAN_TIMEOUT));