Support configuring an RSSI threshold in dBm (s32) when requesting
scheduled scan, below which a BSS won't be reported by the cfg80211
driver.
Signed-off-by: Thomas Pedersen <[email protected]>
---
v2:
naming (Kalle)
remove WIPHY_FLAG (Kalle)
use sched_scan_match_attr (Luca)
include/linux/nl80211.h | 3 +++
include/net/cfg80211.h | 2 ++
net/wireless/nl80211.c | 6 +++++-
3 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/include/linux/nl80211.h b/include/linux/nl80211.h
index 970afdf..5c0767f 100644
--- a/include/linux/nl80211.h
+++ b/include/linux/nl80211.h
@@ -1956,6 +1956,8 @@ enum nl80211_reg_rule_attr {
* @__NL80211_SCHED_SCAN_MATCH_ATTR_INVALID: attribute number 0 is reserved
* @NL80211_SCHED_SCAN_MATCH_ATTR_SSID: SSID to be used for matching,
* only report BSS with matching SSID.
+ * @NL80211_ATTR_SCHED_SCAN_MATCH_RSSI: RSSI threshold (in dBm) for reporting a
+ * BSS in scan results. 0 to turn off filtering.
* @NL80211_SCHED_SCAN_MATCH_ATTR_MAX: highest scheduled scan filter
* attribute number currently defined
* @__NL80211_SCHED_SCAN_MATCH_ATTR_AFTER_LAST: internal use
@@ -1964,6 +1966,7 @@ enum nl80211_sched_scan_match_attr {
__NL80211_SCHED_SCAN_MATCH_ATTR_INVALID,
NL80211_ATTR_SCHED_SCAN_MATCH_SSID,
+ NL80211_ATTR_SCHED_SCAN_MATCH_RSSI,
/* keep last */
__NL80211_SCHED_SCAN_MATCH_ATTR_AFTER_LAST,
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 7319f25..891fcd1 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -975,6 +975,7 @@ struct cfg80211_match_set {
* @wiphy: the wiphy this was for
* @dev: the interface
* @channels: channels to scan
+ * @rssi_thold: don't report scan results below this threshold
*/
struct cfg80211_sched_scan_request {
struct cfg80211_ssid *ssids;
@@ -985,6 +986,7 @@ struct cfg80211_sched_scan_request {
size_t ie_len;
struct cfg80211_match_set *match_sets;
int n_match_sets;
+ s32 rssi_thold;
/* internal */
struct wiphy *wiphy;
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 7ae54b8..3945ad6 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -252,6 +252,7 @@ static const struct nla_policy
nl80211_match_policy[NL80211_SCHED_SCAN_MATCH_ATTR_MAX + 1] = {
[NL80211_ATTR_SCHED_SCAN_MATCH_SSID] = { .type = NLA_BINARY,
.len = IEEE80211_MAX_SSID_LEN },
+ [NL80211_ATTR_SCHED_SCAN_MATCH_RSSI] = { .type = NLA_U32 },
};
/* ifidx get helper */
@@ -4241,7 +4242,7 @@ static int nl80211_start_sched_scan(struct sk_buff *skb,
nla_for_each_nested(attr,
info->attrs[NL80211_ATTR_SCHED_SCAN_MATCH],
tmp) {
- struct nlattr *ssid;
+ struct nlattr *ssid, *rssi;
nla_parse(tb, NL80211_SCHED_SCAN_MATCH_ATTR_MAX,
nla_data(attr), nla_len(attr),
@@ -4257,6 +4258,9 @@ static int nl80211_start_sched_scan(struct sk_buff *skb,
request->match_sets[i].ssid.ssid_len =
nla_len(ssid);
}
+ rssi = tb[NL80211_ATTR_SCHED_SCAN_MATCH_SSID];
+ if (rssi)
+ request->rssi_thold = nla_get_u32(rssi);
i++;
}
}
--
1.7.4.1
On Wed, 2012-06-13 at 13:50 -0700, Pedersen, Thomas wrote:
> On Wed, Jun 13, 2012 at 02:56:26PM +0300, Kalle Valo wrote:
> > On 06/13/2012 02:37 PM, Luciano Coelho wrote:
> > > On Wed, 2012-06-13 at 07:40 +0200, Johannes Berg wrote:
> > >> On Tue, 2012-06-12 at 13:43 -0700, Thomas Pedersen wrote:
> > >>> Support configuring an RSSI threshold in dBm (s32) when requesting
> > >>> scheduled scan, below which a BSS won't be reported by the cfg80211
> > >>> driver.
> > >>
> > >> I'm confused -- were you going to do scheduled scan only? Makes sense,
> > >> but if you could maybe change the subject a bit to "specify ... in
> > >> scheduled scan"?
> > >
> > > It makes more sense with scheduled scans, but maybe it is also desirable
> > > with normal scans to reduce the amount of scan results traffic?
> > >
> > > At least if we consider the intermediate scan results that Victor has
> > > been working on... We may want to report all scan results at the end,
> > > but only send intermediate events if all the matches are satisfied, for
> > > example.
> > >
> > > Just thinking out loud a bit.
> >
> > Good point.
> >
> > Funnily enough I don't have any idea how ath6kl has implemented this
> > feature, but in theory this feature is useful also for the current
> > normal scan (when the firmware/hardware supports it) as we can avoid
> > host wakeups. If there are 10 APs, but all are below the RSSI threshold,
> > we will have only 1 host wakeup (scan ready event) opposed to 11 wakeups
> > (10 AP found events plus 1 scan ready event).
>
> But can the host even sleep on normal scans?
Why not? If you're doing a full scan in 11bg + 11a channels it can take
a long time...
Some applications may use very frequent scans, for example for location
services, so saving some wake-ups every time can prove a big improvement
in power consumption in the long run...
> If so, maybe it makes sense to convert NL80211_ATTR_SCHED_SCAN_MATCH
> into general scan matching parameters instead of having a set for each
> scan type?
I'm sure I discussed this with Johannes a long time ago, but now I can't
remember why we decided to keep it for sched scans only...
--
Luca.
@NL80211_ATTR_SCHED_SCAN_MATCH_RSSI
I'd also move around "SCHED" and "ATTR". Look at the attribute names
above or below it, then it's more obvious:
NL80211_SCHED_SCAN_MATCH_ATTR_SSID
NL80211_ATTR_SCHED_SCAN_MATCH_RSSI
NL80211_SCHED_SCAN_MATCH_ATTR_MAX
--
http://www.holgerschurig.de
Fw memory is generally very limited. Maintaining the complete scan results is almost next to impossible. There are also other implications like taking care of duplicates, in case of similar taking the one with higher signal strength, for same AP taking care of size differences b/w probe response and beacon etc.
Passing the results as you receive avoids lot of these complications.
Regards
Naveen
-----Original Message-----
From: Chadd, Adrian
Sent: Thursday, June 14, 2012 12:40 PM
To: Valo, Kalle; Pedersen, Thomas
Cc: Luciano Coelho; Johannes Berg; ath6kl-devel; [email protected]; [email protected]
Subject: RE: [PATCH] nl80211: specify RSSI threshold when scanning
Why then doesn't the host just stay asleep and let the firmware aggregate some scan results, and then fire those up in one message, waking the host up only once?
Adrian
-----Original Message-----
From: Valo, Kalle
Sent: Wednesday, June 13, 2012 11:29 PM
To: Pedersen, Thomas
Cc: Luciano Coelho; Johannes Berg; ath6kl-devel; [email protected]; [email protected]
Subject: Re: [PATCH] nl80211: specify RSSI threshold when scanning
On 06/13/2012 11:50 PM, Pedersen, Thomas wrote:
> On Wed, Jun 13, 2012 at 02:56:26PM +0300, Kalle Valo wrote:
>
>> Funnily enough I don't have any idea how ath6kl has implemented this
>> feature, but in theory this feature is useful also for the current
>> normal scan (when the firmware/hardware supports it) as we can avoid
>> host wakeups. If there are 10 APs, but all are below the RSSI
>> threshold, we will have only 1 host wakeup (scan ready event) opposed
>> to 11 wakeups
>> (10 AP found events plus 1 scan ready event).
>
> But can the host even sleep on normal scans?
It's "implementation defined", the good ones can and bad ones can't :)
But from our (wireless developer) perspective we don't need to care about that, our job is to minimise all possible host wakeup events (timers, interrupts etc) as much as possible. That will allow the host to sleep more.
Kalle
On Wed, 2012-06-13 at 07:53 +0200, Holger Schurig wrote:
> @NL80211_ATTR_SCHED_SCAN_MATCH_RSSI
>
> I'd also move around "SCHED" and "ATTR". Look at the attribute names
> above or below it, then it's more obvious:
>
> NL80211_SCHED_SCAN_MATCH_ATTR_SSID
> NL80211_ATTR_SCHED_SCAN_MATCH_RSSI
> NL80211_SCHED_SCAN_MATCH_ATTR_MAX
Indeed, NL80211_ATTR_* is usually the namespace for the top-level
attributes.
johannes
On Wed, 2012-06-13 at 13:45 -0700, Pedersen, Thomas wrote:
> On Wed, Jun 13, 2012 at 07:53:51AM +0200, Holger Schurig wrote:
> > @NL80211_ATTR_SCHED_SCAN_MATCH_RSSI
> >
> > I'd also move around "SCHED" and "ATTR". Look at the attribute names
> > above or below it, then it's more obvious:
> >
> > NL80211_SCHED_SCAN_MATCH_ATTR_SSID
> > NL80211_ATTR_SCHED_SCAN_MATCH_RSSI
> > NL80211_SCHED_SCAN_MATCH_ATTR_MAX
>
> Makes sense. In wireless-testing HEAD the SSID match attr is actually
> "NL80211_ATTR_SCHED_SCAN_MATCH_SSID".
I just fixed that :)
johannes
Why then doesn't the host just stay asleep and let the firmware aggregate some scan results, and then fire those up in one message, waking the host up only once?
Adrian
-----Original Message-----
From: Valo, Kalle
Sent: Wednesday, June 13, 2012 11:29 PM
To: Pedersen, Thomas
Cc: Luciano Coelho; Johannes Berg; ath6kl-devel; [email protected]; [email protected]
Subject: Re: [PATCH] nl80211: specify RSSI threshold when scanning
On 06/13/2012 11:50 PM, Pedersen, Thomas wrote:
> On Wed, Jun 13, 2012 at 02:56:26PM +0300, Kalle Valo wrote:
>
>> Funnily enough I don't have any idea how ath6kl has implemented this
>> feature, but in theory this feature is useful also for the current
>> normal scan (when the firmware/hardware supports it) as we can avoid
>> host wakeups. If there are 10 APs, but all are below the RSSI
>> threshold, we will have only 1 host wakeup (scan ready event) opposed
>> to 11 wakeups
>> (10 AP found events plus 1 scan ready event).
>
> But can the host even sleep on normal scans?
It's "implementation defined", the good ones can and bad ones can't :)
But from our (wireless developer) perspective we don't need to care about that, our job is to minimise all possible host wakeup events (timers, interrupts etc) as much as possible. That will allow the host to sleep more.
Kalle
On 06/13/2012 11:50 PM, Pedersen, Thomas wrote:
> On Wed, Jun 13, 2012 at 02:56:26PM +0300, Kalle Valo wrote:
>
>> Funnily enough I don't have any idea how ath6kl has implemented this
>> feature, but in theory this feature is useful also for the current
>> normal scan (when the firmware/hardware supports it) as we can avoid
>> host wakeups. If there are 10 APs, but all are below the RSSI threshold,
>> we will have only 1 host wakeup (scan ready event) opposed to 11 wakeups
>> (10 AP found events plus 1 scan ready event).
>
> But can the host even sleep on normal scans?
It's "implementation defined", the good ones can and bad ones can't :)
But from our (wireless developer) perspective we don't need to care
about that, our job is to minimise all possible host wakeup events
(timers, interrupts etc) as much as possible. That will allow the host
to sleep more.
Kalle
Right. What platforms would this be more doable on? Mckinley? Peregrine?
Adrian
-----Original Message-----
From: Singh, Naveen
Sent: Thursday, June 14, 2012 1:21 PM
To: Chadd, Adrian; Valo, Kalle; Pedersen, Thomas
Cc: Luciano Coelho; Johannes Berg; ath6kl-devel; [email protected]; [email protected]
Subject: RE: [PATCH] nl80211: specify RSSI threshold when scanning
Fw memory is generally very limited. Maintaining the complete scan results is almost next to impossible. There are also other implications like taking care of duplicates, in case of similar taking the one with higher signal strength, for same AP taking care of size differences b/w probe response and beacon etc.
Passing the results as you receive avoids lot of these complications.
Regards
Naveen
-----Original Message-----
From: Chadd, Adrian
Sent: Thursday, June 14, 2012 12:40 PM
To: Valo, Kalle; Pedersen, Thomas
Cc: Luciano Coelho; Johannes Berg; ath6kl-devel; [email protected]; [email protected]
Subject: RE: [PATCH] nl80211: specify RSSI threshold when scanning
Why then doesn't the host just stay asleep and let the firmware aggregate some scan results, and then fire those up in one message, waking the host up only once?
Adrian
-----Original Message-----
From: Valo, Kalle
Sent: Wednesday, June 13, 2012 11:29 PM
To: Pedersen, Thomas
Cc: Luciano Coelho; Johannes Berg; ath6kl-devel; [email protected]; [email protected]
Subject: Re: [PATCH] nl80211: specify RSSI threshold when scanning
On 06/13/2012 11:50 PM, Pedersen, Thomas wrote:
> On Wed, Jun 13, 2012 at 02:56:26PM +0300, Kalle Valo wrote:
>
>> Funnily enough I don't have any idea how ath6kl has implemented this
>> feature, but in theory this feature is useful also for the current
>> normal scan (when the firmware/hardware supports it) as we can avoid
>> host wakeups. If there are 10 APs, but all are below the RSSI
>> threshold, we will have only 1 host wakeup (scan ready event) opposed
>> to 11 wakeups
>> (10 AP found events plus 1 scan ready event).
>
> But can the host even sleep on normal scans?
It's "implementation defined", the good ones can and bad ones can't :)
But from our (wireless developer) perspective we don't need to care about that, our job is to minimise all possible host wakeup events (timers, interrupts etc) as much as possible. That will allow the host to sleep more.
Kalle
On Thu, 2012-06-14 at 22:16 +0000, Chadd, Adrian wrote:
> Well, my idea was to keep the host asleep for as long as possible. So maybe only wake up the host when you have either:
>
> * filled the "scan memory" with scan results - so flush those to the host before continuing;
Couldn't getting the "scan memory" full potentially cause you to lose
some results? You might be getting responses while you're processing it,
I guess.
> * finished the scan, and flushing the remaining scan results out.
>
> I'm just raising the idea, it may not be worth doing.. :)
One other thing to keep in mind, that is not directly related with this
last discussion, is the "intermediate scan results" that Victor has
proposed some time ago[1]. For long scans (11bg + 11a), we want to tell
the userspace about the results before the scan completes to save some
time, but we don't want to wake it up excessively when the results don't
really matter.
[1] http://comments.gmane.org/gmane.linux.kernel.wireless.general/76708
--
Luca.
Well, my idea was to keep the host asleep for as long as possible. So maybe only wake up the host when you have either:
* filled the "scan memory" with scan results - so flush those to the host before continuing;
* finished the scan, and flushing the remaining scan results out.
I'm just raising the idea, it may not be worth doing.. :)
Adrian
-----Original Message-----
From: Singh, Naveen
Sent: Thursday, June 14, 2012 2:18 PM
To: Chadd, Adrian; Valo, Kalle; Pedersen, Thomas
Cc: Luciano Coelho; Johannes Berg; ath6kl-devel; [email protected]; [email protected]
Subject: RE: [PATCH] nl80211: specify RSSI threshold when scanning
May not be possible to do in any platform you listed. I could be wrong here but from SW perspective if we decide to do following, it may be feasible:
1. We break down a single scan into multiple scan commands. Each scan just scanning one channel or a set of few channels.
2. FW at least as 4 to 6 Kbytes of memory kept for scan results.
But then there will not be much time left b/w for host to go to sleep.
Regards
Naveen Singh
-----Original Message-----
From: Chadd, Adrian
Sent: Thursday, June 14, 2012 1:41 PM
To: Singh, Naveen; Valo, Kalle; Pedersen, Thomas
Cc: Luciano Coelho; Johannes Berg; ath6kl-devel; [email protected]; [email protected]
Subject: RE: [PATCH] nl80211: specify RSSI threshold when scanning
Right. What platforms would this be more doable on? Mckinley? Peregrine?
Adrian
-----Original Message-----
From: Singh, Naveen
Sent: Thursday, June 14, 2012 1:21 PM
To: Chadd, Adrian; Valo, Kalle; Pedersen, Thomas
Cc: Luciano Coelho; Johannes Berg; ath6kl-devel; [email protected]; [email protected]
Subject: RE: [PATCH] nl80211: specify RSSI threshold when scanning
Fw memory is generally very limited. Maintaining the complete scan results is almost next to impossible. There are also other implications like taking care of duplicates, in case of similar taking the one with higher signal strength, for same AP taking care of size differences b/w probe response and beacon etc.
Passing the results as you receive avoids lot of these complications.
Regards
Naveen
-----Original Message-----
From: Chadd, Adrian
Sent: Thursday, June 14, 2012 12:40 PM
To: Valo, Kalle; Pedersen, Thomas
Cc: Luciano Coelho; Johannes Berg; ath6kl-devel; [email protected]; [email protected]
Subject: RE: [PATCH] nl80211: specify RSSI threshold when scanning
Why then doesn't the host just stay asleep and let the firmware aggregate some scan results, and then fire those up in one message, waking the host up only once?
Adrian
-----Original Message-----
From: Valo, Kalle
Sent: Wednesday, June 13, 2012 11:29 PM
To: Pedersen, Thomas
Cc: Luciano Coelho; Johannes Berg; ath6kl-devel; [email protected]; [email protected]
Subject: Re: [PATCH] nl80211: specify RSSI threshold when scanning
On 06/13/2012 11:50 PM, Pedersen, Thomas wrote:
> On Wed, Jun 13, 2012 at 02:56:26PM +0300, Kalle Valo wrote:
>
>> Funnily enough I don't have any idea how ath6kl has implemented this
>> feature, but in theory this feature is useful also for the current
>> normal scan (when the firmware/hardware supports it) as we can avoid
>> host wakeups. If there are 10 APs, but all are below the RSSI
>> threshold, we will have only 1 host wakeup (scan ready event) opposed
>> to 11 wakeups
>> (10 AP found events plus 1 scan ready event).
>
> But can the host even sleep on normal scans?
It's "implementation defined", the good ones can and bad ones can't :)
But from our (wireless developer) perspective we don't need to care about that, our job is to minimise all possible host wakeup events (timers, interrupts etc) as much as possible. That will allow the host to sleep more.
Kalle
May not be possible to do in any platform you listed. I could be wrong here but from SW perspective if we decide to do following, it may be feasible:
1. We break down a single scan into multiple scan commands. Each scan just scanning one channel or a set of few channels.
2. FW at least as 4 to 6 Kbytes of memory kept for scan results.
But then there will not be much time left b/w for host to go to sleep.
Regards
Naveen Singh
-----Original Message-----
From: Chadd, Adrian
Sent: Thursday, June 14, 2012 1:41 PM
To: Singh, Naveen; Valo, Kalle; Pedersen, Thomas
Cc: Luciano Coelho; Johannes Berg; ath6kl-devel; [email protected]; [email protected]
Subject: RE: [PATCH] nl80211: specify RSSI threshold when scanning
Right. What platforms would this be more doable on? Mckinley? Peregrine?
Adrian
-----Original Message-----
From: Singh, Naveen
Sent: Thursday, June 14, 2012 1:21 PM
To: Chadd, Adrian; Valo, Kalle; Pedersen, Thomas
Cc: Luciano Coelho; Johannes Berg; ath6kl-devel; [email protected]; [email protected]
Subject: RE: [PATCH] nl80211: specify RSSI threshold when scanning
Fw memory is generally very limited. Maintaining the complete scan results is almost next to impossible. There are also other implications like taking care of duplicates, in case of similar taking the one with higher signal strength, for same AP taking care of size differences b/w probe response and beacon etc.
Passing the results as you receive avoids lot of these complications.
Regards
Naveen
-----Original Message-----
From: Chadd, Adrian
Sent: Thursday, June 14, 2012 12:40 PM
To: Valo, Kalle; Pedersen, Thomas
Cc: Luciano Coelho; Johannes Berg; ath6kl-devel; [email protected]; [email protected]
Subject: RE: [PATCH] nl80211: specify RSSI threshold when scanning
Why then doesn't the host just stay asleep and let the firmware aggregate some scan results, and then fire those up in one message, waking the host up only once?
Adrian
-----Original Message-----
From: Valo, Kalle
Sent: Wednesday, June 13, 2012 11:29 PM
To: Pedersen, Thomas
Cc: Luciano Coelho; Johannes Berg; ath6kl-devel; [email protected]; [email protected]
Subject: Re: [PATCH] nl80211: specify RSSI threshold when scanning
On 06/13/2012 11:50 PM, Pedersen, Thomas wrote:
> On Wed, Jun 13, 2012 at 02:56:26PM +0300, Kalle Valo wrote:
>
>> Funnily enough I don't have any idea how ath6kl has implemented this
>> feature, but in theory this feature is useful also for the current
>> normal scan (when the firmware/hardware supports it) as we can avoid
>> host wakeups. If there are 10 APs, but all are below the RSSI
>> threshold, we will have only 1 host wakeup (scan ready event) opposed
>> to 11 wakeups
>> (10 AP found events plus 1 scan ready event).
>
> But can the host even sleep on normal scans?
It's "implementation defined", the good ones can and bad ones can't :)
But from our (wireless developer) perspective we don't need to care about that, our job is to minimise all possible host wakeup events (timers, interrupts etc) as much as possible. That will allow the host to sleep more.
Kalle
On Wed, 2012-06-13 at 07:40 +0200, Johannes Berg wrote:
> On Tue, 2012-06-12 at 13:43 -0700, Thomas Pedersen wrote:
> > Support configuring an RSSI threshold in dBm (s32) when requesting
> > scheduled scan, below which a BSS won't be reported by the cfg80211
> > driver.
>
> I'm confused -- were you going to do scheduled scan only? Makes sense,
> but if you could maybe change the subject a bit to "specify ... in
> scheduled scan"?
It makes more sense with scheduled scans, but maybe it is also desirable
with normal scans to reduce the amount of scan results traffic?
At least if we consider the intermediate scan results that Victor has
been working on... We may want to report all scan results at the end,
but only send intermediate events if all the matches are satisfied, for
example.
Just thinking out loud a bit.
--
Luca.
On Tue, 2012-06-12 at 13:43 -0700, Thomas Pedersen wrote:
> Support configuring an RSSI threshold in dBm (s32) when requesting
> scheduled scan, below which a BSS won't be reported by the cfg80211
> driver.
I'm confused -- were you going to do scheduled scan only? Makes sense,
but if you could maybe change the subject a bit to "specify ... in
scheduled scan"?
> + * @NL80211_ATTR_SCHED_SCAN_MATCH_RSSI: RSSI threshold (in dBm) for reporting a
> + * BSS in scan results. 0 to turn off filtering.
No ... leave out to turn off filtering.
> + * @rssi_thold: don't report scan results below this threshold
would be good to repeat the units
> + rssi = tb[NL80211_ATTR_SCHED_SCAN_MATCH_SSID];
rssi = ... SSID :-)
johannes
On Wed, Jun 13, 2012 at 02:56:26PM +0300, Kalle Valo wrote:
> On 06/13/2012 02:37 PM, Luciano Coelho wrote:
> > On Wed, 2012-06-13 at 07:40 +0200, Johannes Berg wrote:
> >> On Tue, 2012-06-12 at 13:43 -0700, Thomas Pedersen wrote:
> >>> Support configuring an RSSI threshold in dBm (s32) when requesting
> >>> scheduled scan, below which a BSS won't be reported by the cfg80211
> >>> driver.
> >>
> >> I'm confused -- were you going to do scheduled scan only? Makes sense,
> >> but if you could maybe change the subject a bit to "specify ... in
> >> scheduled scan"?
> >
> > It makes more sense with scheduled scans, but maybe it is also desirable
> > with normal scans to reduce the amount of scan results traffic?
> >
> > At least if we consider the intermediate scan results that Victor has
> > been working on... We may want to report all scan results at the end,
> > but only send intermediate events if all the matches are satisfied, for
> > example.
> >
> > Just thinking out loud a bit.
>
> Good point.
>
> Funnily enough I don't have any idea how ath6kl has implemented this
> feature, but in theory this feature is useful also for the current
> normal scan (when the firmware/hardware supports it) as we can avoid
> host wakeups. If there are 10 APs, but all are below the RSSI threshold,
> we will have only 1 host wakeup (scan ready event) opposed to 11 wakeups
> (10 AP found events plus 1 scan ready event).
But can the host even sleep on normal scans?
If so, maybe it makes sense to convert NL80211_ATTR_SCHED_SCAN_MATCH
into general scan matching parameters instead of having a set for each
scan type?
Thomas
On Wed, Jun 13, 2012 at 07:53:51AM +0200, Holger Schurig wrote:
> @NL80211_ATTR_SCHED_SCAN_MATCH_RSSI
>
> I'd also move around "SCHED" and "ATTR". Look at the attribute names
> above or below it, then it's more obvious:
>
> NL80211_SCHED_SCAN_MATCH_ATTR_SSID
> NL80211_ATTR_SCHED_SCAN_MATCH_RSSI
> NL80211_SCHED_SCAN_MATCH_ATTR_MAX
Makes sense. In wireless-testing HEAD the SSID match attr is actually
"NL80211_ATTR_SCHED_SCAN_MATCH_SSID".
Thomas
On 06/13/2012 02:37 PM, Luciano Coelho wrote:
> On Wed, 2012-06-13 at 07:40 +0200, Johannes Berg wrote:
>> On Tue, 2012-06-12 at 13:43 -0700, Thomas Pedersen wrote:
>>> Support configuring an RSSI threshold in dBm (s32) when requesting
>>> scheduled scan, below which a BSS won't be reported by the cfg80211
>>> driver.
>>
>> I'm confused -- were you going to do scheduled scan only? Makes sense,
>> but if you could maybe change the subject a bit to "specify ... in
>> scheduled scan"?
>
> It makes more sense with scheduled scans, but maybe it is also desirable
> with normal scans to reduce the amount of scan results traffic?
>
> At least if we consider the intermediate scan results that Victor has
> been working on... We may want to report all scan results at the end,
> but only send intermediate events if all the matches are satisfied, for
> example.
>
> Just thinking out loud a bit.
Good point.
Funnily enough I don't have any idea how ath6kl has implemented this
feature, but in theory this feature is useful also for the current
normal scan (when the firmware/hardware supports it) as we can avoid
host wakeups. If there are 10 APs, but all are below the RSSI threshold,
we will have only 1 host wakeup (scan ready event) opposed to 11 wakeups
(10 AP found events plus 1 scan ready event).
Kalle