Re: [RFC v2 2/2] cfg80211: support 4-way handshake offloading for 802.1X

[Johannes Berg <johannes@sipsolutions.net>]

> > +	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