| Message ID | 20230629035254.2.I23c5e51afcc6173299bb2806c8c38364ad15dd63@changeid (mailing list archive) |
|---|---|
| State | Awaiting Upstream |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | [1/2] wifi: cfg80211: call reg_call_notifier on beacon hints | expand |
Abhishek Kumar <kuabhs@chromium.org> wrote: > Enabling this flag, ensures that reg_call_notifier is called > on beacon hints from handle_reg_beacon in cfg80211. This call > propagates the channel property changes to ath10k driver, thus > changing the channel property from passive scan to active scan > based on beacon hints. > Once the channels are rightly changed from passive to active,the > connection to hidden SSID does not fail. > > Signed-off-by: Abhishek Kumar <kuabhs@chromium.org> There's no Tested-on tag, on which hardware/firmware did you test this? This flag is now enabled on ALL ath10k supported hardware: SNOC, PCI, SDIO and maybe soon USB. I'm just wondering can we trust that this doesn't break anything.
Kalle Valo <kvalo@kernel.org> writes: > Abhishek Kumar <kuabhs@chromium.org> wrote: > >> Enabling this flag, ensures that reg_call_notifier is called >> on beacon hints from handle_reg_beacon in cfg80211. This call >> propagates the channel property changes to ath10k driver, thus >> changing the channel property from passive scan to active scan >> based on beacon hints. >> Once the channels are rightly changed from passive to active,the >> connection to hidden SSID does not fail. >> >> Signed-off-by: Abhishek Kumar <kuabhs@chromium.org> > > There's no Tested-on tag, on which hardware/firmware did you test this? > > This flag is now enabled on ALL ath10k supported hardware: SNOC, PCI, SDIO and > maybe soon USB. I'm just wondering can we trust that this doesn't break > anything. Jeff, what are your thoughts on this? I'm worried how different ath10k firmwares can be and if this breaks something.
On 10/13/2023 10:20 PM, Kalle Valo wrote: > Kalle Valo <kvalo@kernel.org> writes: > >> Abhishek Kumar <kuabhs@chromium.org> wrote: >> >>> Enabling this flag, ensures that reg_call_notifier is called >>> on beacon hints from handle_reg_beacon in cfg80211. This call >>> propagates the channel property changes to ath10k driver, thus >>> changing the channel property from passive scan to active scan >>> based on beacon hints. >>> Once the channels are rightly changed from passive to active,the >>> connection to hidden SSID does not fail. >>> >>> Signed-off-by: Abhishek Kumar <kuabhs@chromium.org> >> >> There's no Tested-on tag, on which hardware/firmware did you test this? >> >> This flag is now enabled on ALL ath10k supported hardware: SNOC, PCI, SDIO and >> maybe soon USB. I'm just wondering can we trust that this doesn't break >> anything. > > Jeff, what are your thoughts on this? I'm worried how different ath10k > firmwares can be and if this breaks something. > Since the 1/2 patch is already in pull-request: wireless-next-2023-10-06 I went through the logic of that again. It would have been nice if that actually described how it fixes the problem. What actually causes a channel to change from passive to active? Note the existing logic prior to the 1/2 patch already updates the wiphy and userspace with the updated channel flags, so it seems reasonable to also update the driver However, this led me down the rabbit hole of trying to figure out what happens if a beacon hint causes us to change a channel from passive to active, but then that AP goes away. What, if anything, causes the channel to revert back to passive? I'm not immediately seeing that logic anywhere. My concern is that we have an AP with a hidden SSID on a DFS channel, and as a result of a beacon hint we switch that channel to active scan. But then later that AP detects radar and vacates the channel. Then we potentially have stations doing active scan on a DFS channel with an active radar. Hopefully this is all handled, and it just isn't obvious in my admittedly very quick 10 minute scan of the code. And as far as the 2/2 patch, note this logic is all dependent upon reg_is_world_roaming(wiphy) returning true, so ath10k impact would really depend upon the board regulatory settings, whether configured for a fixed regulatory domain/country code or configured for world roaming. /jeff
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c index 7675858f069b..12df3228b120 100644 --- a/drivers/net/wireless/ath/ath10k/mac.c +++ b/drivers/net/wireless/ath/ath10k/mac.c @@ -10033,6 +10033,7 @@ int ath10k_mac_register(struct ath10k *ar) ar->hw->wiphy->features |= NL80211_FEATURE_STATIC_SMPS; ar->hw->wiphy->flags |= WIPHY_FLAG_IBSS_RSN; + ar->hw->wiphy->flags |= WIPHY_FLAG_CHANNEL_CHANGE_ON_BEACON; if (ar->ht_cap_info & WMI_HT_CAP_DYNAMIC_SMPS) ar->hw->wiphy->features |= NL80211_FEATURE_DYNAMIC_SMPS;
Enabling this flag, ensures that reg_call_notifier is called on beacon hints from handle_reg_beacon in cfg80211. This call propagates the channel property changes to ath10k driver, thus changing the channel property from passive scan to active scan based on beacon hints. Once the channels are rightly changed from passive to active,the connection to hidden SSID does not fail. Signed-off-by: Abhishek Kumar <kuabhs@chromium.org> --- drivers/net/wireless/ath/ath10k/mac.c | 1 + 1 file changed, 1 insertion(+)