cfg80211: advertise extended capabilities to userspace
In many cases, userspace may need to know which of the
802.11 extended capabilities ("Extended Capabilities
element") are implemented in the driver or device, to
include them e.g. in beacons, assoc request/response
or other frames. Add a new nl80211 attribute to hold
the extended capabilities bitmap for this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 8a9200f..a229046 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -2480,6 +2480,14 @@
*
* @max_acl_mac_addrs: Maximum number of MAC addresses that the device
* supports for ACL.
+ *
+ * @extended_capabilities: extended capabilities supported by the driver,
+ * additional capabilities might be supported by userspace; these are
+ * the 802.11 extended capabilities ("Extended Capabilities element")
+ * and are in the same format as in the information element. See
+ * 802.11-2012 8.4.2.29 for the defined fields.
+ * @extended_capabilities_mask: mask of the valid values
+ * @extended_capabilities_len: length of the extended capabilities
*/
struct wiphy {
/* assign these fields before you register the wiphy */
@@ -2546,6 +2554,9 @@
*/
u32 probe_resp_offload;
+ const u8 *extended_capabilities, *extended_capabilities_mask;
+ u8 extended_capabilities_len;
+
/* If multiple wiphys are registered and you're handed e.g.
* a regular netdev with assigned ieee80211_ptr, you won't
* know whether it points to a wiphy your driver has registered