> > Can we add below additional capabilities also. > Some of the below capabilities make sense to me. I can add few of them now, but in general, I think it would be better to add them together with the API definition of the specific feature they introduce. This way it will be possible to properly describe what exactly is required from the underlying driver/device. > * @NL80211_NAN_CAPA_INSTANT_MODE_SUPPORT: Flag attribute indicating > if the > > * device supports instant mode operation for faster NAN session setup. I think this one should be added together with some command/configuration to enter exist instant communication mode. > * @NL80211_NAN_CAPA_6G_SUPPORT: Flag attribute indicating if the device > * supports NAN operation in 6 GHz band. I will make it more generic. Supported bands bitmap (see my other comment below) > * @NL80211_NAN_CAPA_HE_SUPPORT: Flag attribute indicating if the device > * supports 802.11ax (HE) features in NAN. Same, see my (last) comment regarding device capabilities reporting. > * @NL80211_NAN_CAPA_PAIRING_SUPPORT: Flag attribute indicating if the > device > * supports secure pairing over NAN. PASN pairing + bootstrapping will be done entirely in user space (wpa_supplicant). What exactly this flag means in context of device/driver capabilities? I guess the device should be able to handle all the new keys derived during PASN (NM-TK etc).. I think it's better to define what exactly is expected here and thus, it's better to define together when this feature is implemented. > * @NL80211_NAN_CAPA_SET_CLUSTER_ID_SUPPORT: Flag attribute > indicating if the > * device supports setting a custom cluster ID for NAN operation. Do we really need a capability for that? The device can just ignore what user space configures? Also, this doesn't sound like a very complex requirement, no? And I don't know why it's needed.. > * @NL80211_NAN_CAPA_PERIODIC_RANGING_SUPPORT: Flag attribute > indicating if the > * device supports periodic ranging sessions over NAN. This should be defined together with ranging commands. > * @NL80211_NAN_CAPA_RTT_SUPPORTED_BW: (u32) Bitmask indicating > supported > * bandwidths for RTT (ranging) over NAN. same > * @NL80211_NAN_CAPA_MAX_CONCURRENT_CLUSTERS: (u8) value to > indicate maximum > * number of clusters the device can join concurrently. How come the device can join multiple clusters? The whole idea in NAN is that the clusters shall converge.. How would it work with the existing API's with cluster_join and dw_notification? Anyway, even though I don't understand why and how it can be used, the way to do so is to support multiple NMI interfaces. Reporting interface types combinations already exists in interface combinations API's (NL80211_ATTR_INTERFACE_COMBINATIONS) > * @NL80211_NAN_CAPA_MAX_PUBLISH_SESSIONS: (u8) value to indicate > maximum number > * of concurrent publish sessions supported. > * @NL80211_NAN_CAPA_MAX_SUBSCRIBE_SESSIONS: (u8) value to indicate > maximum What exactly is subsribe/publish *session*? I guess this limitation only applies for the offloaded DE scenario. The existing APIs for offloaded DE use the notion of NAN function, which may be either publish, subsrcribe or follow up. How this *session* limitation applies to it? I think it would be clearer to define it as MAX_DE_FUNCS no? > * number of concurrent subscribe sessions supported. > * @NL80211_NAN_CAPA_MAX_MATCH_FILTER_LEN: (u16) Maximum length > (in > bytes) of an > * individual match filter. > * @NL80211_NAN_CAPA_MAX_TOTAL_MATCH_FILTER_LEN: (u16) Maximum > total length > * (in bytes) of all match filters combined across sessions. Which filters? TX / RX filters? Is this limit applies for both? What about SRF filters? Bloom filter support. I think it > * @NL80211_NAN_CAPA_MAX_SSI_LEN: (u16) Maximum length (in bytes) of > the service > * specific info (SSI) field. This one makes sense, but better define it together with all the other DE limitations. I guess we will need also max for vendor elements and NAN attributes lengths etc. > * @NL80211_NAN_CAPA_MAX_NDI_IFACES: (u8) Maximum number of NAN > Data Interfaces > * (NDI) supported concurrently. NDI is eventually a netdev interface, so it will be reported via existing API's for supported iftypes and combinations. > * @NL80211_NAN_CAPA_MAX_NDP_SESSIONS: (u8) Maximum number of > concurrent NAN > * Data Path (NDP) sessions supported. NDP session is not a real limitation. We can have multiple NDPs between same peers over same NDI reusing the same security. Such NDPs will not consume any resource at all. The proper way to define it, is to report the maximum number of peer NAN stations and NDI's. Since this is not trivial, I prefer to add it together with the definition of NAN datapath APIs. > * @NL80211_NAN_CAPA_MAX_QUEUED_TRANSMIT_FOLLOWUP_MSGS: > (u16) Maximum number of > * follow-up messages that can be queued for transmission. For offloaded DE, as I mentioned before, I think it should be MAX_DE_FUNCS which include both publish, subscribe and follow ups. For non-offloaded case, this limitation doesn't apply as it is just management frame which is transmitted with NL80211_FRAME_CMD, similar to any other management frame. > * @NL80211_NAN_CAPA_MAX_SDEA_SSI_LEN: (u16) Maximum length (in > bytes) of the > * extended service specific info (SDEA SSI) field. There's no need to define both SDEA SSI and SDA SSI as the offloaded DE API (ADD_FUNC) has only one attribute for SSI and it's up to the device to decide whether it should go in SDEA or SDA. Actually the spec defines that SSI with length over 255 bytes should go into SDEA. > * @NL80211_NAN_CAPA_MAX_SUBSCRIBE_ADDRESSES: (u8) Maximum > number of subscribe > * addresses supported. What is subscribe address? I don't think I understand what this means. > * @NL80211_NAN_CAPA_MAX_RX_CHAINS: (u8) Maximum number of > receive chains > * supported for NAN operation. I think it is better to report the entire device capability (similar to the contents of NAN device capability attribute) as it includes everything. - supported bands bitmap - operation mode (which include VHT/HE/80+80 etc support bits) - antennas bitmap (it has both tx and rx antennas) - max channel switch time - capabilities (dfs master bit, extended key_id, simultaneous ndp, ndpe, s3 capable etc..) Andrei
