| Message ID | 20221222124221.30894-2-quic_youghand@quicinc.com (mailing list archive) |
|---|---|
| State | Changes Requested |
| Delegated to: | Johannes Berg |
| Headers | show |
| Series | Update the channel list if the change in channel flags | expand |
> +++ b/include/net/cfg80211.h > @@ -5386,6 +5386,8 @@ struct wiphy { > void (*reg_notifier)(struct wiphy *wiphy, > struct regulatory_request *request); > > + void (*beacon_hint_notifier)(struct wiphy *wiphy); missing documentation, for sure Also this should probably be in the ops, rather than here? Not sure why reg_notifier is here. > - if (channel_changed) > + if (channel_changed) { > nl80211_send_beacon_hint_event(wiphy, &chan_before, chan); > + if (wiphy->beacon_hint_notifier) > + wiphy->beacon_hint_notifier(wiphy); > + } This also seems excessive if you're not even passing the channel - you call it for every (affected) channel, but you don't tell it anything about the channel? Seems strange. However ... Why is this even needed? You should always get reg_notifier after this anyway? johannes
On 1/18/2023 10:00 PM, Johannes Berg wrote: >> +++ b/include/net/cfg80211.h >> @@ -5386,6 +5386,8 @@ struct wiphy { >> void (*reg_notifier)(struct wiphy *wiphy, >> struct regulatory_request *request); >> >> + void (*beacon_hint_notifier)(struct wiphy *wiphy); > > missing documentation, for sure I will add the missed documentation in next version of patch. > Also this should probably be in the ops, rather than here? Not sure why > reg_notifier is here. I followed reg_notifier implementation. >> - if (channel_changed) >> + if (channel_changed) { >> nl80211_send_beacon_hint_event(wiphy, &chan_before, chan); >> + if (wiphy->beacon_hint_notifier) >> + wiphy->beacon_hint_notifier(wiphy); >> + } > This also seems excessive if you're not even passing the channel - you > call it for every (affected) channel, but you don't tell it anything > about the channel? Seems strange. I will address this in next version of patch. > > > However ... > > Why is this even needed? You should always get reg_notifier after this > anyway? > > johannes Currently when channel flag changed through the beacon hints are not informed to driver. reg_notifier will be triggered for regdomain changes but not for channel flag changes due to beacon hints. Regards, Youghandhar
> > > > Why is this even needed? You should always get reg_notifier after this > > anyway? > > Currently when channel flag changed through the beacon hints are not > informed to driver. > > reg_notifier will be triggered for regdomain changes but not for channel flag changes due to beacon hints. > So maybe triggering reg notifier once would be sufficient, a la Wen's patch that I recently merged? johannes
On 2/15/2023 11:10 PM, Johannes Berg wrote: >>> Why is this even needed? You should always get reg_notifier after this >>> anyway? >> Currently when channel flag changed through the beacon hints are not >> informed to driver. >> >> reg_notifier will be triggered for regdomain changes but not for channel flag changes due to beacon hints. >> > So maybe triggering reg notifier once would be sufficient, a la Wen's > patch that I recently merged? My patch only take effect for this flag, not for all wiphy. if (wiphy->flags & WIPHY_FLAG_NOTIFY_REGDOM_BY_DRIVER) https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit?id=d99975c4953eb79e389d4630e848435c700e2dfc > > johannes >
On Wed, 2023-02-22 at 08:22 +0800, Wen Gong wrote: > On 2/15/2023 11:10 PM, Johannes Berg wrote: > > > > Why is this even needed? You should always get reg_notifier after this > > > > anyway? > > > Currently when channel flag changed through the beacon hints are not > > > informed to driver. > > > > > > reg_notifier will be triggered for regdomain changes but not for channel flag changes due to beacon hints. > > > > > So maybe triggering reg notifier once would be sufficient, a la Wen's > > patch that I recently merged? > > My patch only take effect for this flag, not for all wiphy. > > if (wiphy->flags & WIPHY_FLAG_NOTIFY_REGDOM_BY_DRIVER) > > https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit?id=d99975c4953eb79e389d4630e848435c700e2dfc > Oh sure, I meant this patch could do something similar, instead of introducing a new notifier callback. johannes
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h index 11a370e64143..07b2f2da77d6 100644 --- a/include/net/cfg80211.h +++ b/include/net/cfg80211.h @@ -5386,6 +5386,8 @@ struct wiphy { void (*reg_notifier)(struct wiphy *wiphy, struct regulatory_request *request); + void (*beacon_hint_notifier)(struct wiphy *wiphy); + /* fields below are read-only, assigned by cfg80211 */ const struct ieee80211_regdomain __rcu *regd; diff --git a/net/wireless/reg.c b/net/wireless/reg.c index c3d950d29432..6ea2455d4964 100644 --- a/net/wireless/reg.c +++ b/net/wireless/reg.c @@ -2219,8 +2219,11 @@ static void handle_reg_beacon(struct wiphy *wiphy, unsigned int chan_idx, channel_changed = true; } - if (channel_changed) + if (channel_changed) { nl80211_send_beacon_hint_event(wiphy, &chan_before, chan); + if (wiphy->beacon_hint_notifier) + wiphy->beacon_hint_notifier(wiphy); + } } /*
There are connection failures in hidden SSID case when the device is with default reg domain WW. For WW reg domain most of the 5 GHz channels are passive. When device listens to the beacon on that channel, the driver is updating its channel flag but firmware is not aware of it and firmware is not sending probes on that channels. Due to this, we are seeing connection failures when the device is trying to connect with hidden SSID AP. In the case of devices using the ath10k driver, it is required to update the change in channel flags to firmware as well. Therefore, we need a mechanism to notify the driver from the regulatory core regarding the channel flag changes. Adding a beacon hint notifier logic, so that drivers can register callbacks to get notified whenever there is a change in channel flags. Signed-off-by: Youghandhar Chintala <quic_youghand@quicinc.com> --- include/net/cfg80211.h | 2 ++ net/wireless/reg.c | 5 ++++- 2 files changed, 6 insertions(+), 1 deletion(-)