Re: [PATCHv5 3/8] nl80211/cfg80211: add radar detection command/event

[Simon Wunderlich <simon.wunderlich@s2003.tu-chemnitz.de>]

[-- Attachment #1: Type: text/plain, Size: 2136 bytes --]

On Wed, Jan 02, 2013 at 02:39:00PM +0100, Johannes Berg wrote:
> On Thu, 2012-12-13 at 14:58 +0100, Simon Wunderlich wrote:
> 
> > +++ b/include/net/cfg80211.h
> > @@ -133,6 +133,11 @@ enum ieee80211_channel_flags {
> >   *	to enable this, this is useful only on 5 GHz band.
> >   * @orig_mag: internal use
> >   * @orig_mpwr: internal use
> > + * @radar_detect_timeout: this timeout indicates the end of the channel
> > + *	availability check for radar channels (in jiffies), only after this
> > + *	period the user may initiate the tx on the channel.
> > + * @cac_type: indicates that channel availability check is started for this
> > + *	channel type.
> >   */
> >  struct ieee80211_channel {
> >  	enum ieee80211_band band;
> > @@ -145,6 +150,9 @@ struct ieee80211_channel {
> >  	bool beacon_found;
> >  	u32 orig_flags;
> >  	int orig_mag, orig_mpwr;
> > +	unsigned long radar_detect_timeout;
> > +	enum nl80211_channel_type cac_type;
> > +	bool cac_started;
> 
> Since we lock a channel, all of these should probably move to the
> rdev/wiphy struct, I think.

Hm, but when we have completed CAC on phy A, we could use the same
channel on phy B too, right? 

That would be handy if one has two WiFi module and uses one only for
CAC/radar detection (e.g. checking other channels), and another one
doing the real AP service.

> 
> And then the code checking channel contexts needs to be extended to not
> allow another while a channel context is in use:
> 
> > +	mutex_lock(&rdev->devlist_mtx);
> > +	err = cfg80211_can_use_chan(rdev, wdev, chandef.chan,
> > +				    CHAN_MODE_SINGLE_ONLY);
> > +	mutex_unlock(&rdev->devlist_mtx);
> 
> This only does a spot check, keeping state needs to be handled
> separately.

I've extended cfg80211_can_use_iftype_chan() to check for other contexts
in the patch 1 of this series. This should make sure that only one single
mode context can be added, and it can't be added if other contexts are already
present. So you say that is not sufficient?

I guess I'm still not fully understanding the channel context concept ...

Cheers,
	Simon

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]