Search Linux Wireless

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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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: signature.asc
Description: Digital signature


[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux