Message ID | 1349965104-14475-1-git-send-email-arend@broadcom.com (mailing list archive) |
---|---|
State | Not Applicable, archived |
Headers | show |
On Thu, 2012-10-11 at 16:18 +0200, Arend van Spriel wrote: > The Peer-to-Peer IE is vendor-specific IE identified by WiFi Alliance > OUI and specific P2P OUI type. The payload of this IE consists of > so-called P2P attributes. This patch adds definitions for processing > these attributes. Looks ok ... but why would a driver need to parse P2P stuff? For NoA for example maybe? johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 2012-10-11 at 16:18 +0200, Arend van Spriel wrote: > +++ b/include/linux/ieee80211.h > @@ -168,6 +168,9 @@ > #define IEEE80211_WMM_IE_STA_QOSINFO_SP_MASK 0x03 > #define IEEE80211_WMM_IE_STA_QOSINFO_SP_SHIFT 5 > > +/* Vendor-specific IE */ > +#define IEEE80211_VENDOR_SPEC_IE 0xDD actually this already exists, as ..._EID_VENDOR or so? johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 10/11/2012 06:41 PM, Johannes Berg wrote: > On Thu, 2012-10-11 at 16:18 +0200, Arend van Spriel wrote: >> The Peer-to-Peer IE is vendor-specific IE identified by WiFi Alliance >> OUI and specific P2P OUI type. The payload of this IE consists of >> so-called P2P attributes. This patch adds definitions for processing >> these attributes. > > Looks ok ... but why would a driver need to parse P2P stuff? For NoA for > example maybe? I did not yet go through a lot of the P2P code that is on my plate to port upstream, but one item that is extracted in the part I already did is the P2P listen channel. I just wanted to do this RFC before sending out the brcmfmac code patches that actually is using it. This change will be part of that patch series. Gr. AvS -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 10/11/2012 06:42 PM, Johannes Berg wrote: > On Thu, 2012-10-11 at 16:18 +0200, Arend van Spriel wrote: > >> +++ b/include/linux/ieee80211.h >> @@ -168,6 +168,9 @@ >> #define IEEE80211_WMM_IE_STA_QOSINFO_SP_MASK 0x03 >> #define IEEE80211_WMM_IE_STA_QOSINFO_SP_SHIFT 5 >> >> +/* Vendor-specific IE */ >> +#define IEEE80211_VENDOR_SPEC_IE 0xDD > > actually this already exists, as ..._EID_VENDOR or so? > > johannes > > Thanks, Johannes I probably overlooked it. Let me re-check. Gr. AvS -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 2012-10-11 at 19:23 +0200, Arend van Spriel wrote: > > Looks ok ... but why would a driver need to parse P2P stuff? For NoA for > > example maybe? > > I did not yet go through a lot of the P2P code that is on my plate to > port upstream, but one item that is extracted in the part I already did > is the P2P listen channel. I just wanted to do this RFC before sending > out the brcmfmac code patches that actually is using it. This change > will be part of that patch series. Ah, fmac, that will be somewhat interesting. What userspace APIs are you proposing for that case? johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 10/11/2012 07:24 PM, Arend van Spriel wrote: > On 10/11/2012 06:42 PM, Johannes Berg wrote: >> On Thu, 2012-10-11 at 16:18 +0200, Arend van Spriel wrote: >> >>> +++ b/include/linux/ieee80211.h >>> @@ -168,6 +168,9 @@ >>> #define IEEE80211_WMM_IE_STA_QOSINFO_SP_MASK 0x03 >>> #define IEEE80211_WMM_IE_STA_QOSINFO_SP_SHIFT 5 >>> >>> +/* Vendor-specific IE */ >>> +#define IEEE80211_VENDOR_SPEC_IE 0xDD >> >> actually this already exists, as ..._EID_VENDOR or so? >> >> johannes >> >> > > Thanks, Johannes > > I probably overlooked it. Let me re-check. > Found it. I can even choose: /* Information Element IDs */ enum ieee80211_eid { : WLAN_EID_WPA = 221, WLAN_EID_GENERIC = 221, WLAN_EID_VENDOR_SPECIFIC = 221, : }; Gr. AvS -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 2012-10-11 at 19:29 +0200, Arend van Spriel wrote: > >>> +/* Vendor-specific IE */ > >>> +#define IEEE80211_VENDOR_SPEC_IE 0xDD > >> > >> actually this already exists, as ..._EID_VENDOR or so? > Found it. I can even choose: > > /* Information Element IDs */ > enum ieee80211_eid { > : > WLAN_EID_WPA = 221, > WLAN_EID_GENERIC = 221, > WLAN_EID_VENDOR_SPECIFIC = 221, Heh, funny. Different context and age, I guess. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 10/11/2012 07:26 PM, Johannes Berg wrote: > On Thu, 2012-10-11 at 19:23 +0200, Arend van Spriel wrote: >>> Looks ok ... but why would a driver need to parse P2P stuff? For NoA for >>> example maybe? >> >> I did not yet go through a lot of the P2P code that is on my plate to >> port upstream, but one item that is extracted in the part I already did >> is the P2P listen channel. I just wanted to do this RFC before sending >> out the brcmfmac code patches that actually is using it. This change >> will be part of that patch series. > > Ah, fmac, that will be somewhat interesting. What userspace APIs are you > proposing for that case? Hi Johannes, Not sure if I understand the question. I am using wpa_supplicant with wpa_cli for testing and given its p2p support I assumed there is already a nl80211 api in place. I am still trying to get a good sense on it. The P2P code to port does more parsing of P2P stuff and if you mean adding userspace APIs to avoid just that I would definitely prefer that. Gr. AvS -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 2012-10-11 at 20:05 +0200, Arend van Spriel wrote: > > Ah, fmac, that will be somewhat interesting. What userspace APIs are you > > proposing for that case? > Not sure if I understand the question. I am using wpa_supplicant with > wpa_cli for testing and given its p2p support I assumed there is already > a nl80211 api in place. I am still trying to get a good sense on it. The > P2P code to port does more parsing of P2P stuff and if you mean adding > userspace APIs to avoid just that I would definitely prefer that. Well the APIs that we have in place right now are really basically just a conduit and wpa_s does all the operations. I would expect fmac to have more offloads (and thus need the parsing), I'd actually be surprised if you could work with the existing APIs. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 10/11/2012 09:34 PM, Johannes Berg wrote: > On Thu, 2012-10-11 at 20:05 +0200, Arend van Spriel wrote: > >>> Ah, fmac, that will be somewhat interesting. What userspace APIs are you >>> proposing for that case? > >> Not sure if I understand the question. I am using wpa_supplicant with >> wpa_cli for testing and given its p2p support I assumed there is already >> a nl80211 api in place. I am still trying to get a good sense on it. The >> P2P code to port does more parsing of P2P stuff and if you mean adding >> userspace APIs to avoid just that I would definitely prefer that. > > Well the APIs that we have in place right now are really basically just > a conduit and wpa_s does all the operations. I would expect fmac to have > more offloads (and thus need the parsing), I'd actually be surprised if > you could work with the existing APIs. I mainly focussed on reworking brcmfmac to support multiple (virtual) interfaces and wireless devices without netdev. So far I only did the scanning part of p2p device discovery which is a regular 802.11 scan so no API change needed there. So no API change proposals yet. When I learn more I will discuss it on the wireless list. Gr. AvS -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h index 8c803f0..7c4c075 100644 --- a/include/linux/ieee80211.h +++ b/include/linux/ieee80211.h @@ -168,6 +168,9 @@ #define IEEE80211_WMM_IE_STA_QOSINFO_SP_MASK 0x03 #define IEEE80211_WMM_IE_STA_QOSINFO_SP_SHIFT 5 +/* Vendor-specific IE */ +#define IEEE80211_VENDOR_SPEC_IE 0xDD + #define IEEE80211_HT_CTL_LEN 4 struct ieee80211_hdr { @@ -905,6 +908,81 @@ struct ieee80211_tdls_data { } u; } __packed; +/* + * Peer-to-Peer IE attribute related definitions. + */ +/** + * enum ieee80211_p2p_attr_id - identifies type of peer-to-peer attribute. + */ +enum ieee80211_p2p_attr_id { + IEEE80211_P2P_ATTR_STATUS = 0, + IEEE80211_P2P_ATTR_MINOR_REASON, + IEEE80211_P2P_ATTR_CAPABILITY, + IEEE80211_P2P_ATTR_DEVICE_ID, + IEEE80211_P2P_ATTR_GO_INTENT, + IEEE80211_P2P_ATTR_GO_CONFIG_TIMEOUT, + IEEE80211_P2P_ATTR_LISTEN_CHANNEL, + IEEE80211_P2P_ATTR_GROUP_BSSID, + IEEE80211_P2P_ATTR_EXT_LISTEN_TIMING, + IEEE80211_P2P_ATTR_INTENDED_IFACE_ADDR, + IEEE80211_P2P_ATTR_MANAGABILITY, + IEEE80211_P2P_ATTR_CHANNEL_LIST, + IEEE80211_P2P_ATTR_ABSENCE_NOTICE, + IEEE80211_P2P_ATTR_DEVICE_INFO, + IEEE80211_P2P_ATTR_GROUP_INFO, + IEEE80211_P2P_ATTR_GROUP_ID, + IEEE80211_P2P_ATTR_INTERFACE, + IEEE80211_P2P_ATTR_OPER_CHANNEL, + IEEE80211_P2P_ATTR_INVITE_FLAGS, + /* 19 - 220: Reserved */ + IEEE80211_P2P_ATTR_VENDOR_SPECIFIC = 221, + + IEEE80211_P2P_ATTR_MAX +}; + +struct ieee80211_p2p_chan_attr { + u8 country[3]; + u8 class; + u8 channel; +} __packed; + +/** + * struct ieee80211_p2p_attribute - attributes in WFA P2P vendor specific IE. + * + * @id: identifier according enum ieee80211_p2p_attr_id. + * @length: length of data buffer mapped by @u. + * @u: union holding information for this peer-to-peer attribute. + */ +struct ieee80211_p2p_attribute { + u8 id; + __le16 length; + union { + u8 status; + u8 minor_reason; + struct { + u8 device; + u8 group; + } __packed cap; + u8 devid[6]; + u8 go_intent; + struct { + u8 group; + u8 client; + } __packed cfg_timeout; + struct ieee80211_p2p_chan_attr listen; + u8 bssid[6]; + struct { + __le16 period; + __le16 interval; + } __packed listen_availability; + u8 ifc_addr[6]; + u8 managability; + struct ieee80211_p2p_chan_attr operating; + u8 invitation; + u8 var_attr[0]; + } u; +} __packed; + /** * struct ieee80211_bar - HT Block Ack Request *