linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ben Greear <greearb@candelatech.com>
To: Janusz Dziedzic <janusz.dziedzic@tieto.com>
Cc: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: More confusion with regulatory issues.
Date: Wed, 11 Jun 2014 09:31:31 -0700	[thread overview]
Message-ID: <53988463.4040303@candelatech.com> (raw)
In-Reply-To: <53987A6A.7080209@candelatech.com>

On 06/11/2014 08:48 AM, Ben Greear wrote:
> On 06/11/2014 07:31 AM, Ben Greear wrote:
>> On 06/11/2014 03:34 AM, Janusz Dziedzic wrote:
>>
>>> This could be the same issue like fixed in:
>>> cfg80211: reg: setup correct alpha2 after intersection (Ben could you
>>> try with this patch?)
>>>
>>> Orginal scenario I descibe:
>>> - insmod cfg80211.ko
>>> - iw reg set FR (1)
>>> - modprobe ath10k_pci (US hint)
>>> - intersection and country set as "98"
>>> - no way to setup new country using iw reg set   (here hostapd startup
>>> will failed)
>>>
>>> But I can imagine also that we have two cards, both using cfg80211.ko
>>> So, first card driver loaded set regulatory eg. FR
>>> Next we load ath10k --> intersection "98"
>>> Next run hostapd - and fail because no way to change regulatory and
>>> get correct DFS region
>>>
>>> BTW:
>>> There is no problem (no intersection) when move "iw reg set" after
>>> modprobe ath10k - seems strange logic issue here ...
>>
>> With your patch, I no longer see the '98' regdomain, but
>> I still see DFS-UNSET.  Is that expected?  How do I get DFS
>> to work (and, should it actually be enabled in this case?)
>>
>> [root@ath10k-2220 ~]# iw reg get
>> country US: DFS-UNSET
>> 	(2402 - 2472 @ 40), (N/A, 30)
>> 	(5170 - 5250 @ 80), (N/A, 17)
>> 	(5250 - 5330 @ 80), (N/A, 23), DFS
>> 	(5735 - 5835 @ 80), (N/A, 30)
>> 	(57240 - 63720 @ 2160), (N/A, 40)
>> [root@ath10k-2220 ~]#
> 
> After more debugging, I noticed this:
> 
> We are getting regulatory update from core, intersecting US with world-regulatory
> domain.  But, the dfs region is un-specified for both of these.  I was expecting
> the US domain to use the FCC dfs region.
> 
> [    7.895189] cfg80211: 5715000 KHz - 5860000 KHz @ 80000 KHz), (N/A mBi, 3000 mBm)
> [    7.895190] cfg80211: Updating information on frequency 5825 MHz with regulatory rule:
> [    7.895191] cfg80211: 5715000 KHz - 5860000 KHz @ 80000 KHz), (N/A mBi, 3000 mBm)
> [    7.895260] cfg80211: Ignoring regulatory request set by core since the driver uses its own custom regulatory domain
> [    7.895929] cfg80211: Calling CRDA for country: US
> [    7.895942] cfg80211: Calling CRDA for country: US
> [    7.901380] cfg80211: set-regdom, lr->initiator: 2 domain: US
> [    7.907423] cfg80211: regdom-intersect, rd1: ffff880220ea5000  rd2: ffff8800371aa700
> [    7.915047] cfg80211: regdom-intersect, rd1: US  rd2: 00
> ....
> [    8.220870] cfg80211: reg-rules-intersect, US  00
> [    8.224454] cfg80211: reg-rules-intersect, US  00
> [    8.227943] cfg80211: dfs-region, region1: 0  region2: 0
> 
> And a bit related, I was thinking the dfs-region intersection might
> be more useful as is written below?
> 
> static enum nl80211_dfs_regions
> reg_intersect_dfs_region(const enum nl80211_dfs_regions dfs_region1,
> 			 const enum nl80211_dfs_regions dfs_region2)
> {
> 	pr_err("dfs-region, region1: %d  region2: %d\n",
> 	       dfs_region1, dfs_region2);
> 	if (dfs_region1 != dfs_region2) {
> 		if (dfs_region1 == NL80211_DFS_UNSET)
> 			return dfs_region2;
> 		if (dfs_region2 == NL80211_DFS_UNSET)
> 			return dfs_region1;
> 		return NL80211_DFS_UNSET;
> 	}
> 	return dfs_region1;
> }

Well, maybe making some progress now.

I notice that if I do a 'make;make install' for the wireless-regdb, then
crda tools say the regulatory.bin is invalid.  I do not know why this
is the case, but if I skip the 'make' and just do a 'make install',
then regdbdump appears happy.

I think the patch to dfs_region intersection above is still needed,
and with it in, I now get this after bootup:


[root@ath10k-2220 ~]# iw reg get
country 98: DFS-FCC
	(2402 - 2472 @ 70), (N/A, 20)
	(2457 - 2472 @ 70), (N/A, 20), PASSIVE-SCAN, NO-IBSS
	(5170 - 5250 @ 80), (N/A, 17), PASSIVE-SCAN, NO-IBSS
	(5250 - 5330 @ 80), (N/A, 20), DFS, PASSIVE-SCAN, NO-IBSS
	(5735 - 5835 @ 80), (N/A, 20), PASSIVE-SCAN, NO-IBSS
	(57240 - 63720 @ 2160), (N/A, 0)
[root@ath10k-2220 ~]#

Does this look proper for a US region?

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


  reply	other threads:[~2014-06-11 16:31 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-11  0:11 More confusion with regulatory issues Ben Greear
2014-06-11  9:10 ` Luis R. Rodriguez
2014-06-11 10:34   ` Janusz Dziedzic
2014-06-11 14:31     ` Ben Greear
2014-06-11 15:48       ` Ben Greear
2014-06-11 16:31         ` Ben Greear [this message]
2014-06-11 19:24           ` Janusz Dziedzic
2014-06-23 19:33             ` Luis R. Rodriguez
2014-06-11 14:15   ` Ben Greear

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53988463.4040303@candelatech.com \
    --to=greearb@candelatech.com \
    --cc=janusz.dziedzic@tieto.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=mcgrof@do-not-panic.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).