> > + int (*del_pmk)(struct wiphy *wiphy, struct > > net_device *dev, > > + const u8 *aa); > > Minor nit, but prefer clr_pmk to clear the pmk. Why? You don't have "the PMK" that you can clear, you have "a PMK" (for the network) and after deleting it you don't have it anymore. You don't have a "cleared PMK" afterwards, you just don't have any. I think the delete makes more sense? > > + * @NL80211_CMD_DEL_PMK: For offloaded 4-Way handshake, delete the > > previously > > + * configured PMK for the authenticator address identified > > by > > + * &NL80211_ATTR_MAC. > > Maybe better to indicate it is for 802.1X. I guess that makes sense. > > + NL80211_EXT_FEATURE_4WAY_HANDSHAKE_STA_1X, > > So do we need this flag. Is the fact that the driver implements the > set_pmk and del_pmk (or clr_pmk) callbacks not sufficient provided > they are listed in the "supported commands" message of wiphy dump > (not in this patch). Which reminds me, is "supported commands" no > longer preferred because that list does not seem complete? It's complicated... We've kinda naturally gravitated towards extended feature flags because they're so easy to handle now (only need to define the bit) - and with mac80211 in the picture, relying on the handlers only often didn't work, so it requires extra code in the CMD() advertising - and anyway it already requires extra code there unlike the feature flags... So overall - while this isn't stated policy (yet?) - I think we prefer the feature bits. johannes
