From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
To: johannes@sipsolutions.net
Cc: linux-wireless@vger.kernel.org, linux@eikelenboom.it,
"Luis R. Rodriguez" <mcgrof@do-not-panic.com>
Subject: [PATCH 2/3] cfg80211: fix processing world regdomain when non modular
Date: Tue, 25 Feb 2014 17:09:41 -0800 [thread overview]
Message-ID: <1393376982-28276-3-git-send-email-mcgrof@do-not-panic.com> (raw)
In-Reply-To: <1393376982-28276-1-git-send-email-mcgrof@do-not-panic.com>
This allows processing of the last regulatory request when
we determine its still pending. Without this if a regulatory
request failed to get processed by userspace we wouldn't
be able to re-process it later. An example situation that can
lead to an unprocessed last_request is enabling cfg80211 to
be built-in to the kernel, not enabling CFG80211_INTERNAL_REGDB
and the CRDA binary not being available at the time the udev
rule that kicks of CRDA triggers.
In such a situation we want to let some cfg80211 triggers
eventually kick CRDA for us again. Without this if the first
cycle attempt to kick off CRDA failed we'd be stuck without
the ability to change process any further regulatory domains.
cfg80211 will trigger re-processing of the regulatory queue
whenever schedule_work(®_work) is called, currently this
happens when:
* suspend / resume
* disconnect
* a beacon hint gets triggered (non DFS 5 GHz AP found)
* a regulatory request gets added to the queue
We don't have any specific opportunistic late boot triggers
to address a late mount of where CRDA resides though, adding
that should be done separately through another patch.
Without an opportunistic fix then this fix relies at least
one of the triggeres above to happen.
Reported-by: Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
---
net/wireless/reg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index f5b120f..7203b74 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -1857,7 +1857,7 @@ static void reg_process_pending_hints(void)
/* When last_request->processed becomes true this will be rescheduled */
if (lr && !lr->processed) {
- REG_DBG_PRINT("Pending regulatory request, waiting for it to be processed...\n");
+ reg_process_hint(lr);
return;
}
--
1.8.5.3
next prev parent reply other threads:[~2014-02-26 1:10 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-26 1:09 [PATCH v2 0/3] cfg80211: respin reprocessing pending requests Luis R. Rodriguez
2014-02-26 1:09 ` [PATCH 1/3] cfg80211: allow reprocessing of " Luis R. Rodriguez
2014-03-03 13:10 ` Johannes Berg
2014-02-26 1:09 ` Luis R. Rodriguez [this message]
2014-03-03 13:10 ` [PATCH 2/3] cfg80211: fix processing world regdomain when non modular Johannes Berg
2014-03-14 20:30 ` Colleen T
2014-03-14 20:48 ` Luis R. Rodriguez
2014-03-14 22:12 ` Colleen T
2014-03-15 1:03 ` Luis R. Rodriguez
2014-03-15 15:59 ` Janusz Dziedzic
2014-03-16 4:42 ` Luis R. Rodriguez
2014-03-16 19:04 ` Colleen T
2014-04-09 16:33 ` Arik Nemtsov
2014-04-09 19:16 ` Johannes Berg
2014-04-10 6:13 ` Arik Nemtsov
2014-04-10 8:01 ` Johannes Berg
2014-04-10 8:17 ` Arik Nemtsov
2014-04-10 8:23 ` Johannes Berg
2014-04-09 20:28 ` Sander Eikelenboom
2014-04-13 12:50 ` Eliad Peller
2014-04-14 19:27 ` Colleen T
2014-04-16 10:38 ` Arik Nemtsov
2014-04-16 11:01 ` Janusz Dziedzic
2014-04-16 11:07 ` Arik Nemtsov
2014-03-19 14:01 ` Johannes Berg
2014-02-26 1:09 ` [PATCH 3/3] cfg80211: processing regulatory requests on netdev notifier Luis R. Rodriguez
2014-02-27 13:21 ` Arik Nemtsov
2014-02-27 17:20 ` Luis R. Rodriguez
2014-02-27 20:31 ` Arik Nemtsov
2014-02-26 7:41 ` [PATCH v2 0/3] cfg80211: respin reprocessing pending requests Sander Eikelenboom
-- strict thread matches above, loose matches on Subject: below --
2013-12-19 20:53 [PATCH 0/3] cfg80211: process pending regulatory requests Luis R. Rodriguez
2013-12-19 20:53 ` [PATCH 2/3] cfg80211: fix processing world regdomain when non modular Luis R. Rodriguez
2014-01-07 15:35 ` Johannes Berg
2014-02-19 1:10 ` Luis R. Rodriguez
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1393376982-28276-3-git-send-email-mcgrof@do-not-panic.com \
--to=mcgrof@do-not-panic.com \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=linux@eikelenboom.it \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).