[PATCH 3.15] cfg80211: allow restricting supported dfs regions

[PATCH 3.15] cfg80211: allow restricting supported dfs regions

[Felix Fietkau]

At the moment, the ath9k/ath10k DFS module only supports detecting ETSI
radar patterns.
Add a bitmap in the interface combinations, indicating which DFS regions
are supported by the detector. If unset, support for all regions is
assumed.

Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
 include/net/cfg80211.h |  2 ++
 net/wireless/util.c    | 14 ++++++++++++++
 2 files changed, 16 insertions(+)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index f3539a1..96975fb 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -2618,6 +2618,7 @@ struct ieee80211_iface_limit {
  *	between infrastructure and AP types must match. This is required
  *	only in special cases.
  * @radar_detect_widths: bitmap of channel widths supported for radar detection
+ * @radar_detect_regions: bitmap of regions supported for radar detection
  *
  * With this structure the driver can describe which interface
  * combinations it supports concurrently.
@@ -2675,6 +2676,7 @@ struct ieee80211_iface_combination {
 	u8 n_limits;
 	bool beacon_int_infra_match;
 	u8 radar_detect_widths;
+	u8 radar_detect_regions;
 };
 
 struct ieee80211_txrx_stypes {
diff --git a/net/wireless/util.c b/net/wireless/util.c
index e5872ff..b2fb12a 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -1275,6 +1275,7 @@ int cfg80211_can_use_iftype_chan(struct cfg80211_registered_device *rdev,
 				 enum cfg80211_chan_mode chanmode,
 				 u8 radar_detect)
 {
+	const struct ieee80211_regdomain *regdom;
 	struct wireless_dev *wdev_iter;
 	u32 used_iftypes = BIT(iftype);
 	int num[NUM_NL80211_IFTYPES];
@@ -1283,6 +1284,7 @@ int cfg80211_can_use_iftype_chan(struct cfg80211_registered_device *rdev,
 	struct ieee80211_channel *ch;
 	enum cfg80211_chan_mode chmode;
 	int num_different_channels = 0;
+	enum nl80211_dfs_regions region = 0;
 	int total = 1;
 	int i, j;
 
@@ -1301,6 +1303,14 @@ int cfg80211_can_use_iftype_chan(struct cfg80211_registered_device *rdev,
 		return 0;
 	}
 
+	if (radar_detect) {
+		rcu_read_lock();
+		regdom = rcu_dereference(cfg80211_regdomain);
+		if (regdom)
+			region = regdom->dfs_region;
+		rcu_read_unlock();
+	}
+
 	memset(num, 0, sizeof(num));
 	memset(used_channels, 0, sizeof(used_channels));
 
@@ -1408,6 +1418,10 @@ int cfg80211_can_use_iftype_chan(struct cfg80211_registered_device *rdev,
 		if (radar_detect && !(c->radar_detect_widths & radar_detect))
 			goto cont;
 
+		if (radar_detect && c->radar_detect_regions &&
+		    !(c->radar_detect_regions & BIT(region)))
+			goto cont;
+
 		/*
 		 * Finally check that all iftypes that we're currently
 		 * using are actually part of this combination. If they
-- 
1.8.5.2 (Apple Git-48)

Re: [PATCH 3.15] cfg80211: allow restricting supported dfs regions

[Johannes Berg]

On Sat, 2014-05-03 at 22:55 +0200, Felix Fietkau wrote:
> At the moment, the ath9k/ath10k DFS module only supports detecting ETSI
> radar patterns.

It seems this should also be advertised to the userspace.

> Add a bitmap in the interface combinations, indicating which DFS regions
> are supported by the detector.

Does that make sense? It seems unlikely to me that it would be interface
combination specific?

I think it's already questionable to put this in after -rc4, in
particular with the userspace advertising part. Can we do anything
else? 

johannes

Re: [PATCH 3.15] cfg80211: allow restricting supported dfs regions

[Felix Fietkau]

On 2014-05-05 09:33, Johannes Berg wrote:
> On Sat, 2014-05-03 at 22:55 +0200, Felix Fietkau wrote:
>> At the moment, the ath9k/ath10k DFS module only supports detecting ETSI
>> radar patterns.
> 
> It seems this should also be advertised to the userspace.
Right.

>> Add a bitmap in the interface combinations, indicating which DFS regions
>> are supported by the detector.
> 
> Does that make sense? It seems unlikely to me that it would be interface
> combination specific?
Having it there made about as much sense to me as having the supportede
channel width there :)
Got any better suggestions?

> I think it's already questionable to put this in after -rc4, in
> particular with the userspace advertising part. Can we do anything
> else? 
I mostly pushed it for 3.15, because right now you can already enable
DFS and it will bring it up on a FCC regdomain and it will appear to be
working (but probably just not recognize any radars).

However, now that I look at the description of the options that you have
to enable, it should be clear enough that this is not guaranteed to be
functional yet, so I guess it can wait for 3.16.

- Felix

Re: [PATCH 3.15] cfg80211: allow restricting supported dfs regions

[Johannes Berg]

On Mon, 2014-05-05 at 11:20 +0200, Felix Fietkau wrote:

> >> Add a bitmap in the interface combinations, indicating which DFS regions
> >> are supported by the detector.
> > 
> > Does that make sense? It seems unlikely to me that it would be interface
> > combination specific?
> Having it there made about as much sense to me as having the supportede
> channel width there :)
> Got any better suggestions?

Not really, it does make sense to group them, though the only real
reason to do it there originally was to prohibit multi-channel usage
with radar detection, so that made sense ... I have no real problem
doing this here as well.

> > I think it's already questionable to put this in after -rc4, in
> > particular with the userspace advertising part. Can we do anything
> > else? 
> I mostly pushed it for 3.15, because right now you can already enable
> DFS and it will bring it up on a FCC regdomain and it will appear to be
> working (but probably just not recognize any radars).
> 
> However, now that I look at the description of the options that you have
> to enable, it should be clear enough that this is not guaranteed to be
> functional yet, so I guess it can wait for 3.16.

Ok.

johannes

Re: [PATCH 3.15] cfg80211: allow restricting supported dfs regions

[Janusz Dziedzic]

2014-05-05 11:20 GMT+02:00 Felix Fietkau <nbd@openwrt.org>:
> On 2014-05-05 09:33, Johannes Berg wrote:
>> On Sat, 2014-05-03 at 22:55 +0200, Felix Fietkau wrote:
>>> At the moment, the ath9k/ath10k DFS module only supports detecting ETSI
>>> radar patterns.
>>
>> It seems this should also be advertised to the userspace.
> Right.
>
>>> Add a bitmap in the interface combinations, indicating which DFS regions
>>> are supported by the detector.
>>
>> Does that make sense? It seems unlikely to me that it would be interface
>> combination specific?
> Having it there made about as much sense to me as having the supportede
> channel width there :)
> Got any better suggestions?
>
>> I think it's already questionable to put this in after -rc4, in
>> particular with the userspace advertising part. Can we do anything
>> else?
> I mostly pushed it for 3.15, because right now you can already enable
> DFS and it will bring it up on a FCC regdomain and it will appear to be
> working (but probably just not recognize any radars).
>
In case you will choose FCC/JP which is not supported yet, single
pulse will trigger
radar detected event.
In case of supported patterns (ETSI) many pulses are checked (pattern)
and next we decide if that is an
radar or not.
So, after you will choose FCC/JP even single (even false) pulse will
trigger radar detected event and next switch to new channel ...
In practice this mean FCC/JP DFS channels became unusable.

BR
Janusz