[RFC 1/2] cfg80211: advertise extended capabilities to userspace

[RFC 1/2] cfg80211: advertise extended capabilities to userspace

[Johannes Berg]

From: Johannes Berg <johannes.berg@intel.com>

In many cases, userspace may need to know which of the
extended capabilities are implemented in the driver or
device, to include them e.g. in beacons, association
request/response or other frames. Add a new nl80211
attribute that holds the extended capabilities bitmap
supported by the driver/device for this.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
 include/net/cfg80211.h       | 7 +++++++
 include/uapi/linux/nl80211.h | 5 +++++
 net/wireless/nl80211.c       | 6 ++++++
 3 files changed, 18 insertions(+)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index bc670b2..04801f4 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -2463,6 +2463,10 @@ struct wiphy_wowlan_support {
  *
  * @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
+ * @extended_capabilities_len: length of the extended capabilities
  */
 struct wiphy {
 	/* assign these fields before you register the wiphy */
@@ -2529,6 +2533,9 @@ struct wiphy {
 	 */
 	u32 probe_resp_offload;
 
+	const u8 *extended_capabilities;
+	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
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 1ed7e1c..e0b6424 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -1342,6 +1342,9 @@ enum nl80211_commands {
  *	number of MAC addresses that a device can support for MAC
  *	ACL.
  *
+ * @NL80211_ATTR_EXT_CAPA: Extended capabilities that the kernel driver
+ *	has and handles. The format is the same as the IE contents.
+ *
  * @NL80211_ATTR_MAX: highest attribute number currently defined
  * @__NL80211_ATTR_AFTER_LAST: internal use
  */
@@ -1620,6 +1623,8 @@ enum nl80211_attrs {
 
 	NL80211_ATTR_MAC_ACL_MAX,
 
+	NL80211_ATTR_EXT_CAPA,
+
 	/* add attributes here, update the policy in nl80211.c */
 
 	__NL80211_ATTR_AFTER_LAST,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index b19c822..86a982b 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -1354,6 +1354,12 @@ static int nl80211_send_wiphy(struct sk_buff *msg, u32 portid, u32 seq, int flag
 			dev->wiphy.max_acl_mac_addrs))
 		goto nla_put_failure;
 
+	if (dev->wiphy.extended_capabilities &&
+	    nla_put(msg, NL80211_ATTR_EXT_CAPA,
+		    dev->wiphy.extended_capabilities_len,
+		    dev->wiphy.extended_capabilities))
+		goto nla_put_failure;
+
 	return genlmsg_end(msg, hdr);
 
  nla_put_failure:
-- 
1.8.0

[RFC 2/2] mac80211: advertise operating mode notification capability

[Johannes Berg]

From: Johannes Berg <johannes.berg@intel.com>

Use the new extended capabilities advertising to advertise
the fact that operating mode notification is supported.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
 include/linux/ieee80211.h | 2 ++
 net/mac80211/main.c       | 8 ++++++++
 2 files changed, 10 insertions(+)

diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
index 4aed928..9164c45 100644
--- a/include/linux/ieee80211.h
+++ b/include/linux/ieee80211.h
@@ -1788,6 +1788,8 @@ enum ieee80211_tdls_actioncode {
 #define WLAN_EXT_CAPA5_TDLS_ENABLED	BIT(5)
 #define WLAN_EXT_CAPA5_TDLS_PROHIBITED	BIT(6)
 
+#define WLAN_EXT_CAPA8_OPMODE_NOTIF	BIT(6)
+
 /* TDLS specific payload type in the LLC/SNAP header */
 #define WLAN_TDLS_SNAP_RFTYPE	0x2
 
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 38b3468..453865f 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -501,6 +501,11 @@ static const struct ieee80211_ht_cap mac80211_ht_capa_mod_mask = {
 	},
 };
 
+static const u8 extended_capabilities[] = {
+	0, 0, 0, 0, 0, 0, 0,
+	WLAN_EXT_CAPA8_OPMODE_NOTIF,
+};
+
 struct ieee80211_hw *ieee80211_alloc_hw(size_t priv_data_len,
 					const struct ieee80211_ops *ops)
 {
@@ -557,6 +562,9 @@ struct ieee80211_hw *ieee80211_alloc_hw(size_t priv_data_len,
 			WIPHY_FLAG_REPORTS_OBSS |
 			WIPHY_FLAG_OFFCHAN_TX;
 
+	wiphy->extended_capabilities = extended_capabilities;
+	wiphy->extended_capabilities_len = ARRAY_SIZE(extended_capabilities);
+
 	if (ops->remain_on_channel)
 		wiphy->flags |= WIPHY_FLAG_HAS_REMAIN_ON_CHANNEL;
 
-- 
1.8.0

Re: [RFC 1/2] cfg80211: advertise extended capabilities to userspace

[Johannes Berg]

On Mon, 2013-02-11 at 15:46 +0100, Johannes Berg wrote:

> + * @NL80211_ATTR_EXT_CAPA: Extended capabilities that the kernel driver
> + *	has and handles. The format is the same as the IE contents.

Jouni pointed out that it'd be safer to also have a mask (for those
multi-bit fields that are coming into this ...) so I've made that
change.

johannes

Re: [RFC 1/2] cfg80211: advertise extended capabilities to userspace

[Kalle Valo]

Johannes Berg <johannes@sipsolutions.net> writes:

> From: Johannes Berg <johannes.berg@intel.com>
>
> In many cases, userspace may need to know which of the
> extended capabilities are implemented in the driver or
> device, to include them e.g. in beacons, association
> request/response or other frames. Add a new nl80211
> attribute that holds the extended capabilities bitmap
> supported by the driver/device for this.

[...]

> + * @extended_capabilities: extended capabilities supported by the driver,
> + *	additional capabilities might be supported by userspace
> + * @extended_capabilities_len: length of the extended capabilities

FWIW, when I first looked at the patch I wasn't sure if you were
referring to 802.11 or nl80211 capabilities. I assumed the former. But
clarifying that in the documentation would be good.

-- 
Kalle Valo

Re: [RFC 1/2] cfg80211: advertise extended capabilities to userspace

[Johannes Berg]

On Tue, 2013-02-12 at 15:57 +0200, Kalle Valo wrote:
> Johannes Berg <johannes@sipsolutions.net> writes:
> 
> > From: Johannes Berg <johannes.berg@intel.com>
> >
> > In many cases, userspace may need to know which of the
> > extended capabilities are implemented in the driver or
> > device, to include them e.g. in beacons, association
> > request/response or other frames. Add a new nl80211
> > attribute that holds the extended capabilities bitmap
> > supported by the driver/device for this.
> 
> [...]
> 
> > + * @extended_capabilities: extended capabilities supported by the driver,
> > + *	additional capabilities might be supported by userspace
> > + * @extended_capabilities_len: length of the extended capabilities
> 
> FWIW, when I first looked at the patch I wasn't sure if you were
> referring to 802.11 or nl80211 capabilities. I assumed the former. But
> clarifying that in the documentation would be good.

Makes sense, will do that.

johannes