On 2-3-2017 9:59, Johannes Berg wrote: > >>> + 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? Ah. I just looked at set_pmk and felt its counter-part should therefor be clr_pmk. Following your logic should it be add_pmk iso set_pmk? >>> + 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. I see. Glad they worked out that way ;-) Regards, Arend
