| Message ID | 1387486399-4053-4-git-send-email-mcgrof@do-not-panic.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
On Thu, 2013-12-19 at 12:53 -0800, Luis R. Rodriguez wrote: > This adds a trigger to review any pending regulatory > requests whenever an 802.11 device interface is brought > down or up. We use this as an opportunistic trigger > for checking the regulatory work queues as otherwise > they they're only checked upon an initial regulatory > request or when beacon hints are found. > > This opportunistic mechanism can be used to trigger > kicking the queues regulatory queues at any time from > userspace without having to change the regulatory state. I don't like this. Can't we just have a self-contained timeout on the userspace request instead? johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Jan 7, 2014 at 7:35 AM, Johannes Berg <johannes@sipsolutions.net> wrote: > On Thu, 2013-12-19 at 12:53 -0800, Luis R. Rodriguez wrote: >> This adds a trigger to review any pending regulatory >> requests whenever an 802.11 device interface is brought >> down or up. We use this as an opportunistic trigger >> for checking the regulatory work queues as otherwise >> they they're only checked upon an initial regulatory >> request or when beacon hints are found. >> >> This opportunistic mechanism can be used to trigger >> kicking the queues regulatory queues at any time from >> userspace without having to change the regulatory state. > > I don't like this. Can't we just have a self-contained timeout on the > userspace request instead? Sure I'll add this and send a v2 series. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Feb 18, 2014 at 5:24 PM, Luis R. Rodriguez <mcgrof@do-not-panic.com> wrote: > On Tue, Jan 7, 2014 at 7:35 AM, Johannes Berg <johannes@sipsolutions.net> wrote: >> On Thu, 2013-12-19 at 12:53 -0800, Luis R. Rodriguez wrote: >>> This adds a trigger to review any pending regulatory >>> requests whenever an 802.11 device interface is brought >>> down or up. We use this as an opportunistic trigger >>> for checking the regulatory work queues as otherwise >>> they they're only checked upon an initial regulatory >>> request or when beacon hints are found. >>> >>> This opportunistic mechanism can be used to trigger >>> kicking the queues regulatory queues at any time from >>> userspace without having to change the regulatory state. >> >> I don't like this. Can't we just have a self-contained timeout on the >> userspace request instead? > > Sure I'll add this and send a v2 series. Come to think of it -- I am not a fan of the timer. What time do we set for it? What is reasonable? This is what made me instead want to use the notifier hooks. You shouldn't be able to bring up an interface without firmware so hence the hook there, the other one upon register was just another opportunistic one. Please consider this and if you still think a timer is best let me know what the timer value should be :D Luis -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/net/wireless/core.c b/net/wireless/core.c index d89dee2..bc0f518 100644 --- a/net/wireless/core.c +++ b/net/wireless/core.c @@ -812,6 +812,7 @@ static int cfg80211_netdev_notifier_call(struct notifier_block *nb, SET_NETDEV_DEVTYPE(dev, &wiphy_type); break; case NETDEV_REGISTER: + reg_process_pending_work(); /* * NB: cannot take rdev->mtx here because this may be * called within code protected by it when interfaces @@ -871,6 +872,7 @@ static int cfg80211_netdev_notifier_call(struct notifier_block *nb, wake_up(&rdev->dev_wait); break; case NETDEV_UP: + reg_process_pending_work(); cfg80211_update_iface_num(rdev, wdev->iftype, 1); wdev_lock(wdev); switch (wdev->iftype) { diff --git a/net/wireless/reg.c b/net/wireless/reg.c index ecf364e..1a049b3 100644 --- a/net/wireless/reg.c +++ b/net/wireless/reg.c @@ -196,6 +196,11 @@ static DECLARE_WORK(reg_work, reg_todo); static void reg_timeout_work(struct work_struct *work); static DECLARE_DELAYED_WORK(reg_timeout, reg_timeout_work); +void reg_process_pending_work(void) +{ + schedule_work(®_work); +} + /* We keep a static world regulatory domain in case of the absence of CRDA */ static const struct ieee80211_regdomain world_regdom = { .n_reg_rules = 6, diff --git a/net/wireless/reg.h b/net/wireless/reg.h index 02bd8f4..063fb7a 100644 --- a/net/wireless/reg.h +++ b/net/wireless/reg.h @@ -36,6 +36,7 @@ void regulatory_exit(void); int set_regdom(const struct ieee80211_regdomain *rd); bool reg_last_request_cell_base(void); +void reg_process_pending_work(void); /** * regulatory_hint_found_beacon - hints a beacon was found on a channel
This adds a trigger to review any pending regulatory requests whenever an 802.11 device interface is brought down or up. We use this as an opportunistic trigger for checking the regulatory work queues as otherwise they they're only checked upon an initial regulatory request or when beacon hints are found. This opportunistic mechanism can be used to trigger kicking the queues regulatory queues at any time from userspace without having to change the regulatory state. Reported-by: Sander Eikelenboom <linux@eikelenboom.it> Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> --- net/wireless/core.c | 2 ++ net/wireless/reg.c | 5 +++++ net/wireless/reg.h | 1 + 3 files changed, 8 insertions(+)