On Wed, 2022-12-14 at 04:39 -0500, Wen Gong wrote:
> Currently the regulatory driver does not call the regulatory callback
> reg_notifier for self managed wiphys. Sometimes driver needs cfg80211
> to calculate the info of ieee80211_channel such as flags and power,
> and driver needs to get the info of ieee80211_channel after hint of
> driver, but driver does not know when calculation of the info of
> ieee80211_channel become finished, so add notify to driver after
> reg_process_self_managed_hint() from cfg80211 is a good way, then
> driver could get the correct info in callback of reg_notifier.
Seems reasonable - but maybe unexpected to some drivers, perhaps it
should be opt-in?
Though I guess not many drivers actually use this infrastructure in the
first place?
> @@ -3095,6 +3107,13 @@ static void notify_self_managed_wiphys(struct regulatory_request *request)
> if (wiphy->regulatory_flags & REGULATORY_WIPHY_SELF_MANAGED &&
> request->initiator == NL80211_REGDOM_SET_BY_USER)
> reg_call_notifier(wiphy, request);
> +
> + if (wiphy->regulatory_flags & REGULATORY_WIPHY_SELF_MANAGED &&
> + request->initiator == NL80211_REGDOM_SET_BY_DRIVER &&
> + request->wiphy_idx == get_wiphy_idx(wiphy)) {
> + reg_call_notifier(wiphy, request);
> + request->wiphy_idx = WIPHY_IDX_INVALID;
> + }
Why set the request->wiphy_idx here? Should this even go through
reg_process_pending_hints() at all?
> + driver_request = kzalloc(sizeof(struct regulatory_request), GFP_KERNEL);
> + if (!driver_request)
> + return;
> +
> + memcpy(driver_request, &request, sizeof(*driver_request));
kmemdup()?
> + queue_regulatory_request(driver_request);
But again not sure you should do this, rather than calling the notifier
directly?
I mean, you could just do reg_call_notifier() here, it's already async?
johannes
