Setting aside Kalle's question for a second (though you should address
them, probably before mine!)...
> + * @NL80211_ATTR_CHAN_DEF: attribute for nesting chan_def parameters
> + * as defined in &enum nl80211_ch_def_attr. The new attribute allows
> + * userspace to send a list of struct cfg80211_chan_def. For example, ACS
> + * command uses this attribute for sending a list of channels, for more
> + * details see &NL80211_CMD_ACS.
I don't think this makes sense. Just have an NL80211_ATTR_CHANNEL_LIST
or so, which is like a NLA_POLICY_NESTED_ARRAY, and then inside we can
reuse the existing top-level attributes for how to define a channel.
That'll save you most of the parsing code too.
> /**
> + * enum nl80211_acs_status - ACS status
> + *
> + * status to be used to inform userspace about the result of the ACS
> offloaded
> + * measurement.
> + *
> + * @NL80211_ACS_SUCCESS: The ACS operation finished successfully
> + * @NL80211_ACS_FAILED: Failed to run the ACS. Userspace should choose a
> channel
> + * by itself.
> + */
> +enum nl80211_acs_status {
> + NL80211_ACS_SUCCESS,
> + NL80211_ACS_FAILED,
> +};
It seems like a "successful" flag attribute would be sufficient.
> + dev_put(netdev);
> + dev_hold(dev);
Don't do that. Need to cancel the operation if the netdev is removed
instead.
johannes
