> On Fri, Jul 26, 2013 at 11:08 AM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx>
> wrote:
> > From: Emmanuel Grumbach <emmanuel.grumbach@xxxxxxxxx>
> >
> > This new API add in cfg80211 wasn't implemented in mac80211.
> > Advertise the capabilities based on the device's implementation
> > (possibly NULL) of crit_prot mac80211 ops.
> >
> > This callback will be called by cfg80211 when hinted by userspace that
> > a critical protocol is happening, e.g. it can be EAPOL, DHCP.
> >
> > Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@xxxxxxxxx>
> > Signed-off-by: Johannes Berg <johannes.berg@xxxxxxxxx>
> > ---
>
> > +static void ieee80211_crit_prot_timeout(struct work_struct *wk) {
> > + struct ieee80211_sub_if_data *sdata;
> > +
> > + sdata = container_of(wk, struct ieee80211_sub_if_data,
> > + crit_prot_end_wk.work);
> > +
> > + drv_crit_proto(sdata->local, sdata, NL80211_CRIT_PROTO_UNSPEC,
> > +false); }
> > +
>
> i think you should call cfg80211_crit_proto_stopped()?
> and even better, maybe provide some callback to let/require the driver
> indicate completion (and implicitly call cfg80211_crit_proto_stopped() there).
Oops, your're right.
Otherwise I won't be able to issue another crit_prot_session since start reads:
if (rdev->crit_proto_nlportid)
return -EBUSY;
The API is just a bit funny: there is a duration, but I am still supposed to call stop when I am done?
If so, why not put the timer internally in cfg80211?
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
