linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Alvin Šipraga" <ALSI@bang-olufsen.dk>
To: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	"johannes@sipsolutions.net" <johannes@sipsolutions.net>
Subject: cfg80211: adding API for triggering a survey
Date: Mon, 29 Mar 2021 00:41:16 +0000	[thread overview]
Message-ID: <96652669-0cad-8cdb-fbe1-4df0f7161102@bang-olufsen.dk> (raw)

Hello,

Currently there is no explicit cfg80211/nl80211 API for triggering a 
channel survey. It seems that all mainline drivers which implement the 
dump_survey rdev op manage to gather survey information during a normal 
scan. While it seems to work perfectly fine in these cases, this 
assumption cannot be made for all devices.

For some context: I am looking into adding survey support for the 
brcmfmac driver, and the firmware interface has a separate, explicit API 
for triggering a survey and reading back the results. There appears to 
be no way to gather survey data through an ordinary scan.

Adding a dump_survey op to brcmfmac is not impossible within the bounds 
of the current cfg80211 API, but it does present some issues. For 
example, some variants of the out-of-tree bcmdhd driver simply trigger 
the survey in the dump_survey function. But doing it like this means 
that a typical survey will hold the RTNL mutex for about 5 seconds - yikes!

So my question is: could the API be extended to support explicitly 
triggering a survey? And if so, how should it look?

The original commit (61fa713c7516 "cfg80211: return channel noise via 
survey API") introducing the dump_survey API notes:

 > In future, there will either be a survey-trigger command --- or the 
existing
 > scan-trigger command will be enhanced. This will allow user-space to
 > request survey for arbitrary channels.

The easiest solution would be just to add an attribute to 
CMD_TRIGGER_SCAN - say NL80211_ATTR_SCAN_SURVEY - to indicate to the 
driver that it should collect survey information if possible. Existing 
drivers would be unaffected (since they already do this implicitly) 
while a driver like brcmfmac could tell the firmware to do an explicit 
survey instead. The only issue I see with this is that there would be no 
new scan results to send back. I wonder if that matters?

Otherwise a new CMD_TRIGGER_SURVEY could be added, and the driver could 
emit CMD_NEW_SURVEY_RESULTS when the survey is complete. I guess the 
implementation here would look a lot like what we already have for 
scanning. I'm not sure how far to take this though - should cfg80211 
also cache the survey results like it does for scans? In that case it 
might also require changes to existing drivers which currently populate 
the survey dump on demand.

I'm quite happy to send some patches for this and I just wanted to get 
some feedback first. I'm less confident about implementing the latter 
approach, particularly if it involves sending patches for drivers I 
cannot test (and for a rather niche feature at that). But if I can get 
some more clarity on what such an interface should look like, I'll see 
what I can do.

Thanks in advance.

Alvin

                 reply	other threads:[~2021-03-29  0:42 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=96652669-0cad-8cdb-fbe1-4df0f7161102@bang-olufsen.dk \
    --to=alsi@bang-olufsen.dk \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    /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).