From: Sunil Dutt <[email protected]>
This commit defines new scan flags (LOW_SPAN, LOW_POWER, HIGH_LATENCY)
to emphasize the requested scan behavior for the driver. These flags are
optional and are mutually exclusive. Driver shall resort to default
behavior if a respective flag is not supported. The implementation of
the respective functionality can be driver/hardware specific.
These flags can be used to control the compromise between how long a
scan takes, how much power it uses, and high accurate/complete the scan
is in finding the BSSs.
Signed-off-by: Sunil Dutt <[email protected]>
Signed-off-by: Jouni Malinen <[email protected]>
---
include/uapi/linux/nl80211.h | 23 ++++++++++++++++++++++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 6dd6939..68fdb95 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -5059,6 +5059,11 @@ enum nl80211_timeout_reason {
* of NL80211_CMD_TRIGGER_SCAN and NL80211_CMD_START_SCHED_SCAN
* requests.
*
+ * NL80211_SCAN_FLAG_LOW_SPAN, NL80211_SCAN_FLAG_LOW_POWER, and
+ * NL80211_SCAN_FLAG_HIGH_ACCURACY flags are exclusive of each other, i.e., only
+ * one of them can be used in the request. If the driver does not support the
+ * requested behavior, default scan behavior will be used instead.
+ *
* @NL80211_SCAN_FLAG_LOW_PRIORITY: scan request has low priority
* @NL80211_SCAN_FLAG_FLUSH: flush cache before scanning
* @NL80211_SCAN_FLAG_AP: force a scan even if the interface is configured
@@ -5086,7 +5091,20 @@ enum nl80211_timeout_reason {
* and suppression (if it has received a broadcast Probe Response frame,
* Beacon frame or FILS Discovery frame from an AP that the STA considers
* a suitable candidate for (re-)association - suitable in terms of
- * SSID and/or RSSI
+ * SSID and/or RSSI.
+ * @NL80211_SCAN_FLAG_LOW_SPAN: Span corresponds to the total time taken to
+ * accomplish the scan. Thus, this flag intends the driver to perform the
+ * scan request with lesser span/duration. It is specific to the driver
+ * implementations on how this is accomplished. Scan accuracy may get
+ * impacted with this flag. This flag cannot be used with
+ * @NL80211_SCAN_FLAG_LOW_POWER: This flag intends the scan attempts to consume
+ * optimal possible power. Drivers can resort to their specific means to
+ * optimize the power. Scan accuracy may get impacted with this flag.
+ * @NL80211_SCAN_FLAG_HIGH_ACCURACY: Accuracy here intends to the extent of scan
+ * results obtained. Thus HIGH_ACCURACY scan flag aims to get maximum
+ * possible scan results. This flag hints the driver to use the best
+ * possible scan configuration to improve the accuracy in scanning.
+ * Latency and power use may get impacted with this flag.
*/
enum nl80211_scan_flags {
NL80211_SCAN_FLAG_LOW_PRIORITY = 1<<0,
@@ -5097,6 +5115,9 @@ enum nl80211_scan_flags {
NL80211_SCAN_FLAG_ACCEPT_BCAST_PROBE_RESP = 1<<5,
NL80211_SCAN_FLAG_OCE_PROBE_REQ_HIGH_TX_RATE = 1<<6,
NL80211_SCAN_FLAG_OCE_PROBE_REQ_DEFERRAL_SUPPRESSION = 1<<7,
+ NL80211_SCAN_FLAG_LOW_SPAN = 1<<8,
+ NL80211_SCAN_FLAG_LOW_POWER = 1<<9,
+ NL80211_SCAN_FLAG_HIGH_ACCURACY = 1<<10,
};
/**
--
2.7.4
PiBDYW4ndCB3ZSBoYXZlIHNvbWUga2luZCBvZiBjYXBhYmlsaXR5IGluZGljYXRpb24gdGhhdCB0
aGUgZHJpdmVyIHN1cHBvcnRzIGVhY2ggb2YgdGhlc2UgZmxhZ3Mgb3Igbm90PyAgT3RoZXJ3aXNl
IHdlIGdldCBpbnRvIGEgc2l0dWF0aW9uIHdoZXJlIHlvdSBqdXN0IGhhdmUgdG8gdHJ5IHRoZSBm
bGFnIGFuZCBob3BlIGl0IHdvcmtzLCBzaW5jZSBpdCBkb2Vzbid0IGxvb2sgbGlrZSBkcml2ZXJz
IGFyZSByZXF1aXJlZCB0byBlcnJvciBvdXQgaWYgdGhleSBkb24ndCBzdXBwb3J0IHRoZSBmbGFn
Lg0KU3VyZSBEYW4gLiBXZSBzaGFsbCBoYXZlIHRoZSBzdXBwb3J0IGZvciBjYXBhYmlsaXR5IGlu
ZGljYXRpb24gZnJvbSB0aGUgZHJpdmVyLg0KDQpSZWdhcmRzLA0KU3VuaWwNCg0KIA0KDQotLS0t
LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRGFuIFdpbGxpYW1zIFttYWlsdG86ZGNid0By
ZWRoYXQuY29tXSANClNlbnQ6IFRodXJzZGF5LCBEZWNlbWJlciAxNCwgMjAxNyAxMjo0MCBBTQ0K
VG86IEpvdW5pIE1hbGluZW4gPGpvdW5pQHFjYS5xdWFsY29tbS5jb20+OyBKb2hhbm5lcyBCZXJn
IDxqb2hhbm5lc0BzaXBzb2x1dGlvbnMubmV0Pg0KQ2M6IGxpbnV4LXdpcmVsZXNzQHZnZXIua2Vy
bmVsLm9yZzsgU3VuaWwgRHV0dCBVbmRla2FyaSA8dXNkdXR0QHF0aS5xdWFsY29tbS5jb20+DQpT
dWJqZWN0OiBSZTogW1BBVENIXSBubDgwMjExOiBJbnRyb2R1Y2Ugc2NhbiBmbGFncyB0byBlbXBo
YXNpemUgcmVxdWVzdGVkIHNjYW4gYmVoYXZpb3INCg0KT24gV2VkLCAyMDE3LTEyLTEzIGF0IDE5
OjUyICswMjAwLCBKb3VuaSBNYWxpbmVuIHdyb3RlOg0KPiBGcm9tOiBTdW5pbCBEdXR0IDx1c2R1
dHRAcXRpLnF1YWxjb21tLmNvbT4NCj4gDQo+IFRoaXMgY29tbWl0IGRlZmluZXMgbmV3IHNjYW4g
ZmxhZ3MgKExPV19TUEFOLCBMT1dfUE9XRVIsDQo+IEhJR0hfTEFURU5DWSkNCj4gdG8gZW1waGFz
aXplIHRoZSByZXF1ZXN0ZWQgc2NhbiBiZWhhdmlvciBmb3IgdGhlIGRyaXZlci4gVGhlc2UgZmxh
Z3MgDQo+IGFyZSBvcHRpb25hbCBhbmQgYXJlIG11dHVhbGx5IGV4Y2x1c2l2ZS4gRHJpdmVyIHNo
YWxsIHJlc29ydCB0byANCj4gZGVmYXVsdCBiZWhhdmlvciBpZiBhIHJlc3BlY3RpdmUgZmxhZyBp
cyBub3Qgc3VwcG9ydGVkLiBUaGUgDQo+IGltcGxlbWVudGF0aW9uIG9mIHRoZSByZXNwZWN0aXZl
IGZ1bmN0aW9uYWxpdHkgY2FuIGJlIGRyaXZlci9oYXJkd2FyZSANCj4gc3BlY2lmaWMuDQoNCkNh
bid0IHdlIGhhdmUgc29tZSBraW5kIG9mIGNhcGFiaWxpdHkgaW5kaWNhdGlvbiB0aGF0IHRoZSBk
cml2ZXIgc3VwcG9ydHMgZWFjaCBvZiB0aGVzZSBmbGFncyBvciBub3Q/ICBPdGhlcndpc2Ugd2Ug
Z2V0IGludG8gYSBzaXR1YXRpb24gd2hlcmUgeW91IGp1c3QgaGF2ZSB0byB0cnkgdGhlIGZsYWcg
YW5kIGhvcGUgaXQgd29ya3MsIHNpbmNlIGl0IGRvZXNuJ3QgbG9vayBsaWtlIGRyaXZlcnMgYXJl
IHJlcXVpcmVkIHRvIGVycm9yIG91dCBpZiB0aGV5IGRvbid0IHN1cHBvcnQgdGhlIGZsYWcuDQoN
CkRhbg0KDQo+IFRoZXNlIGZsYWdzIGNhbiBiZSB1c2VkIHRvIGNvbnRyb2wgdGhlIGNvbXByb21p
c2UgYmV0d2VlbiBob3cgbG9uZyBhIA0KPiBzY2FuIHRha2VzLCBob3cgbXVjaCBwb3dlciBpdCB1
c2VzLCBhbmQgaGlnaCBhY2N1cmF0ZS9jb21wbGV0ZSB0aGUgDQo+IHNjYW4gaXMgaW4gZmluZGlu
ZyB0aGUgQlNTcy4NCj4gDQo+IFNpZ25lZC1vZmYtYnk6IFN1bmlsIER1dHQgPHVzZHV0dEBxdGku
cXVhbGNvbW0uY29tPg0KPiBTaWduZWQtb2ZmLWJ5OiBKb3VuaSBNYWxpbmVuIDxqb3VuaUBxY2Eu
cXVhbGNvbW0uY29tPg0KPiAtLS0NCj4gwqBpbmNsdWRlL3VhcGkvbGludXgvbmw4MDIxMS5oIHwg
MjMgKysrKysrKysrKysrKysrKysrKysrKy0NCj4gwqAxIGZpbGUgY2hhbmdlZCwgMjIgaW5zZXJ0
aW9ucygrKSwgMSBkZWxldGlvbigtKQ0KPiANCj4gZGlmZiAtLWdpdCBhL2luY2x1ZGUvdWFwaS9s
aW51eC9ubDgwMjExLmggDQo+IGIvaW5jbHVkZS91YXBpL2xpbnV4L25sODAyMTEuaCBpbmRleCA2
ZGQ2OTM5Li42OGZkYjk1IDEwMDY0NA0KPiAtLS0gYS9pbmNsdWRlL3VhcGkvbGludXgvbmw4MDIx
MS5oDQo+ICsrKyBiL2luY2x1ZGUvdWFwaS9saW51eC9ubDgwMjExLmgNCj4gQEAgLTUwNTksNiAr
NTA1OSwxMSBAQCBlbnVtIG5sODAyMTFfdGltZW91dF9yZWFzb24gew0KPiDCoCAqIG9mIE5MODAy
MTFfQ01EX1RSSUdHRVJfU0NBTiBhbmQgTkw4MDIxMV9DTURfU1RBUlRfU0NIRURfU0NBTg0KPiDC
oCAqIHJlcXVlc3RzLg0KPiDCoCAqDQo+ICsgKiBOTDgwMjExX1NDQU5fRkxBR19MT1dfU1BBTiwg
Tkw4MDIxMV9TQ0FOX0ZMQUdfTE9XX1BPV0VSLCBhbmQNCj4gKyAqIE5MODAyMTFfU0NBTl9GTEFH
X0hJR0hfQUNDVVJBQ1kgZmxhZ3MgYXJlIGV4Y2x1c2l2ZSBvZiBlYWNoDQo+IG90aGVyLCBpLmUu
LCBvbmx5DQo+ICsgKiBvbmUgb2YgdGhlbSBjYW4gYmUgdXNlZCBpbiB0aGUgcmVxdWVzdC4gSWYg
dGhlIGRyaXZlciBkb2VzIG5vdA0KPiBzdXBwb3J0IHRoZQ0KPiArICogcmVxdWVzdGVkIGJlaGF2
aW9yLCBkZWZhdWx0IHNjYW4gYmVoYXZpb3Igd2lsbCBiZSB1c2VkIGluc3RlYWQuDQo+ICsgKg0K
PiDCoCAqIEBOTDgwMjExX1NDQU5fRkxBR19MT1dfUFJJT1JJVFk6IHNjYW4gcmVxdWVzdCBoYXMg
bG93IHByaW9yaXR5DQo+IMKgICogQE5MODAyMTFfU0NBTl9GTEFHX0ZMVVNIOiBmbHVzaCBjYWNo
ZSBiZWZvcmUgc2Nhbm5pbmcNCj4gwqAgKiBATkw4MDIxMV9TQ0FOX0ZMQUdfQVA6IGZvcmNlIGEg
c2NhbiBldmVuIGlmIHRoZSBpbnRlcmZhY2UgaXMgDQo+IGNvbmZpZ3VyZWQgQEAgLTUwODYsNyAr
NTA5MSwyMCBAQCBlbnVtIG5sODAyMTFfdGltZW91dF9yZWFzb24gew0KPiDCoCAqCWFuZCBzdXBw
cmVzc2lvbiAoaWYgaXQgaGFzIHJlY2VpdmVkIGEgYnJvYWRjYXN0IFByb2JlDQo+IFJlc3BvbnNl
IGZyYW1lLA0KPiDCoCAqCUJlYWNvbiBmcmFtZSBvciBGSUxTIERpc2NvdmVyeSBmcmFtZSBmcm9t
IGFuIEFQIHRoYXQgdGhlDQo+IFNUQSBjb25zaWRlcnMNCj4gwqAgKglhIHN1aXRhYmxlIGNhbmRp
ZGF0ZSBmb3IgKHJlLSlhc3NvY2lhdGlvbiAtIHN1aXRhYmxlIGluDQo+IHRlcm1zIG9mDQo+IC0g
KglTU0lEIGFuZC9vciBSU1NJDQo+ICsgKglTU0lEIGFuZC9vciBSU1NJLg0KPiArICogQE5MODAy
MTFfU0NBTl9GTEFHX0xPV19TUEFOOiBTcGFuIGNvcnJlc3BvbmRzIHRvIHRoZSB0b3RhbCB0aW1l
DQo+IHRha2VuIHRvDQo+ICsgKglhY2NvbXBsaXNoIHRoZSBzY2FuLiBUaHVzLCB0aGlzIGZsYWcg
aW50ZW5kcyB0aGUgZHJpdmVyIHRvDQo+IHBlcmZvcm0gdGhlDQo+ICsgKglzY2FuIHJlcXVlc3Qg
d2l0aCBsZXNzZXIgc3Bhbi9kdXJhdGlvbi4gSXQgaXMgc3BlY2lmaWMgdG8NCj4gdGhlIGRyaXZl
cg0KPiArICoJaW1wbGVtZW50YXRpb25zIG9uIGhvdyB0aGlzIGlzIGFjY29tcGxpc2hlZC4gU2Nh
biBhY2N1cmFjeQ0KPiBtYXkgZ2V0DQo+ICsgKglpbXBhY3RlZCB3aXRoIHRoaXMgZmxhZy4gVGhp
cyBmbGFnIGNhbm5vdCBiZSB1c2VkIHdpdGgNCj4gKyAqIEBOTDgwMjExX1NDQU5fRkxBR19MT1df
UE9XRVI6IFRoaXMgZmxhZyBpbnRlbmRzIHRoZSBzY2FuIGF0dGVtcHRzDQo+IHRvIGNvbnN1bWUN
Cj4gKyAqCW9wdGltYWwgcG9zc2libGUgcG93ZXIuIERyaXZlcnMgY2FuIHJlc29ydCB0byB0aGVp
cg0KPiBzcGVjaWZpYyBtZWFucyB0bw0KPiArICoJb3B0aW1pemUgdGhlIHBvd2VyLiBTY2FuIGFj
Y3VyYWN5IG1heSBnZXQgaW1wYWN0ZWQgd2l0aA0KPiB0aGlzIGZsYWcuDQo+ICsgKiBATkw4MDIx
MV9TQ0FOX0ZMQUdfSElHSF9BQ0NVUkFDWTogQWNjdXJhY3kgaGVyZSBpbnRlbmRzIHRvIHRoZQ0K
PiBleHRlbnQgb2Ygc2Nhbg0KPiArICoJcmVzdWx0cyBvYnRhaW5lZC4gVGh1cyBISUdIX0FDQ1VS
QUNZIHNjYW4gZmxhZyBhaW1zIHRvIGdldA0KPiBtYXhpbXVtDQo+ICsgKglwb3NzaWJsZSBzY2Fu
IHJlc3VsdHMuIFRoaXMgZmxhZyBoaW50cyB0aGUgZHJpdmVyIHRvIHVzZQ0KPiB0aGUgYmVzdA0K
PiArICoJcG9zc2libGUgc2NhbiBjb25maWd1cmF0aW9uIHRvIGltcHJvdmUgdGhlIGFjY3VyYWN5
IGluDQo+IHNjYW5uaW5nLg0KPiArICoJTGF0ZW5jeSBhbmQgcG93ZXIgdXNlIG1heSBnZXQgaW1w
YWN0ZWQgd2l0aCB0aGlzIGZsYWcuDQo+IMKgICovDQo+IMKgZW51bSBubDgwMjExX3NjYW5fZmxh
Z3Mgew0KPiDCoAlOTDgwMjExX1NDQU5fRkxBR19MT1dfUFJJT1JJVFkJCQkJDQo+ID0gMTw8MCwN
Cj4gQEAgLTUwOTcsNiArNTExNSw5IEBAIGVudW0gbmw4MDIxMV9zY2FuX2ZsYWdzIHsNCj4gwqAJ
Tkw4MDIxMV9TQ0FOX0ZMQUdfQUNDRVBUX0JDQVNUX1BST0JFX1JFU1AJCT0NCj4gMTw8NSwNCj4g
wqAJTkw4MDIxMV9TQ0FOX0ZMQUdfT0NFX1BST0JFX1JFUV9ISUdIX1RYX1JBVEUJCQ0KPiA9IDE8
PDYsDQo+IMKgCU5MODAyMTFfU0NBTl9GTEFHX09DRV9QUk9CRV9SRVFfREVGRVJSQUxfU1VQUFJF
U1NJT04JDQo+ID0gMTw8NywNCj4gKwlOTDgwMjExX1NDQU5fRkxBR19MT1dfU1BBTgkJCQk9DQo+
IDE8PDgsDQo+ICsJTkw4MDIxMV9TQ0FOX0ZMQUdfTE9XX1BPV0VSCQkJCT0NCj4gMTw8OSwNCj4g
KwlOTDgwMjExX1NDQU5fRkxBR19ISUdIX0FDQ1VSQUNZCQkJCQ0KPiA9IDE8PDEwLA0KPiDCoH07
DQo+IMKgDQo+IMKgLyoqDQo=
On Wed, 2017-12-13 at 19:52 +0200, Jouni Malinen wrote:
> From: Sunil Dutt <[email protected]>
>
> This commit defines new scan flags (LOW_SPAN, LOW_POWER,
> HIGH_LATENCY)
> to emphasize the requested scan behavior for the driver. These flags
> are
> optional and are mutually exclusive. Driver shall resort to default
> behavior if a respective flag is not supported. The implementation of
> the respective functionality can be driver/hardware specific.
Can't we have some kind of capability indication that the driver
supports each of these flags or not? Otherwise we get into a situation
where you just have to try the flag and hope it works, since it doesn't
look like drivers are required to error out if they don't support the
flag.
Dan
> These flags can be used to control the compromise between how long a
> scan takes, how much power it uses, and high accurate/complete the
> scan
> is in finding the BSSs.
>
> Signed-off-by: Sunil Dutt <[email protected]>
> Signed-off-by: Jouni Malinen <[email protected]>
> ---
> include/uapi/linux/nl80211.h | 23 ++++++++++++++++++++++-
> 1 file changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/include/uapi/linux/nl80211.h
> b/include/uapi/linux/nl80211.h
> index 6dd6939..68fdb95 100644
> --- a/include/uapi/linux/nl80211.h
> +++ b/include/uapi/linux/nl80211.h
> @@ -5059,6 +5059,11 @@ enum nl80211_timeout_reason {
> * of NL80211_CMD_TRIGGER_SCAN and NL80211_CMD_START_SCHED_SCAN
> * requests.
> *
> + * NL80211_SCAN_FLAG_LOW_SPAN, NL80211_SCAN_FLAG_LOW_POWER, and
> + * NL80211_SCAN_FLAG_HIGH_ACCURACY flags are exclusive of each
> other, i.e., only
> + * one of them can be used in the request. If the driver does not
> support the
> + * requested behavior, default scan behavior will be used instead.
> + *
> * @NL80211_SCAN_FLAG_LOW_PRIORITY: scan request has low priority
> * @NL80211_SCAN_FLAG_FLUSH: flush cache before scanning
> * @NL80211_SCAN_FLAG_AP: force a scan even if the interface is
> configured
> @@ -5086,7 +5091,20 @@ enum nl80211_timeout_reason {
> * and suppression (if it has received a broadcast Probe
> Response frame,
> * Beacon frame or FILS Discovery frame from an AP that the
> STA considers
> * a suitable candidate for (re-)association - suitable in
> terms of
> - * SSID and/or RSSI
> + * SSID and/or RSSI.
> + * @NL80211_SCAN_FLAG_LOW_SPAN: Span corresponds to the total time
> taken to
> + * accomplish the scan. Thus, this flag intends the driver to
> perform the
> + * scan request with lesser span/duration. It is specific to
> the driver
> + * implementations on how this is accomplished. Scan accuracy
> may get
> + * impacted with this flag. This flag cannot be used with
> + * @NL80211_SCAN_FLAG_LOW_POWER: This flag intends the scan attempts
> to consume
> + * optimal possible power. Drivers can resort to their
> specific means to
> + * optimize the power. Scan accuracy may get impacted with
> this flag.
> + * @NL80211_SCAN_FLAG_HIGH_ACCURACY: Accuracy here intends to the
> extent of scan
> + * results obtained. Thus HIGH_ACCURACY scan flag aims to get
> maximum
> + * possible scan results. This flag hints the driver to use
> the best
> + * possible scan configuration to improve the accuracy in
> scanning.
> + * Latency and power use may get impacted with this flag.
> */
> enum nl80211_scan_flags {
> NL80211_SCAN_FLAG_LOW_PRIORITY
> = 1<<0,
> @@ -5097,6 +5115,9 @@ enum nl80211_scan_flags {
> NL80211_SCAN_FLAG_ACCEPT_BCAST_PROBE_RESP =
> 1<<5,
> NL80211_SCAN_FLAG_OCE_PROBE_REQ_HIGH_TX_RATE
> = 1<<6,
> NL80211_SCAN_FLAG_OCE_PROBE_REQ_DEFERRAL_SUPPRESSION
> = 1<<7,
> + NL80211_SCAN_FLAG_LOW_SPAN =
> 1<<8,
> + NL80211_SCAN_FLAG_LOW_POWER =
> 1<<9,
> + NL80211_SCAN_FLAG_HIGH_ACCURACY
> = 1<<10,
> };
>
> /**
On 12/14/2017 7:16 PM, Sunil Dutt Undekari wrote:
>> Can't we have some kind of capability indication that the driver supports each of these flags or not? Otherwise we get into a situation where you just have to try the flag and hope it works, since it doesn't look like drivers are required to error out if they don't support the flag.
> Sure Dan . We shall have the support for capability indication from the driver.
No top-post please. The capability indication should be done through the
nl80211 api so I would expect to see a patch for that or just included
in this patch. So maybe in struct wiphy add supported_scan_flags field
and provide that through NL80211_CMD_GET_WIPHY command.
Regards,
Arend
> Regards,
> Sunil
>
>
>
> -----Original Message-----
> From: Dan Williams [mailto:[email protected]]
> Sent: Thursday, December 14, 2017 12:40 AM
> To: Jouni Malinen <[email protected]>; Johannes Berg <[email protected]>
> Cc: [email protected]; Sunil Dutt Undekari <[email protected]>
> Subject: Re: [PATCH] nl80211: Introduce scan flags to emphasize requested scan behavior
>
> On Wed, 2017-12-13 at 19:52 +0200, Jouni Malinen wrote:
>> From: Sunil Dutt <[email protected]>
>>
>> This commit defines new scan flags (LOW_SPAN, LOW_POWER,
>> HIGH_LATENCY)
>> to emphasize the requested scan behavior for the driver. These flags
>> are optional and are mutually exclusive. Driver shall resort to
>> default behavior if a respective flag is not supported. The
>> implementation of the respective functionality can be driver/hardware
>> specific.
>
> Can't we have some kind of capability indication that the driver supports each of these flags or not? Otherwise we get into a situation where you just have to try the flag and hope it works, since it doesn't look like drivers are required to error out if they don't support the flag.
>
> Dan
>
>> These flags can be used to control the compromise between how long a
>> scan takes, how much power it uses, and high accurate/complete the
>> scan is in finding the BSSs.
>>
>> Signed-off-by: Sunil Dutt <[email protected]>
>> Signed-off-by: Jouni Malinen <[email protected]>
>> ---
>> include/uapi/linux/nl80211.h | 23 ++++++++++++++++++++++-
>> 1 file changed, 22 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/uapi/linux/nl80211.h
>> b/include/uapi/linux/nl80211.h index 6dd6939..68fdb95 100644
>> --- a/include/uapi/linux/nl80211.h
>> +++ b/include/uapi/linux/nl80211.h
>> @@ -5059,6 +5059,11 @@ enum nl80211_timeout_reason {
>> * of NL80211_CMD_TRIGGER_SCAN and NL80211_CMD_START_SCHED_SCAN
>> * requests.
>> *
>> + * NL80211_SCAN_FLAG_LOW_SPAN, NL80211_SCAN_FLAG_LOW_POWER, and
>> + * NL80211_SCAN_FLAG_HIGH_ACCURACY flags are exclusive of each
>> other, i.e., only
>> + * one of them can be used in the request. If the driver does not
>> support the
>> + * requested behavior, default scan behavior will be used instead.
>> + *
>> * @NL80211_SCAN_FLAG_LOW_PRIORITY: scan request has low priority
>> * @NL80211_SCAN_FLAG_FLUSH: flush cache before scanning
>> * @NL80211_SCAN_FLAG_AP: force a scan even if the interface is
>> configured @@ -5086,7 +5091,20 @@ enum nl80211_timeout_reason {
>> * and suppression (if it has received a broadcast Probe
>> Response frame,
>> * Beacon frame or FILS Discovery frame from an AP that the
>> STA considers
>> * a suitable candidate for (re-)association - suitable in
>> terms of
>> - * SSID and/or RSSI
>> + * SSID and/or RSSI.
>> + * @NL80211_SCAN_FLAG_LOW_SPAN: Span corresponds to the total time
>> taken to
>> + * accomplish the scan. Thus, this flag intends the driver to
>> perform the
>> + * scan request with lesser span/duration. It is specific to
>> the driver
>> + * implementations on how this is accomplished. Scan accuracy
>> may get
>> + * impacted with this flag. This flag cannot be used with
>> + * @NL80211_SCAN_FLAG_LOW_POWER: This flag intends the scan attempts
>> to consume
>> + * optimal possible power. Drivers can resort to their
>> specific means to
>> + * optimize the power. Scan accuracy may get impacted with
>> this flag.
>> + * @NL80211_SCAN_FLAG_HIGH_ACCURACY: Accuracy here intends to the
>> extent of scan
>> + * results obtained. Thus HIGH_ACCURACY scan flag aims to get
>> maximum
>> + * possible scan results. This flag hints the driver to use
>> the best
>> + * possible scan configuration to improve the accuracy in
>> scanning.
>> + * Latency and power use may get impacted with this flag.
>> */
>> enum nl80211_scan_flags {
>> NL80211_SCAN_FLAG_LOW_PRIORITY
>> = 1<<0,
>> @@ -5097,6 +5115,9 @@ enum nl80211_scan_flags {
>> NL80211_SCAN_FLAG_ACCEPT_BCAST_PROBE_RESP =
>> 1<<5,
>> NL80211_SCAN_FLAG_OCE_PROBE_REQ_HIGH_TX_RATE
>> = 1<<6,
>> NL80211_SCAN_FLAG_OCE_PROBE_REQ_DEFERRAL_SUPPRESSION
>> = 1<<7,
>> + NL80211_SCAN_FLAG_LOW_SPAN =
>> 1<<8,
>> + NL80211_SCAN_FLAG_LOW_POWER =
>> 1<<9,
>> + NL80211_SCAN_FLAG_HIGH_ACCURACY
>> = 1<<10,
>> };
>>
>> /**
Hi Jouni,
> This commit defines new scan flags (LOW_SPAN, LOW_POWER, HIGH_LATENCY)
> to emphasize the requested scan behavior for the driver. These flags are
> optional and are mutually exclusive. Driver shall resort to default
> behavior if a respective flag is not supported. The implementation of
> the respective functionality can be driver/hardware specific.
I really dislike falling back to some unspecified default behavior in case something is not supported. That is a really bad API towards userspace. Let the driver just fail and reject that operation. Userspace can define the policy and behavior if certain low power or high accuracy functionality is not available. Asking the kernel to do one thing and then the driver does whatever it wants anyway is Wireless Extensions behavior. We complained about it back then and falling back into the same pattern is bad.
And as Dan mentioned, just indicate the capabilities to userspace and then it knows what it can use. That means a good userspace will not use unsupported flags and a bad one gets hit with an error (which is a good thing).
Regards
Marcel