On Monday, March 04, 2013 04:47:59 PM Johannes Berg wrote: > On Wed, 2013-02-27 at 14:24 +0200, Vladimir Kondratiev wrote: > > > Enable p2p find phase offload to the driver. > > Add methods for the struct cfg80211_ops, like > > > > int (*start_p2p_find)(struct wiphy *wiphy, > > struct cfg80211_p2p_find_params *params); > > void (*stop_p2p_find)(struct wiphy *wiphy); > > > > where struct cfg80211_p2p_find_params includes info elements > > to be added for probe request and probe response frames; > > social channels etc. > > We had something like this before. I think you need to specify not the > wiphy but a netdev though, to know what MAC address to use. In fact, not > a netdev but a wdev, so it can work on P2P_Device type wdevs. Why do we need wdev here? It should be similar to scan, as p2p scan composed of legacy scan and p2p find. Scan have only wiphy. It's no problem to add wdev as well, of course. I'll add it. > > Also, timings? Or is that left to the driver? Yes, timing is up to the driver. Point is, firmware may have its reasons when switch search/listen phases. > > > wpa_supplicant will call these methods through nl80211. > > > > Driver responsible for toggling between search and listen states, > > reporting probe request/response frames to the user space. > > > > Driver/firmware may answer to the probe request frames on itself, > > in this case probe requests are still reported. > > wpa_s will need to know whether or not it responded, unless you mandate > that it must respond by itself -- not sure if you should do that though? Same way as today wpa_s know whether driver/firmware answer probes - WIPHY_FLAG_AP_PROBE_RESP_OFFLOAD. Or, should I add one more flag, like WIPHY_FLAG_P2P_PROBE_RESP_OFFLOAD? > > > To satisfy requirements for 60GHz band, additional attribute 'pcp_resolution' > > shall be added to the reported frames, indicating result of the PCP resolution. > > This attribute carries result of PCP factor comparison between probe request > > and response, as defined in the spec for 60GHz. It is enum having values > > 'undefined', 'win' and 'lose'. > > ? > > > For the 2.4GHz band devices, PCP resolution is not used and pcp_resolution > > attribute set to 'undefined' > > No ... you'd just leave out the attribute instead of having a special > undefined value. I think I was not clear here. On nl80211 - yes, just leave out attribute if it is 'undefined', I meant this 'undefined' to be used on driver API level. > > johannes > -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
