[PATCH] regulatory: don't rule out some valid rules

[PATCH] regulatory: don't rule out some valid rules

[Eliad Peller]

commit 6d87df6 ("regdb: allow 40 MHz on world roaming
channels 12/13") in wireless-regdb did the following
change:

-        # Channel 12 - 13. No HT40 channel fits here
-        (2457 - 2482 @ 20), (3, 20), PASSIVE-SCAN, NO-IBSS
+        # Channel 12 - 13.
+        (2457 - 2482 @ 40), (3, 20), PASSIVE-SCAN, NO-IBSS

in order to allow HT40+ on lower channels (such as 9).

However, the current regulatory rules verification forbids
such rules, as 2482 - 2457 < 40.
Remove this requirement from the rules verification function.

Signed-off-by: Eliad Peller <eliad@wizery.com>
---
 net/wireless/reg.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 6c4b507..c8a5c34 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -610,8 +610,7 @@ static bool is_valid_reg_rule(const struct ieee80211_reg_rule *rule)
 
 	freq_diff = freq_range->end_freq_khz - freq_range->start_freq_khz;
 
-	if (freq_range->end_freq_khz <= freq_range->start_freq_khz ||
-	    freq_range->max_bandwidth_khz > freq_diff)
+	if (freq_range->end_freq_khz <= freq_range->start_freq_khz)
 		return false;
 
 	return true;
-- 
1.8.5.2.229.g4448466.dirty

Re: [PATCH] regulatory: don't rule out some valid rules

[Johannes Berg]

On Sun, 2014-04-13 at 16:15 +0300, Eliad Peller wrote:
> commit 6d87df6 ("regdb: allow 40 MHz on world roaming
> channels 12/13") in wireless-regdb did the following
> change:
> 
> -        # Channel 12 - 13. No HT40 channel fits here
> -        (2457 - 2482 @ 20), (3, 20), PASSIVE-SCAN, NO-IBSS
> +        # Channel 12 - 13.
> +        (2457 - 2482 @ 40), (3, 20), PASSIVE-SCAN, NO-IBSS
> 
> in order to allow HT40+ on lower channels (such as 9).
> 
> However, the current regulatory rules verification forbids
> such rules, as 2482 - 2457 < 40.

For better or worse, this is how the rules verification was defined. I
don't like this definition either and think the whole "max bandwidth"
thing was done badly in the original implementation, but this is
userspace API.

To bust this limit would mean to change the rule interpretation quite
significantly, I don't think we can do that without more analysis on why
it's safe or won't matter for the regdb.

However, we have the NL80211_RRF_AUTO_BW flag now, which presumably
could also be somehow set for the rule here to solve this issue?

johannes