* [PATCH 50/53] wireless-regdb: enable VHT80 when world roaming
From: Luis R. Rodriguez @ 2013-07-17 2:18 UTC (permalink / raw)
To: linville; +Cc: wireless-regdb, linux-wireless, Luis R. Rodriguez
In-Reply-To: <1374027522-18488-1-git-send-email-mcgrof@do-not-panic.com>
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
For VHT, the wider bandwidths (up to 160 MHz) need
to be allowed. Since world roaming only covers the
case of connecting to an AP, it can be opened up
there, we will rely on the AP to know the local
regulations.
Based on a patch by Johannes Berg for upstream Linux.
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
---
db.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/db.txt b/db.txt
index 0a4b56f..c6def1c 100644
--- a/db.txt
+++ b/db.txt
@@ -6,10 +6,10 @@ country 00:
# Channel 14. Only JP enables this and for 802.11b only
(2474 - 2494 @ 20), (3, 20), PASSIVE-SCAN, NO-IBSS, NO-OFDM
# Channel 36 - 48
- (5170 - 5250 @ 40), (3, 20), PASSIVE-SCAN, NO-IBSS
+ (5170 - 5250 @ 80), (3, 20), PASSIVE-SCAN, NO-IBSS
# NB: 5260 MHz - 5700 MHz requies DFS
# Channel 149 - 165
- (5735 - 5835 @ 40), (3, 20), PASSIVE-SCAN, NO-IBSS
+ (5735 - 5835 @ 80), (3, 20), PASSIVE-SCAN, NO-IBSS
country AD:
--
1.7.10.4
^ permalink raw reply related
* [PATCH 51/53] wireless-regdb: add 802.11ad 60 GHz channels 1..3 to world regdom
From: Luis R. Rodriguez @ 2013-07-17 2:18 UTC (permalink / raw)
To: linville; +Cc: wireless-regdb, linux-wireless, Luis R. Rodriguez
In-Reply-To: <1374027522-18488-1-git-send-email-mcgrof@do-not-panic.com>
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
This is a port of what Vladimir Kondratiev sent to the
Linux kernel for the static world regulatory domain.
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
---
db.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/db.txt b/db.txt
index c6def1c..54f89d3 100644
--- a/db.txt
+++ b/db.txt
@@ -10,6 +10,8 @@ country 00:
# NB: 5260 MHz - 5700 MHz requies DFS
# Channel 149 - 165
(5735 - 5835 @ 80), (3, 20), PASSIVE-SCAN, NO-IBSS
+ # IEEE 802.11ad (60GHz), channels 1..3
+ (57240 - 63720 @ 2160), (N/A, 0)
country AD:
--
1.7.10.4
^ permalink raw reply related
* [PATCH 52/53] wireless-regdb: CR, Costa Rica - enable VHT80
From: Luis R. Rodriguez @ 2013-07-17 2:18 UTC (permalink / raw)
To: linville; +Cc: wireless-regdb, linux-wireless, Luis R. Rodriguez
In-Reply-To: <1374027522-18488-1-git-send-email-mcgrof@do-not-panic.com>
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
This enables 80 MHz bandwidth usage for Costa Rica,
updates the max EIRP and adds a new 5 GHz band:
* 5490 - 5710
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
---
db.txt | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/db.txt b/db.txt
index 54f89d3..1470772 100644
--- a/db.txt
+++ b/db.txt
@@ -182,9 +182,10 @@ country CO:
country CR:
(2402 - 2482 @ 40), (N/A, 20)
- (5170 - 5250 @ 20), (3, 17)
- (5250 - 5330 @ 20), (3, 23), DFS
- (5735 - 5835 @ 20), (3, 30)
+ (5170 - 5250 @ 80), (3, 17)
+ (5250 - 5330 @ 80), (3, 24), DFS
+ (5490 - 5710 @ 80), (3, 24), DFS
+ (5735 - 5835 @ 80), (3, 30)
country CS:
(2402 - 2482 @ 40), (N/A, 20)
--
1.7.10.4
^ permalink raw reply related
* [PATCH 53/53] wireless-regdb: EC, Ecauador - enable VHT80
From: Luis R. Rodriguez @ 2013-07-17 2:18 UTC (permalink / raw)
To: linville; +Cc: wireless-regdb, linux-wireless, Luis R. Rodriguez
In-Reply-To: <1374027522-18488-1-git-send-email-mcgrof@do-not-panic.com>
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
This enables 80 MHz bandwidth usage for Ecuador,
updates the max EIRP and adds a new 5 GHz band:
* 5490 - 5710
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
---
db.txt | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/db.txt b/db.txt
index 1470772..811eb5c 100644
--- a/db.txt
+++ b/db.txt
@@ -256,9 +256,10 @@ country DZ:
country EC:
(2402 - 2482 @ 40), (N/A, 20)
- (5170 - 5250 @ 20), (3, 17)
- (5250 - 5330 @ 20), (3, 23), DFS
- (5735 - 5835 @ 20), (3, 30)
+ (5170 - 5250 @ 80), (3, 17)
+ (5250 - 5330 @ 80), (3, 24), DFS
+ (5490 - 5710 @ 80), (3, 24), DFS
+ (5735 - 5835 @ 80), (3, 30)
country EE: DFS-ETSI
(2402 - 2482 @ 40), (N/A, 20)
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH 0/2] beacon measurement (beacon filtering disable)
From: Kalle Valo @ 2013-07-17 4:10 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1373971517-315-1-git-send-email-johannes@sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> writes:
> We have beacon filtering (to reduce host wakeups) in our device,
> but for some measurement/debug purposes we need to turn it off.
TBH I'm not really fond of this. I'm not really sure what's the use
case but first this sounded a like a factory test for me, not something
which a regular user would want to do.
Can't we connect this to power save? When disabling power save we could
also disable beacon filtering and would not need a separate command.
--
Kalle Valo
^ permalink raw reply
* Re: Power saving features for iwl4965
From: Pedro Francisco @ 2013-07-17 11:48 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: Tino Keitel, ML linux-wireless
In-Reply-To: <20130716102743.GA8321@redhat.com>
On Tue, Jul 16, 2013 at 11:27 AM, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
>> I seem only to be able to trigger it with disable_hw_scan=0, I need
>> further testing with disable_hw_scan=1 (I use disable_hw_scan=0
>> because it prevents me from getting disconnected from eduroam Cisco
>> APs -- haven't tested disable_hw_scan=0 since the VOIP-friendly SW
>> scanning patch, however).
>>
>> Do you want the log anyway? (modprobe iwl3945 debug=0x47ffffff
>> disable_hw_scan=0 and runtime PCI powersave also enabled -- I don't
>> know if it matters).
>
> As this is not causing troubles with default disable_hw_scan option,
> I'll post that patch.
My mistake, I can trigger error conditions _independently_ of
disable_hw_scan option being enabled or disabled, as long as powersave
is enabled.
I'll send you a private email with the logs.
^ permalink raw reply
* Re: [BUG] 3.10 regression: hang on suspend
From: Stanislaw Gruszka @ 2013-07-17 12:29 UTC (permalink / raw)
To: Ortwin Glück; +Cc: Arend van Spriel, linux-kernel, linux-wireless
In-Reply-To: <51E58FA5.4000804@odi.ch>
On Tue, Jul 16, 2013 at 08:23:33PM +0200, Ortwin Glück wrote:
> Without NetworkManager, no X, on console and with plain jane wpa_supplicant I do
> echo mem > /sys/power state
>
> After that, it still responds to keyboard events: I can switch VT
> and type on the consoles, but I can not login on a different VT
> (pressing Enter after the username doesn't return). So I guess tasks
> have been frozen, but it hangs in stopping devices.
>
> settings for pm_test:
> devices: same behviour as above
> freezer: works as expected (stops tasks; sleeps; resumes tasks)
>
> Nothing in the logs. How can I enable more log?
This looks like livelock, i.e. kernel wait for mutex to be released
but that never happen , for example because of deadlock. Enabling
CONFIG_LOCKDEP=y could help to diagnose this. Other than that
sysreq key w (show blocked task) could help, see
Documentation/sysrq.txt for instructions how to use this key.
Also please remember set no_console_suspend boot option to
allow print messages on tty during suspend.
Stanislaw
^ permalink raw reply
* hung task while plugging in cfg80211
From: Jeff Layton @ 2013-07-17 13:47 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, linux-kernel
(Resending with wider distribution list since my earlier email to
linux-wireless didn't get a response)
I updated the kernel on my fedora rawhide KVM guest, and noticed that
the ethernet interface wasn't coming up at all. While poking around, I
saw this stack trace pop up:
Jul 12 07:29:25 rawhide kernel: [ 241.156196] INFO: task modprobe:501 blocked for more than 120 seconds.
Jul 12 07:29:25 rawhide kernel: [ 241.157222] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jul 12 07:29:25 rawhide kernel: [ 241.158379] modprobe D ffff880118c526e0 4584 501 500 0x00000080
Jul 12 07:29:25 rawhide kernel: [ 241.159458] ffff8800d10c3ba8 0000000000000046 00000000001d5300 ffff8800d10c3fd8
Jul 12 07:29:25 rawhide kernel: [ 241.160644] ffff8800d10c3fd8 00000000001d5300 ffff8800d2ae4dc0 ffff8800d2ae4dc0
Jul 12 07:29:25 rawhide kernel: [ 241.161875] ffffffff81d0bfa0 ffffffff81d0bfa8 ffffffff00000000 ffffffff81d0bff0
Jul 12 07:29:25 rawhide kernel: [ 241.163096] Call Trace:
Jul 12 07:29:25 rawhide kernel: [ 241.163460] [<ffffffff817377e9>] schedule+0x29/0x70
Jul 12 07:29:25 rawhide kernel: [ 241.164235] [<ffffffff817392ad>] rwsem_down_write_failed+0xed/0x1a0
Jul 12 07:29:25 rawhide kernel: [ 241.165489] [<ffffffff810bb600>] ? update_cpu_load_active+0xb0/0xb0
Jul 12 07:29:25 rawhide kernel: [ 241.166267] [<ffffffff8137d503>] call_rwsem_down_write_failed+0x13/0x20
Jul 12 07:29:25 rawhide kernel: [ 241.166760] [<ffffffff81736aad>] ? down_write+0x9d/0xb2
Jul 12 07:29:25 rawhide kernel: [ 241.167189] [<ffffffff8162d975>] ? genl_lock_all+0x15/0x30
Jul 12 07:29:25 rawhide kernel: [ 241.167603] [<ffffffff8162d975>] genl_lock_all+0x15/0x30
Jul 12 07:29:25 rawhide kernel: [ 241.168036] [<ffffffff8162ea83>] genl_register_family+0x53/0x1f0
Jul 12 07:29:25 rawhide kernel: [ 241.168490] [<ffffffffa015e000>] ? 0xffffffffa015dfff
Jul 12 07:29:25 rawhide kernel: [ 241.168877] [<ffffffff8162f520>] genl_register_family_with_ops+0x20/0x80
Jul 12 07:29:25 rawhide kernel: [ 241.169406] [<ffffffffa015e000>] ? 0xffffffffa015dfff
Jul 12 07:29:25 rawhide kernel: [ 241.169802] [<ffffffffa0101ec4>] nl80211_init+0x24/0xf0 [cfg80211]
Jul 12 07:29:25 rawhide kernel: [ 241.170297] [<ffffffffa015e000>] ? 0xffffffffa015dfff
Jul 12 07:29:25 rawhide kernel: [ 241.170686] [<ffffffffa015e043>] cfg80211_init+0x43/0xdb [cfg80211]
Jul 12 07:29:25 rawhide kernel: [ 241.171230] [<ffffffff810020fa>] do_one_initcall+0xfa/0x1b0
Jul 12 07:29:25 rawhide kernel: [ 241.171651] [<ffffffff8105cb93>] ? set_memory_nx+0x43/0x50
Jul 12 07:29:25 rawhide kernel: [ 241.172099] [<ffffffff810fa2bf>] load_module+0x1c6f/0x27f0
Jul 12 07:29:25 rawhide kernel: [ 241.172515] [<ffffffff810f59a0>] ? store_uevent+0x40/0x40
Jul 12 07:29:25 rawhide kernel: [ 241.172933] [<ffffffff810fafd6>] SyS_finit_module+0x86/0xb0
Jul 12 07:29:25 rawhide kernel: [ 241.173379] [<ffffffff81744019>] system_call_fastpath+0x16/0x1b
...on a hunch, I blacklisted the cfg80211 module, and that seems to
have worked around the problem for now. I suspect that NM was trying to
plug in this module and it hung, and it couldn't proceed any further to
configure the virtual ethernet interface.
In the fedora rawhide kernels, last known good one is
kernel-3.11.0-0.rc0.git3.1.fc20, and bad one is
kernel-3.11.0-0.rc0.git6.1.fc20. I haven't bisected it further.
--
Jeff Layton <jlayton@redhat.com>
^ permalink raw reply
* authsae & ath9k nohwcrypt=1
From: etienne.champetier @ 2013-07-17 16:47 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <242956217.344802091.1374060921158.JavaMail.root@zimbra65-e11.priv.proxad.net>
Hi
I'm making some test with authsae on openrwt and for wr1043nd router (AR9100 wireless) i still need 'ath9k nohwcrypt=1'
for the secure mesh to work when on another router (AR9280 wireless) i don't need it.
Is it a drivers bug? or is it hardware?
-Router A: wr1043nd (need nohwcrypt=1 option)
-AR9100 wireless
-authsae - 2013-06-25-e2f67612101dc83f2c459d8ddc75c34bc83e1e83 (https://github.com/cozybit/authsae/tree/e2f67612101dc83f2c459d8ddc75c34bc83e1e83)
-kmod-ath9k - 3.10.1+2013-06-27-1 (backports-20130617-4-ge3220f5)
-openwrt BB r37364
-Router B: ubnt rspro
-AR9280 wireless
-openwrt BB r37369 (same authsae/ath9k)
Thanks in advance
Etienne
^ permalink raw reply
* So, which IEEE<->Frequency mappings should we be all using?
From: Adrian Chadd @ 2013-07-17 17:42 UTC (permalink / raw)
To: freebsd-wireless, linux-wireless
Hi all,
I've been increasingly asked to bring up FreeBSD on "other" bands.
* 420MHz
* 700MHz
* 900MHz (which we already have, due to history);
* 3.6GHz
* 4.9GHz
I'd also like to support half and quarter width channels on these
frequencies. If I use the 2GHz channel mapping method, I end up with a
very restricted channel set and it definitely has no "gaps" for
5/10MHz increments.
Now, what I'd like to do is figure out some sane, shared method of
translating channel frequencies to IEEE numbers and back. That way the
BSDs and Linux (and maybe commercial stacks; I dunno what they do) can
have some sane chance of interoperating.
So: Is there some standardised or semi-standardised channel mapping
method? Or should we invent one?
-adrian
^ permalink raw reply
* Wake-On-Wireless and Deauthentication
From: greg.huber @ 2013-07-17 18:11 UTC (permalink / raw)
To: linux-wireless
I'm trying to get Wake-on-wireless working with an Atheros AR9462.
The problem I seem to be having is that there is a Deauth requested
when the system is suspended. Does anyone know how to keep the
association while suspended?? I'm using kernel 3.9.9.
The log after waking (from keyboard)
[ 320.117062] wlp3s0: deauthenticating from 00:24:01:12:de:7a by local choice
(reason=3)
[ 320.125719] cfg80211: Calling CRDA to update world regulatory domain
[ 320.186243] cfg80211: World regulatory domain updated:
[ 320.186255] cfg80211: (start_freq - end_freq @ bandwidth),
(max_antenna_gain, max_eirp)
[ 320.186259] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi,
2000 mBm)
[ 320.186263] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (300 mBi,
2000 mBm)
[ 320.186266] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi,
2000 mBm)
[ 320.186270] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi,
2000 mBm)
[ 320.186273] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi,
2000 mBm)
[ 320.626022] PM: Syncing filesystems ... done.
[ 320.632331] PM: Preparing system for mem sleep
[ 320.633223] Freezing user space processes ... (elapsed 0.01 seconds) done.
[ 320.644617] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
[ 320.655788] PM: Entering mem sleep
[ 320.655917] Suspending console(s) (use no_console_suspend to debug)
[ 320.656856] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 320.657069] serial 00:09: disabled
[ 320.657086] serial 00:09: System wakeup disabled by ACPI
[ 320.679813] sd 0:0:0:0: [sda] Stopping disk
[ 320.681171] <6>[fglrx] IRQ 48 Disabled
[ 320.681217] <6>[fglrx] Preparing suspend fglrx in kernel.
[ 320.927890] <6>[fglrx] Suspending fglrx in kernel completed.
[ 320.927893] <6>[fglrx] Power down the ASIC .
[ 321.168217] PM: suspend of devices complete after 511.732 msecs
[ 321.168512] PM: late suspend of devices complete after 0.289 msecs
Thanks for any insight you could provide.
Greg
^ permalink raw reply
* RE: [PATCH 1/3] [RFC] cfg80211: Add indoor only and GO concurrent channel attributes
From: Peer, Ilan @ 2013-07-17 18:47 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: wireless-regdb@lists.infradead.org, linux-wireless,
Spinadel, David, Ginsburg, Noam, Perelmooter, Liraz, Shalev, Oz,
Michael Green
In-Reply-To: <CAB=NE6WBz36HktdvOd_Ay=xrx0LJQd=9MxxTrTFKhALS+HMHzg@mail.gmail.com>
SGkgTHVpcywNCg0KT25jZSBhZ2FpbiwgdGhhbmtzIGZvciB0aGUgY29tbWVudHMgOikNCg0KUmVn
YXJkcywNCg0KSWxhbi4NCg0KPiA+PiBJcyBXRkQgV2lGaSBEaXNwbGF5PyBJcyB0aGVyZSBhbnkg
c3RyaWN0IHJlbGF0aW9uc2hpcCBoZXJlIHRvIFdGRCBhbmQNCj4gPj4gR08gYW5kIHJlZ3VsYXRv
cnkgb3IgaXMgV0ZEIGp1c3QgYSB1c2UgY2FzZSBleGFtcGxlPyBBcmUgeW91DQo+ID4+IGluZGlj
YXRpbmcgdGhhdCB0aGUgRkNDIGlzIG1ha2luZyBzcGVjaWFsIHJ1bGVzIGZvciBjYXNlcyBpbiBz
cGVjaWZpYw0KPiA+PiBiYW5kcyB3aGVyZSBHTyAqY2FuKiBjby1leGlzdCB3aXRoIG90aGVyIEdP
IGRldmljZXMgPw0KPiA+DQo+ID4gV0ZEIGlzIFdpRmkgZGlyZWN0IGluIHRoaXMgY29udGV4dC4g
SSBkbyBub3QgdGhpbmsgdGhhdCB0aGUgRkNDIGFyZSBtYWtpbmcNCj4gc3BlY2lhbCBydWxlcyBv
bmx5IGZvciBHTyBzcGVjaWZpYyBzY2VuYXJpb3MgYnV0IGEgbW9yZSBnZW5lcmFsIGFwcHJvYWNo
IHdoZXJlDQo+ICJjb21wbGlhbmNlIG1heSBiZSBhY2hpZXZlZCB1bmRlciB0aGUgZ3VpZGFuY2Ug
b2YgYW4gYXV0aG9yaXplZCBtYXN0ZXIiLg0KPiBUaGUgV0ZEL1AyUCBHTyBjYXNlIGlzIG9ubHkg
YW4gZXhhbXBsZS4NCj4gDQo+IE9LIHRoZW4gSSB0aGluayBjdWxsdWxhciBiYXNlIHN0YXRpb24g
cmVndWxhdG9yeSBoaW50cyBtaWdodCBiZSBhbm90aGVyIGV4YW1wbGUuDQo+IEluIGZhY3QgSSBi
ZWxpZXZlIEkgYW0gbG9va2luZyBhdCB0aGUgaW5mb3JtYXRpb24geW91IG1pZ2h0IGJlIHVzaW5n
IGFzDQo+IHJlZmVyZW5jZS4gSSBhbSBsb29raW5nIGF0IHB1YmxpYyBkcmFmdCBlZGl0IGZvciBG
Q0MgS0RCIDU5NDI4MDoNCj4gDQo+IGh0dHBzOi8vYXBwcy5mY2MuZ292L2Vhcy9jb21tZW50cy9H
ZXRQdWJsaXNoZWREb2N1bWVudC5odG1sP2lkPTMyNyZ0bj01DQo+IDI4MTIyDQoNClRoaXMgaXMg
aW5kZWVkIHRoZSByZWxldmFudCBkb2N1bWVudC4NCg0KPiANCj4gVGhlIG9yaWdpbmFsIEtEQjoN
Cj4gDQo+IGh0dHA6Ly90cmFuc2l0aW9uLmZjYy5nb3Yvb2V0L2VhL3ByZXNlbnRhdGlvbnMvZmls
ZXMvYXByMTEvM2IuU29mdHdhcmVDb25maWd1cg0KPiBhdGlvbkNvbnRyb2wtUkRKUy5wZGYNCj4g
DQo+IFNwZWNpZmljYWxseSBpbiB0aGUgYWJvdmUgZG9jdW1lbnQsIHRoZSBkcmFmdCBlZGl0LCBJ
IGFtIGxvb2tpbmcgYXQgcGFnZSAxMi4gVGhhdA0KPiBhY3R1YWxseSByZWZlcmVuY2VzIFdpRmkg
RGlyZWN0IHByZWNpc2VseSBhbmQgY29uc2lkZXJzIHRoZSBjYXNlIHRoYXQgYSBHTyBtYXkNCj4g
bmVlZCB0byBtb3ZlIG91dCBvZiBpdHMgY2hhbm5lbCBpZiBpdHMgbWFzdGVyIGRldmljZSBpdHMg
dXNpbmcgdG8gY29uZmlndXJlIGl0c2VsZg0KPiBhbHNvIHN3aXRjaGVzIGNoYW5uZWxzLiBHaXZl
biB0aGF0IGNlbGx1bGFyIGJhc2Ugc3RhdGlvbiBoaW50cyBjb3VsZCBhbHNvDQo+IHRlY2huaWNh
bGx5IGJlIHVzZWQgdGhpcyBhbHNvIHdvdWxkIG5lZWQgdG8gYmUgY29uc2lkZXJlZCBmb3IgY2Vs
bHVsYXIgYmFzZQ0KPiBzdGF0aW9ucy4gQnV0IGFsc28gbm90ZSBvbiBwYWdlIDE0IGl0IHN0YXRl
cyBjbGVhcmx5Og0KPiANCj4gIk1vYmlsZSBDb3VudHJ5IENvZGVzIChNQ0MpIG9yIE1vYmlsZSBO
ZXR3b3JrIENvZGVzDQo+IChNTkMpIGFyZSBub3QgYWNjZXB0YWJsZSBmb3IgcHJvZ3JhbW1pbmcg
aG9zdCBjb21wbGlhbmNlIg0KPiANCj4gU28gaXQgc2VlbXMgY2VsbHVsYXIgYmFzZSBzdGF0aW9u
IGhpbnRzIGFyZSBzaW1wbHkgbm90IGFsbG93ZWQgYnkgdGhlIEZDQyAodW5sZXNzDQo+IHNwZWNp
ZmljIGFwcHJvdmFsIGlzIHJlcXVlc3RlZCAvIHJldmlzZWQpLiBFdmVuIGlmIHRoZSBGQ0MgYWxs
b3dlZCBmb3IgaXQgSSBiZWxpZXZlDQo+IGFuIEFQSSB3b3VsZCBuZWVkIHRvIGJlIHByb3ZpZGVk
IHNob3VsZCBjZWxsdWxhciBiYXNlIHN0YXRpb25zIGhhdmUgYSBjYXNlDQo+IHdoZXJlIHRoZXkg
bWF5IHN0b3Agb3BlcmF0aW5nIGFzIHdlbGwgc2ltaWxhciB0byBERlMuDQo+IA0KPiBCVFcgaW4g
ZnV0dXJlIGl0ZXJhdGlvbnMgb2YgcGF0Y2hlcyBJJ2QgYXBwcmVjaWF0ZSBpZiB5b3UgY2FuIGlu
Y2x1ZGUgdGhlIGFib3ZlDQo+IHJlZmVyZW5jZXMgdG8gZG9jdW1lbnRhdGlvbiBnaXZlbiB0aGF0
IHdlJ3ZlIHB1bGxlZCB0aGVtIHVwIG5vdy4NCj4gDQoNClN1cmUuDQoNCj4gPj4gWW91IGFubm90
YXRlIHRoYXQgdGhpcyBpcyBzb21laG93IHJlbGF0ZWQgdG8gREZTLCBhcmUgdGhlIEdPDQo+ID4+
IGNvbmN1cnJlbnQgcnVsZXMgdGhhdCB0aGUgRkNDIGlzIGRlZmluaW5nIG9ubHkgYXBwbGljYWJs
ZSB0byBERlMNCj4gPj4gZnJlcXVlbmN5IHJhbmdlcz8gSWYgc28gd291bGQgaXQgc3VmZmljZSB0
byBvbmx5IHVzZSBERlMgZmxhZyA/IE9yDQo+ID4+IGFyZSB0aGVyZSBvdGhlciBzcGVjaWFsIGNh
c2VzIGJleW9uZCBERlMgZnJlcXVlbmN5IHJhbmdlcyB0aGF0IHRoZSBGQ0MgaXMNCj4gY3JlYXRp
bmcgc3BlY2lhbCBoYW5kbGluZz8NCj4gPj4NCj4gPg0KPiA+IERGUyB3YXMgZ2l2ZW4gaGVyZSBh
cyBhbiBleGFtcGxlLiBHZW5lcmFsbHksIEkgdGhpbmsgdGhhdCB0aGUgY2hhbmdlcyB0aGF0DQo+
IHRoZSBGQ0MgYXJlIG1ha2luZyBhcmUgdGFyZ2V0aW5nIHZhcmlvdXMgc2NlbmFyaW9zIGFuZCB2
YXJpb3VzIFJGIGRldmljZXMgKGZvcg0KPiBleGFtcGxlIHRob3NlIGRlZmluZWQgaW4gcGFydCAx
NSBvZiBDRlIgdGl0bGUgNDcpLg0KPiANCj4gT0sgdGhhbmtzLiBUaGluZ3MgYXJlIGNsZWFyIG5v
dyB0aGF0IEkgc2VlIHRoZSBkb2N1bWVudCB0aGF0IHlvdSBtaWdodCBiZQ0KPiByZWZlcnJpbmcg
dG8uDQo+IA0KPiA+PiBBcGFydCBmcm9tIHRoZSBGQ0MgYXJlIHlvdSBhd2FyZSBvZiBzcGVjaWFs
IGNhc2VzIGhhbmRsaW5nIGZvciBvdGhlcg0KPiA+PiByZWd1bGF0b3J5IGJvZGllcyBhdCB0aGlz
IHBvaW50Pw0KPiA+DQo+ID4gTm90IHRoYXQgSSdtIGF3YXJlIG9mLiBBZGRpbmcgc29tZSBtb3Jl
IHBlb3BsZSB0aGF0IG1pZ2h0IGtub3cgbW9yZS4NCj4gDQo+IEhleSBmb2xrcywgYW55b25lPyA6
KQ0KPiANCg0KPiA+DQo+ID4gQWN0dWFsbHksIHRoaXMgc2hvdWxkIGJlIGEgR08gb25seSBmbGFn
LCBtZWFuaW5nIHRoYXQgc3VjaCByZWxheGF0aW9uDQo+ID4gc2hvdWxkIG5vdCBiZSB2YWxpZCBm
b3Igc29mdCBBUCwgSUJTUyBvciBtZXNoLiBUaGUgaW50ZW50aW9uIGhlcmUgaXMNCj4gPiBsaW1p
dCB0aGUgZXh0ZW5kIG9mIHRoZSBjZWxsLCBhbmQgcHJldmVudCBkYWlzeSBjaGFpbiBzY2VuYXJp
b3MNCj4gPiAoYXNzdW1lIHRoYXQgeW91IGFsbG93IGEgc29mdCBBUCBvbiBzdWNoIGEgY2hhbm5l
bCBhbmQgdGhhdCBhIGNsaWVudA0KPiA+IGFzc29jaWF0ZWQgdG8gaXQsIGFuZCB0aGVuIHRoYXQg
ZGV2aWNlIGNhbiBhbHNvIHN0YXJ0IGEgc29mdCBBUCBvbiB0aGUNCj4gPiBjaGFubmVsIC4uLi4p
LiBBbnl3YXksIEknbGwgbmVlZCB0byBoYXZlIGFub3RoZXIgbG9vayBhdCB0aGlzIChtaWdodA0K
PiA+IGJlIHBlcm1pc3NpYmxlIGZvciBJQlNTIC4uLikNCj4gDQo+IEJhc2VkIG9uIHRoZSBkb2N1
bWVudGF0aW9uIEkgcmV2aWV3ZWQgYW5kIHlvdXIgcHJvcG9zYWwgaXQnZCBzZWVtIHRvIG1lIHRo
YXQNCj4gd2UgY2FuIGRpc3Rpbmd1aXNoIEdPIG9uIHRoZSB1cHBlciBsYXllcnMgYW5kIGRldGVy
bWluZSBpZiBhIGNoYW5uZWwgaXMgREZTIG9yDQo+IG5vdCBieSBqdXN0IHRoZSBERlMgZmxhZy4g
VGhlIG5leHQgaGludCB5b3UnZCBuZWVkIGlzIGlmIHRoZSBHTyBnb3QgcmVndWxhdG9yeQ0KPiBp
bmZvcm1hdGlvbiBmcm9tIGEgbWFzdGVyIHNvbWVob3csIG5vPw0KDQpUaGlzIHNob3VsZCBhbHNv
IGJlIGhhbmRsZWQgYnkgdXNlciBzcGFjZSwgYmFzZWQgb24gdGhlIGRldmljZSB0eXBlL3N1YiB0
eXBlIG9mIHRoZSBsb2NhbCBkZXZpY2UgZGlyZWN0bHksIG9yIGluZGlyZWN0bHkgdGhyb3VnaCBv
dGhlciBtZWFucyBzdWNoIGEgbWFuYWdlZCBpbnRlcmZhY2UgYXNzb2NpYXRpbmcgd2l0aCBhbiBB
UCB0aGF0IGl0J3MgZGV2aWNlIHR5cGUgdmFsdWUgaXMgNiBldGMuDQoNCj4gVGhhdCBpcyBJIGFt
IG5vdCBzZWVpbmcgYSBuZWVkIGZvciBhIG5ldyBmbGFnIGF0IHRoaXMgcG9pbnQgaW4gd2lyZWxl
c3MtcmVnZGIsDQo+IGdpdmVuIGFsc28gSSBtZW50aW9uZWQgYW5vdGhlciB0eXBlIG9mIGNhc2Ug
Zm9yIHJlZ3VsYXRvcnkgaGludHMgdGVjaG5pY2FsbHkNCj4gcG9zc2libGUgKGNlbGx1bGFyIGJh
c2Ugc3RhdGlvbiBoaW50cyBidXQgaXQgc2VlbXMgb25seSBhbGxvd2VkIHdpdGggZXhjZXB0aW9u
YWwNCj4gcmV2aWV3IGJ5IHRoZSBGQ0MpLg0KPiANCj4gSSB0YWtlIGl0IHdoYXQgeW91IHdhbnQg
dG8gZW5hYmxlIGhlcmUgaXMgR08gb3BlcmF0aW9uIG9uIERGUyBjaGFubmVscyBhbmQgdXNlDQo+
IGNvdW50cnkgSUVzIHRvIGRldGVybWluZSBpZiB5b3UgY2FuIHVzZSBHTywgYnV0IGlmIHlvdSBk
byBoYXZlIEdPIGVuYWJsZWQgdGhlbg0KPiB5b3UnZCB3YW50IGhvb2tzIHRvIG5vdCBkYWlzeSBj
aGFpbiwgYWNrPw0KDQpDdXJyZW50bHksIHdlIGRvIG5vdCBpbnRlbmQgdG8gYmFzZSB0aGUgcmVs
YXhhdGlvbiBvbiB0aGUgY291bnRyeSBJRSBkaXJlY3RseSwgYnV0IGJhc2UgaXQgb24gdGhlIGZh
Y3QgdGhhdCBpZiB0aGVyZSBpcyBhIG1hbmFnZWQgY29ubmVjdGlvbiB0byBhbiBBUCB3aG8ncyBu
b3QgYSBtb2JpbGUgZGV2aWNlIChhc3N1bWluZyB0aGF0IGl0IGlzIGFuIGF1dGhvcml6ZWQgbWFz
dGVyKSwgdGhhbiB0aGUgY2hhbm5lbCB1c2VkIGJ5IHRoZSBtYW5hZ2VkIGNvbm5lY3Rpb24gaXMg
dmFsaWQgZm9yIHVzZSAoYXMgbG9uZyBhcyB0aGUgbWFuYWdlZCBpbnRlcmZhY2UgaXMgY29ubmVj
dGVkIHRvIHRoZSBBUCBvbiB0aGUgY2hhbm5lbCkuIA0KDQo+DQo+ID4+ID4gMi4gSW5kb29yIG9w
ZXJhdGlvbiwgd2hlcmUgaW4gYmFuZHMgcmVxdWlyaW5nIGluZG9vciBvcGVyYXRpb24sIHRoZQ0K
PiA+PiA+ICAgIGRldmljZSBtdXN0IGJlIHByb2dyYW1tZWQgdG8gZGV0ZWN0IGluZG9vciBvcGVy
YXRpb24sIG9yDQo+ID4+ID4gICAgLSBEZXZpY2UgbXVzdCBiZSBjb25uZWN0ZWQgdG8gQUMgUG93
ZXINCj4gPj4NCj4gPj4gRG9lcyBhbnlvbmUgIGtub3cgaWYgdGhlIEZDQyBjb25zaWRlcnMgImlu
ZG9vciIgaWYgd2UgcG93ZXIgYSBkZXZpY2UNCj4gPj4gdGhyb3VnaCB0aGUgY2FyIG9uIEFDIHBv
d2VyIHRocm91Z2ggYSBjb252ZXJ0ZXIgPyBBcmUgd2Ugd2lsbGluZyB0bw0KPiA+PiBpZ25vcmUg
dGhhdCBjb3JuZXIgY2FzZT8NCj4gPg0KPiA+IE5vLiBBQyBwb3dlciBtZWFucyAibWFpbnMiIGFu
ZCBub3QgdGhyb3VnaCBwb3J0YWJsZSBEQyBjb252ZXJ0ZXJzIChzZWUNCj4gc2xpZGUgMTIgaW4N
Cj4gaHR0cHM6Ly9hcHBzLmZjYy5nb3YvZWFzL2NvbW1lbnRzL0dldFB1Ymxpc2hlZERvY3VtZW50
Lmh0bWw/aWQ9MzI3JnRuPQ0KPiA1MjgxMjIpLiBJdCB3b3VsZCBiZSB1cCB0byB0aGUgdXNlciBz
cGFjZSB0byBpZGVudGlmeSB0aGUgZGV2aWNlIHR5cGUgZXRjLiBhbmQNCj4gaWRlbnRpZnkgaWYg
dGhpcyBhIHRydWx5IEFDIHBvd2VyZWQgQVAuDQo+IA0KPiBPSyB0aGFua3MgZm9yIHRoZSBjbGFy
aWZpY2F0aW9uLiBJIHdvbmRlciBpZiB3ZSBjYW4gZGlzdGluZ3Vpc2ggYmV0d2VlbiB0aGUgdHdv
DQo+IGluIHVzZXJzcGFjZSB0b2RheS4gSSdtIGhhcHB5IHRvIHN0YXJ0IHBlZ2dpbmcgZnJlcXVl
bmN5IHJhbmdlcyBhcyBpbmRvb3Itb25seQ0KPiBvbiB3aXJlbGVzcy1yZWdkYiBldmVuIGlmIHdl
IGRvbid0IGhhdmUgdGhlIHVzZXJzcGFjZSBBUElzIHRvIGFubm90YXRlIHdoZW4gYQ0KPiBkZXZp
Y2UgaXMgaW5kb29yIG9yIG5vdCB5ZXQuIFBhdGNoZXMgd2VsY29tZWQgdGhlbi4NCj4gDQoNCkFn
YWluLCB3ZSBhcmUgZ29pbmcgdG8gdXNlIHRoZSBkZXZpY2UgdHlwZS9zdWIgdHlwZSBhcyBhbiBp
bmRpY2F0aW9uIHRvIGFuIEFQIGJlaW5nIEFDIHBvd2VyZWQuDQoNCj4gPj4gPiAgICAtIERldmlj
ZSBtdXN0IGJlIHVuZGVyIHRoZSBjb250cm9sIG9mIGEgbG9jYWwgbWFzdGVyIHRoYXQgaXMNCj4g
Pj4gPiBhY3RpbmcNCj4gPj4NCj4gPj4gSW50ZXJlc3RpbmcsIHNvIHNvbWUgQVBJcyB3b3VsZCBi
ZSBkZWZpbmVkLCBJIHRha2UgaXQgb24gaG9zdGFwZCB0bw0KPiA+PiBkbyB0aGUgcHJvcGVyIGNh
bGxiYWNrcyB0byAnc2xhdmUnIHR5cGUgb2YgZGV2aWNlcyB0aGF0IGRlcGVuZCBvbiB0aGUNCj4g
Pj4gbG9jYWwgbWFzdGVyKHMpLiBJIGNvdWxkIGVudmlzaW9uIHRoaXMgYmVpbmcgaW1wbGVtZW50
ZWQgb24gaG9zdGFwZA0KPiA+PiBieSBleHBhbmRpbmcgdGhlIEFQIGludGVyZmFjZSB0eXBlIGFu
ZCBhc3NvY2lhdGluZyAnc2xhdmUnIGRldmljZXMNCj4gPj4gYW5kIGNhbGxiYWNrcyBmb3IgdXBk
YXRlcyBvbiBBUCBkZXZpY2UgdXBkYXRlcyAoY2hhbm5lbCBjaGFuZ2VzLCBhbmQgc28NCj4gb24p
LiBJcyB0aGlzIHdvcmsgYmVpbmcgcGxhbm5lZD8NCj4gPg0KDQpOb3RlIHN1cmUgdGhhdCBJIGZv
bGxvdyAuLi4gSG93ZXZlciwgd2UgZG8gaW50ZW5kIHRvIGFkZCB0aGlzIHR5cGUgb2Ygc3VwcG9y
dCB0byBob3N0YXAuDQoNCj4gPiBZZXMuIFdlIGhhdmUgcGxhbnMgdG8gaW5jb3Jwb3JhdGUgbW9y
ZSBsb2dpYyB0byBob3N0YXAgKGN1cnJlbnRseSBpbnRvDQo+IHdwYV9zdXBwbGljYW50IGZvciBQ
MlAgdXNlIGNhc2VzKS4NCj4gDQo+IFN3ZWV0Lg0KPiANCj4gICBMdWlzDQoNCg0KDQo=
^ permalink raw reply
* RE: [PATCH 3/3] [RFC] cfg80211: Enable GO operation on additional channels
From: Peer, Ilan @ 2013-07-17 19:15 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Spinadel, David, linux-wireless,
wireless-regdb@lists.infradead.org, Jouni Malinen, Ginsburg, Noam,
Perelmooter, Liraz, Shalev, Oz, Michael Green
In-Reply-To: <CAB=NE6WY43BYDehH5-MyF0GQORC1dTrNToUsRVC-Q5bDwcna3A@mail.gmail.com>
PiBPbiBXZWQsIEp1bCAxMCwgMjAxMyBhdCAzOjQ3IEFNLCBQZWVyLCBJbGFuIDxpbGFuLnBlZXJA
aW50ZWwuY29tPiB3cm90ZToNCj4gPj4gQXJlIHlvdSBhd2FyZSBvZiBVTklJLTEsIFVOSUktMiwg
VU5JSS0yRSwgVU5JSS0zIGFyZSBzcGVjaWZpYyB3b3JsZA0KPiA+PiByZWd1bGF0b3J5IGxhbmd1
YWdlIGJhbmRzPyBXaGVuIEkgbGFzdCB0cmllZCB0byBsb29rIGZvciBhIGNsZWFyDQo+ID4+IGRl
ZmluaXRpb24gSSBjb3VsZCBub3QgZmluZCBhIGNsZWFyIGRlZmluaXRpb24gb2YgdGhlbSBhbmQg
aXRzIHdoeSBvbg0KPiA+PiB0aGUgYXRoIG1vZHVsZSBvbiBmb3IgUUNBIG1vZHVsZXMgSSBzdGF0
ZSAid2UgY2FsbCB0aGVzZSIgaW4NCj4gPj4gcmVmZXJlbmNlIHRvIHRoZSBVTklJIG5vbWVuY2xh
dHVyZS4gSWYgd2UgY2FuIGdldCBhIGNsZWFyIHJlc291cmNlIGZvciBpdHMNCj4gZGVmaW5pdGlv
biB0aGF0IHdvdWxkIGhlbHAgaGVyZS4NCj4gPj4NCj4gPg0KPiA+IE1heWJlIHRoZXNlIGxpbmsg
d2lsbCBoZWxwLg0KPiA+IGh0dHA6Ly93d3cuZ3BvLmdvdi9mZHN5cy9wa2cvQ0ZSLTIwMTAtdGl0
bGU0Ny12b2wxL3htbC9DRlItMjAxMC10aXRsZTQNCj4gPiA3LXZvbDEtcGFydDE1LnhtbCNzZXFu
dW0xNS40MDMNCj4gPiBodHRwOi8vaHJhdW5mb3NzLmZjYy5nb3YvZWRvY3NfcHVibGljL2F0dGFj
aG1hdGNoL0ZDQy0xMy0yMkExLnBkZg0KPiA+DQo+ID4gQW55d2F5LCBJIHdpbGwgdXNlIHlvdXIg
Jyd3ZSBjYWxsIHRoZXNlIiBub3RhdGlvbiBhcyB3ZWxsIDopDQo+IA0KPiBObyBubywgdGhpcyBp
cyBnb29kLCBpdHMganVzdCBVbml0ZWQgU3RhdGVzIC8gRkNDIGJpYXNlZCBhbmQgSSBoYWRuJ3Qg
c2VlbiB0aGUNCj4gZG9jdW1lbnRhdGlvbiB5b3UgcHJvdmlkZWQgYmVmb3JlLiBUaGlzIGNvbmZp
cm1zIHRoZXNlIGFyZSBvZmZpY2lhbCB0ZXJtcyBidXQNCj4gc3RpbGwganVzdCBVUyAvIEZDQyBi
aWFzZWQuIE15IHBvaW50IHdhcyB0aGF0IHdlIHNob3VsZCBiZSBjYXJlZnVsIHRvIG5vdCBtYWtl
DQo+IGdsb2JhbCBzdGF0ZW1lbnRzIG9uIHJlZ3VsYXRvcnkgY29kZSBhYm91dCB0aGluZ3MgdGhh
dCBhcmUgbm90IGdsb2JhbC4gSWYgd2UNCj4ga25vdyBvbmx5IHRoZSBGQ0MgY2FsbHMgdGhpcyBV
TklJIHdlbGwgbGV0cyBkb2N1bWVudCB0aGF0IGFuZCBwcm92aWRlIHRoZQ0KPiByZWZlcmVuY2Ug
eW91IHN1cHBsaWVkLiBJIGFudGljaXBhdGVkIGhhdmluZyB0byBkZWFsIHdpdGggc3BlY2lhbCBj
YXNlDQo+IHJlZ3VsYXRvcnkgY29kZSBvdXRzaWRlIG9mIG9mIHdoYXQgQ1JEQSAvIHdpcmVsZXNz
LXJlZ2RiIHByb3ZpZGVzIC0tIGdpdmVuIHRoYXQNCj4gQ1JEQSAvIHdpcmVsZXNzLXJlZ2RiIHdl
cmUgbWVhbnQgdG8gYmUgbW9yZSBSRiBhZ25vc3RpYyBhbnl3YXkuDQo+IA0KPiBHaXZlbiB0aGF0
IG90aGVyIHZlbmRvcnMgbWF5IGFsc28gd2FudCB0byBnZXQgdGhlIFVOSUkgYmFuZCBjYW4geW91
IHN0dWZmDQo+IGluc3RlYWQgY2ZnODAyMTFfZ2V0X3VuaWlfYmFuZCgpIGludG8gcmVnLmMgYW5k
IGRvIHRoZSAjaWZkZWYgcHJvcGVybHkgd2l0aCB0aGUNCj4gS2NvbmZpZywgYW5kIGV4cG9ydCBp
dCBhcyB3ZWxsLCBhcyB3ZWxsIGFzIGRvY3VtZW50IGl0IHByb3Blcmx5IHByb3ZpZGluZyB0aGUN
Cj4gcmVmZXJlbmNlIHlvdSBtZW50aW9uZWQuDQoNClN1cmUuDQoNCj4gDQo+ID4+ID4gKyAqIDEu
IEluZG9vciBvbmx5OiBhIEdPIGNhbiBiZSBvcGVyYXRpb25hbCBvbiBzdWNoIGEgY2hhbm5lbCwg
aWZmIHRoZXJlIGlzDQo+ID4+ID4gKyAqICAgIGNsZWFyIGFzc2Vzc21lbnQgdGhhdCB0aGUgcGxh
dGZvcm0gZGV2aWNlIGlzIGluZG9vci4NCj4gPj4gPiArICogMi4gQ29uY3VycmVudCBHTzogYSBH
TyBjYW4gYmUgb3BlcmF0aW9uYWwgb24gc3VjaCBhIGNoYW5uZWwsDQo+ID4+ID4gKyBpZmYgdGhl
cmUgaXMNCj4gPj4gYW4NCj4gPj4gPiArICogICAgYWRkaXRpb25hbCBzdGF0aW9uIGludGVyZmFj
ZSBjb25uZWN0ZWQgdG8gYW4gQVAgb24gdGhpcyBjaGFubmVsLg0KPiA+PiA+ICsgKg0KPiA+PiA+
ICsgKiBUT0RPOiBUaGUgZnVuY3Rpb24gaXMgdG9vIHBlcm1pc3NpdmUsIGFzIGl0IGRvZXMgbm90
IHZlcmlmeSB0aGUNCj4gPj4gPiArIHBsYXRmb3JtDQo+ID4+ID4gKyAqIGRldmljZSB0eXBlIGlz
IGluZGVlZCBpbmRvb3IsIG9yIHRoYXQgdGhlIEFQIGlzIGluZG9vci9BQyBwb3dlcmVkLg0KPiA+
Pg0KPiA+PiBTbyB0byBkbyB0aGlzIHByb3Blcmx5IHdlIG5lZWQgYW4gZXZlbnR1YWwgdXNlcnNw
YWNlIEFQSSB0byB0aHJvdyB0bw0KPiA+PiBrZXJuZWxzcGFjZSBpZiB3ZSBhcmUgQUMgcG93ZXJl
ZD8gV2UnbGwgbmVlZCB0aGlzIHRvIGVuaGFuY2UgdGhpcw0KPiA+PiByb3V0aW5lIGhlcmU/DQo+
ID4+DQo+ID4NCj4gPiBOb3Qgc3VyZSBhYm91dCB0aGlzIHBvaW50LiBJIHByZWZlciBsZWF2aW5n
IHRoZSBleGFjdCBrbm93bGVkZ2Ugb2YgdGhlIGRldmljZQ0KPiB0eXBlLCBiZWluZyBBQyBQb3dl
cmVkIG9yIG5vdCAoYW5kIHdoaWNoIHR5cGUgb2YgQUMgcG93ZXIpIGV0Yy4gb3V0IHNpZGUgb2Yg
dGhlDQo+IGtlcm5lbC4gVGhlIGFwcHJvYWNoIEkgY2hvc2Ugd2l0aCB0aGlzIHBhdGNoIHdhcyB0
byBvbmx5IGFsbG93IHRvIHN0YXJ0IGEgR08gb24NCj4gc3VjaCBhIGNoYW5uZWwsIG1ha2luZyB0
aGUgYmFzaWMgdmVyaWZpY2F0aW9uIGRvbmUgYWJvdmUsIGFzc3VtaW5nIHRoYXQgdGhlDQo+IHVz
ZXIgc3BhY2UgY29tcG9uZW50IGd1YXJhbnRlZXMgdGhhdCBhbGwgdGhlIGZ1bGwgcmVzdHJpY3Rp
b25zIGFyZSBzYXRpc2ZpZWQuDQo+IA0KPiBGYWlyIGVub3VnaC4gU2VlbXMgd2UganVzdCBuZWVk
IHRvIHplcm8gaW4gbm93IG9uIHRoZSByZXF1aXJlbWVudCBvciBub3Qgb24NCj4gdGhlIGV4dHJh
IGZsYWcgeW91IHN1Z2dlc3RlZC4NCj4gDQo+ID4+IEluIHRoZSBtZWFudGltZSwgd2hpbGUgeW91
IGdldCBhbGwgeW91ciBwYXRjaCBzZXRzIHByb3Blcmx5IGRldmVsb3BlZA0KPiA+PiBJJ2QgcmVj
b21tZW5kIHRvIGRlZmluZSB0aGUgY29kZSByZXR1cm5pbmcgZmFsc2UgdGhlcmUgc3RyaWN0bHkg
b3INCj4gPj4gcGVyaGFwcyBmb3IgYW55IGZsYWcgb24gdGhlIGNoYW5uZWwgcmVxdWlyaW5nIERG
UyAvIG5vLWlic3MsIG9yDQo+ID4+IHBhc3NpdmUgc2Nhbi4gVGhlIHN0cmljdGVyIGNhc2UsIGRl
ZmluaW5nIGZhbHNlIGFsd2F5cywgc2VlbXMgdG8gYmUgd2hhdCB5b3UNCj4gYXJlIHN1Z2dlc3Rp
bmcgaGVyZS4NCj4gPg0KPiA+IEkgZG8gbm90IHRoaW5rIHRoYXQgdGhpcyBpcyBuZWVkZWQgaGVy
ZS4gUmV0dXJuaW5nIGZhbHNlLCBtZWFucyB0aGF0IHRoZSBjb2RlDQo+IHNob3VsZCB0ZXN0IGlm
IHRoZSBQQVNTSVZFX1NDQU4gYW5kIE5PX0lCU1MgYXJlIG5vdCBzZXQgb24gdGhlIGNoYW5uZWwg
d2UNCj4gd2FudCB0byBzdGFydCBiZWFjb25pbmcgb24uDQo+ID4NCj4gPj4gRG8geW91IGhhdmUg
YSB3aGl0ZSBsaXN0IHRoYXQgY2FuIGV4Y2x1ZGUgc29tZSBjaGFubmVscyBmb3Igbm93DQo+ID4+
IGdsb2JhbGx5IG9yIHNvbWVob3cgYXMgYWxsIHRoaXMgbGluZXMgdXA/DQo+ID4+DQo+ID4NCg0K
SSdsbCB0cnkgdG8gcHJvdmlkZSBzdWNoIGxpc3QgLi4uIA0KDQo+ID4gTm90ZSBzdXJlIEkgdW5k
ZXJzdG9vZCB3aGF0IHlvdSBhcmUgbG9va2luZyBmb3IuIENhbiB5b3UgcGxlYXNlIGNsYXJpZnkg
dGhpcw0KPiBwb2ludD8NCj4gDQo+IEl0IHdhcyB1bmNsZWFyIGZvciB3aGF0IGV4YWN0IGNoYW5u
ZWxzIHlvdSBuZWVkZWQgdG8gZGVhbCB3aXRoIGhlcmUuDQo+IEdpdmVuIHJldmlldyBzbyBmYXIg
d291bGRuJ3QgaXQganVzdCBiZSBERlMgZmxhZ2dlZCBjaGFubmVscyBvbiBzb21lIFVOSUkNCj4g
YmFuZHMgPyBUaGVuIGFnYWluIGlmIHRoZSBpbmRvb3IgZmxhZyBuZWVkcyB0byBiZSBwZWdnZWQg
dG8gdG8gYSBzcGVjaWZpYyBVTklJDQo+IGJhbmQgYW5kIHdlIGNhbiBkbyB0aGF0IG9uIHdpcmVs
ZXNzLXJlZ2RiIGRvIHdlIGV2ZW4gbmVlZCB0aGUgVU5JSSBiYW5kDQo+IGNoZWNrIHJvdXRpbmUg
aGVscGVyPw0KPiANCg0KR2VuZXJhbGx5IGl0IGlzIHBvc3NpYmxlIHRoYXQgdGhlIGluZG9vciBw
cm9wZXJ0eSBpcyBub3QgcGVnZ2VkIHRvIHRoZSAnb3RoZXJfY2hhbm5lbCcsIG9yIGl0IGlzIHBv
c3NpYmxlIHRoYXQgaXQgaXMgcGVnZ2VkIGJ1dCB0aGV5IGFyZSBub3QgaW4gdGhlIHNhbWUgVU5J
SSBiYW5kLCBzbyB0aGUgdmVyaWZpY2F0aW9uIGlzIHN0aWxsIG5lZWRlZC4gSSBndWVzcyB0aGF0
IG9uY2UgSSBnZXQgdGhlIGxpc3QgeW91IHJlcXVlc3RlZCB0aGluZ3Mgd2lsbCBiZSBjbGVhcmVy
IDopIA0KDQpSZWdhcmRzLA0KDQpJbGFuLg0KDQo=
^ permalink raw reply
* Re: [PATCH] Documentation: dt: bindings: TI WiLink modules
From: Laurent Pinchart @ 2013-07-17 23:58 UTC (permalink / raw)
To: Luciano Coelho
Cc: mturquette, Mark Rutland, balbi, grant.likely@linaro.org,
rob.herring@calxeda.com, devicetree-discuss@lists.ozlabs.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-omap@vger.kernel.org, linux-wireless@vger.kernel.org,
linux-arm@vger.kernel.org
In-Reply-To: <1372682370.21065.68.camel@cumari.coelho.fi>
Hi Luciano,
On Monday 01 July 2013 15:39:30 Luciano Coelho wrote:
> On Fri, 2013-06-28 at 16:21 +0300, Luciano Coelho wrote:
> > On Fri, 2013-06-28 at 15:18 +0300, Felipe Balbi wrote:
> > > On Fri, Jun 28, 2013 at 03:13:52PM +0300, Luciano Coelho wrote:
> > > > On Fri, 2013-06-28 at 14:41 +0300, Felipe Balbi wrote:
> > > > > On Fri, Jun 28, 2013 at 02:22:11PM +0300, Luciano Coelho wrote:
> > > > > > On Fri, 2013-06-28 at 13:31 +0300, Luciano Coelho wrote:
> > > > > > > (fixed Mike's address)
> > > > > > >
> > > > > > > On Fri, 2013-06-28 at 11:21 +0100, Mark Rutland wrote:
> > > > > > > > On Fri, Jun 28, 2013 at 10:53:35AM +0100, Luciano Coelho
wrote:
> > > > > > > > > On Fri, 2013-06-28 at 10:38 +0100, Mark Rutland wrote:
> > > > > > > > > > On Tue, Jun 25, 2013 at 09:35:30AM +0100, Luciano Coelho
wrote:
> > > > > > > > > > > +Optional properties:
> > > > > > > > > > > +--------------------
> > > > > > > > > > > +
> > > > > > > > > > > +- refclock: the internal WLAN reference clock frequency
> > > > > > > > > > > (required for
> > > > > > > > > > > + WiLink6 and WiLink7; not used for WiLink8). Must be
> > > > > > > > > > > one of the
> > > > > > > > > > > + following:
> > > > > > > > > > > + 0 = 19.2 MHz
> > > > > > > > > > > + 1 = 26.0 MHz
> > > > > > > > > > > + 2 = 38.4 MHz
> > > > > > > > > > > + 3 = 52.0 MHz
> > > > > > > > > > > + 4 = 38.4 MHz, XTAL
> > > > > > > > > > > + 5 = 26.0 MHz, XTAL
> > > > > > > > > > > +
> > > > > > > > > > > +- tcxoclock: the internal WLAN TCXO clock frequency
> > > > > > > > > > > (required for
> > > > > > > > > > > + WiLink7 not used for WiLink6 and WiLink8). Must be
> > > > > > > > > > > one of the
> > > > > > > > > > > + following:
> > > > > > > > > > > + 0 = 19.200 MHz
> > > > > > > > > > > + 1 = 26.000 MHz
> > > > > > > > > > > + 2 = 38.400 MHz
> > > > > > > > > > > + 3 = 52.000 MHz
> > > > > > > > > > > + 4 = 16.368 MHz
> > > > > > > > > > > + 5 = 32.736 MHz
> > > > > > > > > > > + 6 = 16.800 MHz
> > > > > > > > > > > + 7 = 33.600 MHz
> > > > > > > > > >
> > > > > > > > > > This looks suspiciously like what we have the common clock
> > > > > > > > > > bindings for:
> > > > > > > > > >
> > > > > > > > > > refclk {
> > > > > > > > > >
> > > > > > > > > > compatible = "fixed-clock";
> > > > > > > > > > #clock-cells = <0>;
> > > > > > > > > > clock-frequency = <19200000>;
> > > > > > > > > >
> > > > > > > > > > }
> > > > > > > > > >
> > > > > > > > > > wilink {
> > > > > > > > > >
> > > > > > > > > > compatible = "ti,wilink7";
> > > > > > > > > > interrupt-parent = <&some_interrupt_controller>;
> > > > > > > > > > interrupts = <0 1 1>;
> > > > > > > > > > clocks = <&refclk>, <&refclk>;
> > > > > > > > > > clock-names = "refclk", "txoclk";
> > > > > > > > > >
> > > > > > > > > > };
> > > > > > > > > >
> > > > > > > > > > Could you not use them?
> > > > > > > > >
> > > > > > > > > Hmmm... this actually does look good. But these are
> > > > > > > > > internal clocks in the modules, they cannot be accessed from
> > > > > > > > > outside. Does it make sense to register them with the clock
> > > > > > > > > framework?
> > > > > > > >
> > > > > > > > Given we already have a common way of describing clocks, I
> > > > > > > > think it makes sense to use it -- people already understand
> > > > > > > > the common bindings, and it's less code to add add to the
> > > > > > > > kernel. I don't think the fact these clocks are internal
> > > > > > > > should prevent us from describing them as we would an external
> > > > > > > > clock.
> > > > > > >
> > > > > > > Yes, I agree with you. Thanks for the suggestion! I think it
> > > > > > > will look much better. And now that I dug a bit more into the
> > > > > > > code, I can see that there are only structs being populated, so
> > > > > > > there shouldn't be any other side-effects.
> > > > > >
> > > > > > Hmmm, one thing that escaped me. Besides the frequency, I also
> > > > > > need a boolean that tells if the clock is XTAL or not. I can't
> > > > > > figure out how to pass this if I use the generic clock framework.
> > > > > > Any suggestions?
> > > > >
> > > > > Could you use clock-output-names for that ?
> > > > >
> > > > > XTAL clock:
> > > > >
> > > > > refclk {
> > > > >
> > > > > compatible = "fixed-clock";
> > > > > #clock cells = <0>;
> > > > > clock-frequency = <19200000>;
> > > > > clock-output-names = "xtal";
> > > > >
> > > > > };
> > > > >
> > > > > non-XTAL clock:
> > > > >
> > > > > refclk {
> > > > >
> > > > > compatible = "fixed-clock";
> > > > > #clock cells = <0>;
> > > > > clock-frequency = <19200000>;
> > > > > clock-output-names = "osc"; /* any better name ? */
> > > > >
> > > > > };
> > > >
> > > > This starts looking a bit hacky. Using the output name as a flag is
> > > > not very pretty.
> > > >
> > > > I think it would be better to have a separate flag for it in the wlan
> > > > node. Like an optional "refclock-xtal" boolean or something. The
> > > > downside of this is that we would be adding information about the
> > > > clock details in the wilink node. :(
> > > >
> > > > OTOH, we could add a flag to the generic clock binding? A new optional
> > > > boolean that tells whether the clock is XTAL or not:
> > > >
> > > > refclk {
> > > >
> > > > compatible = "fixed-clock";
> > > > #clock cells = <0>;
> > > > clock-frequency = <19200000>;
> > > > clock-xtal;
> > > >
> > > > };
> > > >
> > > > Do you think that would make sense?
> > >
> > > sure, that looks alright to me. Surely there are other devices out there
> > > who want to know if the clock comes from a crystal or not ?!?
> >
> > Mike, what do you think about this idea? If it sounds okay to you, I can
> > cook up a patch adding this flag.
>
> Hmmm... I started implementing this whole thing, but using these clocks
> as "fixed-clock"s is not so straightforward. The problem is that I
> would need to register my driver as a clock provider and add the OF
> match for "fixed-clock".
>
> If I do that, all the other "fixed-clock" nodes would be passed to my
> driver too, which is wrong. Or, the platform should register the
> "fixed-clock" match, but this would be wrong too, since it would find
> *my* fixed-clocks.
>
> The only thing I can come up with is to make a small clock driver (maybe
> even inside the WiLink module itself) that registers a new type of
> clock, "ti,wilink-clock" or something. But this would really be
> overkill, wouldn't it?
>
> Any other ideas?
One possibility would be to just call clk_get_rate() on the clock from the
WiLink driver, which would return the fixed frequency specified in DT, and
configure the WiLink hardware accordingly. This might be a bit hackish though.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* RE: So, which IEEE<->Frequency mappings should we be all using?
From: Wright, Brett @ 2013-07-18 0:58 UTC (permalink / raw)
To: Adrian Chadd, freebsd-wireless, linux-wireless
In-Reply-To: <CAJ-Vmo=yvHUgv6pwK42n+NhPrAu9shxc5pigRkhZE+x91W_FoA@mail.gmail.com>
> -----Original Message-----
> From: owner-freebsd-wireless@freebsd.org [mailto:owner-freebsd-
> wireless@freebsd.org] On Behalf Of Adrian Chadd
> Sent: Thursday, 18 July 2013 3:42 AM
> To: freebsd-wireless@freebsd.org; linux-wireless@vger.kernel.org
> Subject: So, which IEEE<->Frequency mappings should we be all using?
>
> Hi all,
>
> I've been increasingly asked to bring up FreeBSD on "other" bands.
>
> * 420MHz
> * 700MHz
> * 900MHz (which we already have, due to history);
> * 3.6GHz
> * 4.9GHz
>
> I'd also like to support half and quarter width channels on these
frequencies.
> If I use the 2GHz channel mapping method, I end up with a very
restricted
> channel set and it definitely has no "gaps" for 5/10MHz increments.
>
> Now, what I'd like to do is figure out some sane, shared method of
> translating channel frequencies to IEEE numbers and back. That way the
BSDs
> and Linux (and maybe commercial stacks; I dunno what they do) can have
> some sane chance of interoperating.
>
> So: Is there some standardised or semi-standardised channel mapping
> method? Or should we invent one?
>
>
> -adrian
Hi Adrian,
I wanted to make similar changes to madwifi some years ago, and as there
was no standard I invented one.
This likely won't align with your requirements, but share some details
below in case it may help.
The approach I took was that the ieee channel numbers should overlap for
the different frequency bands, as there are a huge number of different
channels once you include all bands + 5, 10, 20, (and maybe 40) channel
widths (not such a big deal since no manufacturers seem to offer a radio
that supports more than one of the lower frequency bands on one board).
This way the 20MHz channel numbers were unchanged for all bands (as they
report as 2.4GHz band anyway), and the 5 and 10 MHz widths I mapped
above channel 14 using mapgsm() and ath_hal_mhz2ieee(), plus other
additions like unmapgsm, etc.
To cut a long story short I ended up with channels 1-14 for 20MHz, 21-34
for 5MHz, and 41-54 for 10MHz.
^ permalink raw reply
* [PATCH 0/3] ath10k: fixes
From: Michal Kazior @ 2013-07-18 6:33 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
Hi,
Here are some fixes for ath10k. The rts threshold
patch addresses my mistake in commit
9aeb6fe53d1f0d6e58658484ce9ad7b59f0ef16b which
caused rts to be always enabled causing throughput
issues in some cases.
Michal Kazior (3):
ath10k: prevent HTC from being used after stopping
ath10k: fix memleak in mac setup
ath10k: fix rts/fragmentation threshold setup
drivers/net/wireless/ath/ath10k/htc.c | 28 ++++++------
drivers/net/wireless/ath/ath10k/htc.h | 4 +-
drivers/net/wireless/ath/ath10k/mac.c | 80 ++++++++++++++++++---------------
3 files changed, 58 insertions(+), 54 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [PATCH 1/3] ath10k: prevent HTC from being used after stopping
From: Michal Kazior @ 2013-07-18 6:33 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1374129193-3533-1-git-send-email-michal.kazior@tieto.com>
It was possible to submit new HTC commands
after/while HTC stopped. This led to memory
corruption in some rare cases.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
drivers/net/wireless/ath/ath10k/htc.c | 28 +++++++++++++---------------
drivers/net/wireless/ath/ath10k/htc.h | 4 ++--
2 files changed, 15 insertions(+), 17 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/htc.c b/drivers/net/wireless/ath/ath10k/htc.c
index 7d5a366..f5610f1 100644
--- a/drivers/net/wireless/ath/ath10k/htc.c
+++ b/drivers/net/wireless/ath/ath10k/htc.c
@@ -251,10 +251,14 @@ int ath10k_htc_send(struct ath10k_htc *htc,
return -ENOENT;
}
- skb_push(skb, sizeof(struct ath10k_htc_hdr));
-
spin_lock_bh(&htc->tx_lock);
+ if (htc->stopped) {
+ spin_unlock_bh(&htc->tx_lock);
+ return -ESHUTDOWN;
+ }
+
__skb_queue_tail(&ep->tx_queue, skb);
+ skb_push(skb, sizeof(struct ath10k_htc_hdr));
spin_unlock_bh(&htc->tx_lock);
queue_work(htc->ar->workqueue, &ep->send_work);
@@ -267,23 +271,17 @@ static int ath10k_htc_tx_completion_handler(struct ath10k *ar,
{
struct ath10k_htc *htc = &ar->htc;
struct ath10k_htc_ep *ep = &htc->endpoint[eid];
- bool stopping;
ath10k_htc_notify_tx_completion(ep, skb);
/* the skb now belongs to the completion handler */
+ /* note: when using TX credit flow, the re-checking of queues happens
+ * when credits flow back from the target. in the non-TX credit case,
+ * we recheck after the packet completes */
spin_lock_bh(&htc->tx_lock);
- stopping = htc->stopping;
- spin_unlock_bh(&htc->tx_lock);
-
- if (!ep->tx_credit_flow_enabled && !stopping)
- /*
- * note: when using TX credit flow, the re-checking of
- * queues happens when credits flow back from the target.
- * in the non-TX credit case, we recheck after the packet
- * completes
- */
+ if (!ep->tx_credit_flow_enabled && !htc->stopped)
queue_work(ar->workqueue, &ep->send_work);
+ spin_unlock_bh(&htc->tx_lock);
return 0;
}
@@ -948,7 +946,7 @@ void ath10k_htc_stop(struct ath10k_htc *htc)
struct ath10k_htc_ep *ep;
spin_lock_bh(&htc->tx_lock);
- htc->stopping = true;
+ htc->stopped = true;
spin_unlock_bh(&htc->tx_lock);
for (i = ATH10K_HTC_EP_0; i < ATH10K_HTC_EP_COUNT; i++) {
@@ -957,7 +955,6 @@ void ath10k_htc_stop(struct ath10k_htc *htc)
}
ath10k_hif_stop(htc->ar);
- ath10k_htc_reset_endpoint_states(htc);
}
/* registered target arrival callback from the HIF layer */
@@ -969,6 +966,7 @@ int ath10k_htc_init(struct ath10k *ar)
spin_lock_init(&htc->tx_lock);
+ htc->stopped = false;
ath10k_htc_reset_endpoint_states(htc);
/* setup HIF layer callbacks */
diff --git a/drivers/net/wireless/ath/ath10k/htc.h b/drivers/net/wireless/ath/ath10k/htc.h
index 1606c9f..e1dd8c7 100644
--- a/drivers/net/wireless/ath/ath10k/htc.h
+++ b/drivers/net/wireless/ath/ath10k/htc.h
@@ -335,7 +335,7 @@ struct ath10k_htc {
struct ath10k *ar;
struct ath10k_htc_ep endpoint[ATH10K_HTC_EP_COUNT];
- /* protects endpoint and stopping fields */
+ /* protects endpoint and stopped fields */
spinlock_t tx_lock;
struct ath10k_htc_ops htc_ops;
@@ -349,7 +349,7 @@ struct ath10k_htc {
struct ath10k_htc_svc_tx_credits service_tx_alloc[ATH10K_HTC_EP_COUNT];
int target_credit_size;
- bool stopping;
+ bool stopped;
};
int ath10k_htc_init(struct ath10k *ar);
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/3] ath10k: fix memleak in mac setup
From: Michal Kazior @ 2013-07-18 6:33 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1374129193-3533-1-git-send-email-michal.kazior@tieto.com>
In some cases channel arrays were never freed.
The patch also unifies error handling in the mac
setup function.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 26 +++++++++++++++-----------
1 file changed, 15 insertions(+), 11 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 5082503..3d0f876 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3025,8 +3025,10 @@ int ath10k_mac_register(struct ath10k *ar)
channels = kmemdup(ath10k_2ghz_channels,
sizeof(ath10k_2ghz_channels),
GFP_KERNEL);
- if (!channels)
- return -ENOMEM;
+ if (!channels) {
+ ret = -ENOMEM;
+ goto err_free;
+ }
band = &ar->mac.sbands[IEEE80211_BAND_2GHZ];
band->n_channels = ARRAY_SIZE(ath10k_2ghz_channels);
@@ -3045,11 +3047,8 @@ int ath10k_mac_register(struct ath10k *ar)
sizeof(ath10k_5ghz_channels),
GFP_KERNEL);
if (!channels) {
- if (ar->phy_capability & WHAL_WLAN_11G_CAPABILITY) {
- band = &ar->mac.sbands[IEEE80211_BAND_2GHZ];
- kfree(band->channels);
- }
- return -ENOMEM;
+ ret = -ENOMEM;
+ goto err_free;
}
band = &ar->mac.sbands[IEEE80211_BAND_5GHZ];
@@ -3113,25 +3112,30 @@ int ath10k_mac_register(struct ath10k *ar)
ath10k_reg_notifier);
if (ret) {
ath10k_err("Regulatory initialization failed\n");
- return ret;
+ goto err_free;
}
ret = ieee80211_register_hw(ar->hw);
if (ret) {
ath10k_err("ieee80211 registration failed: %d\n", ret);
- return ret;
+ goto err_free;
}
if (!ath_is_world_regd(&ar->ath_common.regulatory)) {
ret = regulatory_hint(ar->hw->wiphy,
ar->ath_common.regulatory.alpha2);
if (ret)
- goto exit;
+ goto err_unregister;
}
return 0;
-exit:
+
+err_unregister:
ieee80211_unregister_hw(ar->hw);
+err_free:
+ kfree(ar->mac.sbands[IEEE80211_BAND_2GHZ].channels);
+ kfree(ar->mac.sbands[IEEE80211_BAND_5GHZ].channels);
+
return ret;
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH 3/3] ath10k: fix rts/fragmentation threshold setup
From: Michal Kazior @ 2013-07-18 6:33 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1374129193-3533-1-git-send-email-michal.kazior@tieto.com>
If RTS and fragmentation threshold values are
0xFFFFFFFF they should be considered disabled and
no min/max limits must be applied.
This fixes some issues with throughput issues,
especially with VHT.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 54 +++++++++++++++++----------------
1 file changed, 28 insertions(+), 26 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 3d0f876..019c6b8 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -331,6 +331,29 @@ static int ath10k_peer_create(struct ath10k *ar, u32 vdev_id, const u8 *addr)
return 0;
}
+static int ath10k_mac_set_rts(struct ath10k_vif *arvif, u32 value)
+{
+ if (value != 0xFFFFFFFF)
+ value = min_t(u32, arvif->ar->hw->wiphy->rts_threshold,
+ ATH10K_RTS_MAX);
+
+ return ath10k_wmi_vdev_set_param(arvif->ar, arvif->vdev_id,
+ WMI_VDEV_PARAM_RTS_THRESHOLD,
+ value);
+}
+
+static int ath10k_mac_set_frag(struct ath10k_vif *arvif, u32 value)
+{
+ if (value != 0xFFFFFFFF)
+ value = clamp_t(u32, arvif->ar->hw->wiphy->frag_threshold,
+ ATH10K_FRAGMT_THRESHOLD_MIN,
+ ATH10K_FRAGMT_THRESHOLD_MAX);
+
+ return ath10k_wmi_vdev_set_param(arvif->ar, arvif->vdev_id,
+ WMI_VDEV_PARAM_FRAGMENTATION_THRESHOLD,
+ value);
+}
+
static int ath10k_peer_delete(struct ath10k *ar, u32 vdev_id, const u8 *addr)
{
int ret;
@@ -1803,7 +1826,7 @@ static int ath10k_add_interface(struct ieee80211_hw *hw,
struct ath10k_vif *arvif = ath10k_vif_to_arvif(vif);
enum wmi_sta_powersave_param param;
int ret = 0;
- u32 value, rts, frag;
+ u32 value;
int bit;
mutex_lock(&ar->conf_mutex);
@@ -1906,20 +1929,12 @@ static int ath10k_add_interface(struct ieee80211_hw *hw,
ath10k_warn("Failed to set PSPOLL count: %d\n", ret);
}
- rts = min_t(u32, ar->hw->wiphy->rts_threshold, ATH10K_RTS_MAX);
- ret = ath10k_wmi_vdev_set_param(ar, arvif->vdev_id,
- WMI_VDEV_PARAM_RTS_THRESHOLD,
- rts);
+ ret = ath10k_mac_set_rts(arvif, ar->hw->wiphy->rts_threshold);
if (ret)
ath10k_warn("failed to set rts threshold for vdev %d (%d)\n",
arvif->vdev_id, ret);
- frag = clamp_t(u32, ar->hw->wiphy->frag_threshold,
- ATH10K_FRAGMT_THRESHOLD_MIN,
- ATH10K_FRAGMT_THRESHOLD_MAX);
- ret = ath10k_wmi_vdev_set_param(ar, arvif->vdev_id,
- WMI_VDEV_PARAM_FRAGMENTATION_THRESHOLD,
- frag);
+ ret = ath10k_mac_set_frag(arvif, ar->hw->wiphy->frag_threshold);
if (ret)
ath10k_warn("failed to set frag threshold for vdev %d (%d)\n",
arvif->vdev_id, ret);
@@ -2627,11 +2642,7 @@ static void ath10k_set_rts_iter(void *data, u8 *mac, struct ieee80211_vif *vif)
lockdep_assert_held(&arvif->ar->conf_mutex);
- rts = min_t(u32, rts, ATH10K_RTS_MAX);
-
- ar_iter->ret = ath10k_wmi_vdev_set_param(ar_iter->ar, arvif->vdev_id,
- WMI_VDEV_PARAM_RTS_THRESHOLD,
- rts);
+ ar_iter->ret = ath10k_mac_set_rts(arvif, rts);
if (ar_iter->ret)
ath10k_warn("Failed to set RTS threshold for VDEV: %d\n",
arvif->vdev_id);
@@ -2663,19 +2674,10 @@ static void ath10k_set_frag_iter(void *data, u8 *mac, struct ieee80211_vif *vif)
struct ath10k_generic_iter *ar_iter = data;
struct ath10k_vif *arvif = ath10k_vif_to_arvif(vif);
u32 frag = ar_iter->ar->hw->wiphy->frag_threshold;
- int ret;
lockdep_assert_held(&arvif->ar->conf_mutex);
- frag = clamp_t(u32, frag,
- ATH10K_FRAGMT_THRESHOLD_MIN,
- ATH10K_FRAGMT_THRESHOLD_MAX);
-
- ret = ath10k_wmi_vdev_set_param(ar_iter->ar, arvif->vdev_id,
- WMI_VDEV_PARAM_FRAGMENTATION_THRESHOLD,
- frag);
-
- ar_iter->ret = ret;
+ ar_iter->ret = ath10k_mac_set_frag(arvif, frag);
if (ar_iter->ret)
ath10k_warn("Failed to set frag threshold for VDEV: %d\n",
arvif->vdev_id);
--
1.7.9.5
^ permalink raw reply related
* [PATCH] ath10k: move irq setup
From: Michal Kazior @ 2013-07-18 6:39 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
There was a slight race during PCI shutdown. Since
interrupts weren't really stopped (only Copy
Engine interrupts were disabled through device hw
registers) it was possible for a firmware
indication (crash) interrupt to come in after
tasklets were synced/killed. This would cause
memory corruption and a panic in most cases. It
was also possible for interrupt to come before CE
was initialized during device probing.
Interrupts are required for BMI phase so they are
enabled as soon as power_up() is called but are
freed upon both power_down() and stop() so there's
asymmetry here. As by design stop() cannot be
followed by start() it is okay. Both power_down()
and stop() should be merged later on to avoid
confusion.
Before this can be really properly fixed var/hw
init code split is necessary.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
Please note: this is based on my (still under
review at the time of posting) previous patchests:
device setup refactor and recovery.
I'm posting this before those patchsets are merged
so anyone interested in testing this fix (I can't
reproduce the problem on my setup) can give it a
try.
drivers/net/wireless/ath/ath10k/pci.c | 36 +++++++++++++++++++++++----------
drivers/net/wireless/ath/ath10k/pci.h | 1 +
2 files changed, 26 insertions(+), 11 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index c71b488..e814151 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -56,6 +56,8 @@ static void ath10k_pci_rx_pipe_cleanup(struct hif_ce_pipe_info *pipe_info);
static void ath10k_pci_stop_ce(struct ath10k *ar);
static void ath10k_pci_device_reset(struct ath10k *ar);
static int ath10k_pci_reset_target(struct ath10k *ar);
+static int ath10k_pci_start_intr(struct ath10k *ar);
+static void ath10k_pci_stop_intr(struct ath10k *ar);
static const struct ce_attr host_ce_config_wlan[] = {
/* host->target HTC control and raw streams */
@@ -827,6 +829,7 @@ static void ath10k_pci_stop_ce(struct ath10k *ar)
int i;
ath10k_ce_disable_interrupts(ar);
+ ath10k_pci_stop_intr(ar);
/* Cancel the pending tasklet */
tasklet_kill(&ar_pci->intr_tq);
@@ -1742,6 +1745,12 @@ static int ath10k_pci_hif_power_up(struct ath10k *ar)
{
int ret;
+ ret = ath10k_pci_start_intr(ar);
+ if (ret) {
+ ath10k_err("could not start interrupt handling (%d)\n", ret);
+ goto err;
+ }
+
/*
* Bring the target up cleanly.
*
@@ -1756,7 +1765,7 @@ static int ath10k_pci_hif_power_up(struct ath10k *ar)
ret = ath10k_pci_reset_target(ar);
if (ret)
- goto err;
+ goto err_intr;
if (ath10k_target_ps) {
ath10k_dbg(ATH10K_DBG_PCI, "on-chip power save enabled\n");
@@ -1783,16 +1792,24 @@ static int ath10k_pci_hif_power_up(struct ath10k *ar)
return 0;
err_ce:
+ /* XXX: Until var/hw init is split it's impossible to fix the ordering
+ * here so we must call stop_intr() here too to prevent interrupts after
+ * CE is teared down. It's okay to double call the stop_intr() */
+ ath10k_pci_stop_intr(ar);
ath10k_pci_ce_deinit(ar);
err_ps:
if (!ath10k_target_ps)
ath10k_do_pci_sleep(ar);
+err_intr:
+ ath10k_pci_stop_intr(ar);
err:
return ret;
}
static void ath10k_pci_hif_power_down(struct ath10k *ar)
{
+ ath10k_pci_stop_intr(ar);
+
ath10k_pci_ce_deinit(ar);
if (!ath10k_target_ps)
ath10k_do_pci_sleep(ar);
@@ -2119,6 +2136,7 @@ static int ath10k_pci_start_intr(struct ath10k *ar)
ret = ath10k_pci_start_intr_legacy(ar);
exit:
+ ar_pci->intr_started = ret == 0;
ar_pci->num_msi_intrs = num;
ar_pci->ce_count = CE_COUNT;
return ret;
@@ -2129,6 +2147,9 @@ static void ath10k_pci_stop_intr(struct ath10k *ar)
struct ath10k_pci *ar_pci = ath10k_pci_priv(ar);
int i;
+ if (ar_pci->intr_started == false)
+ return;
+
/* There's at least one interrupt irregardless whether its legacy INTR
* or MSI or MSI-X */
for (i = 0; i < max(1, ar_pci->num_msi_intrs); i++)
@@ -2136,6 +2157,8 @@ static void ath10k_pci_stop_intr(struct ath10k *ar)
if (ar_pci->num_msi_intrs > 0)
pci_disable_msi(ar_pci->pdev);
+
+ ar_pci->intr_started = false;
}
static int ath10k_pci_reset_target(struct ath10k *ar)
@@ -2358,22 +2381,14 @@ static int ath10k_pci_probe(struct pci_dev *pdev,
ar_pci->cacheline_sz = dma_get_cache_alignment();
- ret = ath10k_pci_start_intr(ar);
- if (ret) {
- ath10k_err("could not start interrupt handling (%d)\n", ret);
- goto err_iomap;
- }
-
ret = ath10k_core_register(ar);
if (ret) {
ath10k_err("could not register driver core (%d)\n", ret);
- goto err_intr;
+ goto err_iomap;
}
return 0;
-err_intr:
- ath10k_pci_stop_intr(ar);
err_iomap:
pci_iounmap(pdev, mem);
err_master:
@@ -2410,7 +2425,6 @@ static void ath10k_pci_remove(struct pci_dev *pdev)
tasklet_kill(&ar_pci->msi_fw_err);
ath10k_core_unregister(ar);
- ath10k_pci_stop_intr(ar);
pci_set_drvdata(pdev, NULL);
pci_iounmap(pdev, ar_pci->mem);
diff --git a/drivers/net/wireless/ath/ath10k/pci.h b/drivers/net/wireless/ath/ath10k/pci.h
index d3a2e6c..5eb628f 100644
--- a/drivers/net/wireless/ath/ath10k/pci.h
+++ b/drivers/net/wireless/ath/ath10k/pci.h
@@ -198,6 +198,7 @@ struct ath10k_pci {
* interrupts.
*/
int num_msi_intrs;
+ bool intr_started;
struct tasklet_struct intr_tq;
struct tasklet_struct msi_fw_err;
--
1.7.9.5
^ permalink raw reply related
* RE: [PATCH] mwifiex: fix IRQ enable/disable
From: Bing Zhao @ 2013-07-18 8:03 UTC (permalink / raw)
To: Daniel Drake, linville@tuxdriver.com, Amitkumar Karwar
Cc: linux-wireless@vger.kernel.org
In-Reply-To: <20130713145710.BC47D12647A@dev.laptop.org>
Hi Daniel,
Thanks for the patch.
> During tear down (e.g. mwifiex_sdio_remove during system suspend),
> mwifiex left IRQs enabled for a significant period of time when it was unable
> to handle them correctly. This caused interrupt storms and interfered with
> the bluetooth interface on the same SDIO card.
>
> Solve this by disabling interrupts at the point when they can no longer be
> handled correctly, which is at the start of mwifiex_remove_card().
>
> For cleanliness, we now enable interrupts in the mwifiex_add_card() path, to
> be symmetrical with the disabling of interrupts. We also couple the
> registration of the sdio IRQ handler with the actual enable/disable of
> interrupts at the hardware level.
>
> I also removed a write to this register in mwifiex_init_sdio which seemed
> pointless and won't cause any ill effects now that we only register the SDIO
> IRQ handler when we are ready to accept interrupts.
>
> Includes some corrections from Amitkumar Karwar.
>
> Signed-off-by: Daniel Drake <dsd@laptop.org>
Acked-by: Bing Zhao <bzhao@marvell.com>
Regards,
Bing
> ---
> drivers/net/wireless/mwifiex/init.c | 10 +---
> drivers/net/wireless/mwifiex/main.c | 13 +++++-
> drivers/net/wireless/mwifiex/main.h | 1 +
> drivers/net/wireless/mwifiex/sdio.c | 91 +++++++++++++++++----------------
> ----
> drivers/net/wireless/mwifiex/sdio.h | 3 --
> 5 files changed, 57 insertions(+), 61 deletions(-)
>
> Replaces the previous patch:
> mwifiex: don't ignore SDIO interrupts during shutdown
^ permalink raw reply
* Re: [BUG] 3.10 regression: hang on suspend
From: Stanislaw Gruszka @ 2013-07-18 10:55 UTC (permalink / raw)
To: Ortwin Glück; +Cc: Arend van Spriel, linux-kernel, linux-wireless
In-Reply-To: <51E6E1AB.5010300@odi.ch>
On Wed, Jul 17, 2013 at 08:25:47PM +0200, Ortwin Glück wrote:
> On 07/17/2013 02:29 PM, Stanislaw Gruszka wrote:
> >This looks like livelock
>
> OK got it. Just a GPF in the suspend path, not a livelock
> fortunately. With no_console_suspend the trace appears. Attached is
> a screenshot, transcription for your convenience is here:
>
> NULL pointer deref at iwlagn_mac_remove_interface+0x43/0x120
Unfortunately I still don't know why this happen. Please do
objdump -r -d --prefix-addresses net/mac80211/mac80211.ko > mac80211.txt
objdump -r -d --prefix-addresses drivers/net/wireless/iwlwifi/dvm/iwldvm.ko > iwldvm.txt
and send me mac80211.txt & iwldvm.txt files.
Thanks
Stanislaw
^ permalink raw reply
* USB drivers supporting master mode with large number of stations
From: Matt Foster @ 2013-07-18 12:03 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
Hi,
I've been using ath9k_htc happily for a while for low density access points. However I've recently bumped into the 8 stations limitation.
Tweaking the firmware & macros in the kernel confirm that 8 is probably the limit as "bad things" happen much past this. I suppose if my coding was up to it stripping out all the crypto and just having open network support might free up enough memory in the firmware to up max stations - but it's not, at least not without some guidance.
Of course there are always commercial APs available, however I'm looking for something that can feature as a full distro with at a total minimum OpenVPN and 3G dongle support for remote mgt.
My platforms are embedded, so PCI based cards are not an option.
Are there any USB based drivers out there that support more than 8 stations in master mode?
I suppose I'd also be possibly partially happy with an AP with a proper distro on it subject to the 3G/OpenVPN requirements, and the ability to run my own coded captive portal, iptables for quota support etc
Maybe OpenWRT does what I want, it's a very long time since I looked at that.
Any suggestions more than welcome
Thanks
Matt
^ permalink raw reply
* Re: [PATCH V2] brcmsmac: Fix WARNING caused by lack of calls to dma_mapping_error()
From: John W. Linville @ 2013-07-18 19:59 UTC (permalink / raw)
To: Arend van Spriel
Cc: Larry Finger, linux-wireless, netdev, Stable, Brett Rudley,
Franky (Zhenhui) Lin, Hante Meuleman, brcm80211-dev-list
In-Reply-To: <51D33DB9.6020508@broadcom.com>
On Tue, Jul 02, 2013 at 10:53:13PM +0200, Arend van Spriel wrote:
> On 07/02/2013 06:06 PM, Larry Finger wrote:
> >The driver fails to check the results of DMA mapping in twp places, which results
> >in the following warning:
> >
> >[ 28.078515] ------------[ cut here ]------------
> >[ 28.078529] WARNING: at lib/dma-debug.c:937 check_unmap+0x47e/0x930()
> >[ 28.078533] bcma-pci-bridge 0000:0e:00.0: DMA-API: device driver failed to check map error[device address=0x00000000b5d60d6c] [size=1876 bytes] [mapped as
> > single]
> >[ 28.078536] Modules linked in: bnep bluetooth vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) ipv6 b43 brcmsmac rtl8192cu rtl8192c_common rtlwifi mac802
> >11 brcmutil cfg80211 snd_hda_codec_conexant rng_core snd_hda_intel kvm_amd snd_hda_codec ssb kvm mmc_core snd_pcm snd_seq snd_timer snd_seq_device snd k8temp
> > cordic joydev serio_raw hwmon sr_mod sg pcmcia pcmcia_core soundcore cdrom i2c_nforce2 i2c_core forcedeth bcma snd_page_alloc autofs4 ext4 jbd2 mbcache crc1
> >6 scsi_dh_alua scsi_dh_hp_sw scsi_dh_rdac scsi_dh_emc scsi_dh ata_generic pata_amd
> >[ 28.078602] CPU: 1 PID: 2570 Comm: NetworkManager Tainted: G O 3.10.0-rc7-wl+ #42
> >[ 28.078605] Hardware name: Hewlett-Packard HP Pavilion dv2700 Notebook PC/30D6, BIOS F.27 11/27/2008
> >[ 28.078607] 0000000000000009 ffff8800bbb03ad8 ffffffff8144f898 ffff8800bbb03b18
> >[ 28.078612] ffffffff8103e1eb 0000000000000002 ffff8800b719f480 ffff8800b7b9c010
> >[ 28.078617] ffffffff824204c0 ffffffff81754d57 0000000000000754 ffff8800bbb03b78
> >[ 28.078622] Call Trace:
> >[ 28.078624] <IRQ> [<ffffffff8144f898>] dump_stack+0x19/0x1b
> >[ 28.078634] [<ffffffff8103e1eb>] warn_slowpath_common+0x6b/0xa0
> >[ 28.078638] [<ffffffff8103e2c1>] warn_slowpath_fmt+0x41/0x50
> >[ 28.078650] [<ffffffff8122d7ae>] check_unmap+0x47e/0x930
> >[ 28.078655] [<ffffffff8122de4c>] debug_dma_unmap_page+0x5c/0x70
> >[ 28.078679] [<ffffffffa04a808c>] dma64_getnextrxp+0x10c/0x190 [brcmsmac]
> >[ 28.078691] [<ffffffffa04a9042>] dma_rx+0x62/0x240 [brcmsmac]
> >[ 28.078707] [<ffffffffa0479101>] brcms_c_dpc+0x211/0x9d0 [brcmsmac]
> >[ 28.078717] [<ffffffffa046d927>] ? brcms_dpc+0x27/0xf0 [brcmsmac]
> >[ 28.078731] [<ffffffffa046d947>] brcms_dpc+0x47/0xf0 [brcmsmac]
> >[ 28.078736] [<ffffffff81047dcc>] tasklet_action+0x6c/0xf0
> >--snip--
> >[ 28.078974] [<ffffffff813891bd>] SyS_sendmsg+0xd/0x20
> >[ 28.078979] [<ffffffff81455c24>] tracesys+0xdd/0xe2
> >[ 28.078982] ---[ end trace 6164d1a08148e9c8 ]---
> >[ 28.078984] Mapped at:
> >[ 28.078985] [<ffffffff8122c8fd>] debug_dma_map_page+0x9d/0x150
> >[ 28.078989] [<ffffffffa04a9322>] dma_rxfill+0x102/0x3d0 [brcmsmac]
> >[ 28.079001] [<ffffffffa047a13d>] brcms_c_init+0x87d/0x1100 [brcmsmac]
> >[ 28.079010] [<ffffffffa046d851>] brcms_init+0x21/0x30 [brcmsmac]
> >[ 28.079018] [<ffffffffa04786e0>] brcms_c_up+0x150/0x430 [brcmsmac]
> >
> >As the patch adds a new failure mechanism to dma_rxfill(). When I changed the
> >comment at the start of the routine to add that information, I also polished
> >the wording.
> >
> >Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> >Cc: Stable <stable@vger.kernel.org>
> >Cc: Brett Rudley <brudley@broadcom.com>
> >Cc: Arend van Spriel <arend@broadcom.com>
> >Cc: Franky (Zhenhui) Lin <frankyl@broadcom.com>
> >Cc: Hante Meuleman <meuleman@broadcom.com>
> >Cc: brcm80211-dev-list@broadcom.com
> >---
> >
> >V2 - fixed two patch errors.
>
> Hi Larry,
>
> Are you planning to do a V3, ie. address my review comments sent
> earlier today? I can resend them if needed.
>
> Regards,
> Arend
Is there going to be a V3?
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH V2] brcmsmac: Fix WARNING caused by lack of calls to dma_mapping_error()
From: Arend van Spriel @ 2013-07-18 20:41 UTC (permalink / raw)
To: John W. Linville
Cc: Larry Finger, linux-wireless, netdev, Stable, Brett Rudley,
Franky (Zhenhui) Lin, Hante Meuleman, brcm80211-dev-list
In-Reply-To: <20130718195933.GA9123@tuxdriver.com>
On 07/18/2013 09:59 PM, John W. Linville wrote:
> On Tue, Jul 02, 2013 at 10:53:13PM +0200, Arend van Spriel wrote:
>> On 07/02/2013 06:06 PM, Larry Finger wrote:
>>> The driver fails to check the results of DMA mapping in twp places, which results
>>> in the following warning:
>>>
>>> [ 28.078515] ------------[ cut here ]------------
>>> [ 28.078529] WARNING: at lib/dma-debug.c:937 check_unmap+0x47e/0x930()
>>> [ 28.078533] bcma-pci-bridge 0000:0e:00.0: DMA-API: device driver failed to check map error[device address=0x00000000b5d60d6c] [size=1876 bytes] [mapped as
>>> single]
>>> [ 28.078536] Modules linked in: bnep bluetooth vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) ipv6 b43 brcmsmac rtl8192cu rtl8192c_common rtlwifi mac802
>>> 11 brcmutil cfg80211 snd_hda_codec_conexant rng_core snd_hda_intel kvm_amd snd_hda_codec ssb kvm mmc_core snd_pcm snd_seq snd_timer snd_seq_device snd k8temp
>>> cordic joydev serio_raw hwmon sr_mod sg pcmcia pcmcia_core soundcore cdrom i2c_nforce2 i2c_core forcedeth bcma snd_page_alloc autofs4 ext4 jbd2 mbcache crc1
>>> 6 scsi_dh_alua scsi_dh_hp_sw scsi_dh_rdac scsi_dh_emc scsi_dh ata_generic pata_amd
>>> [ 28.078602] CPU: 1 PID: 2570 Comm: NetworkManager Tainted: G O 3.10.0-rc7-wl+ #42
>>> [ 28.078605] Hardware name: Hewlett-Packard HP Pavilion dv2700 Notebook PC/30D6, BIOS F.27 11/27/2008
>>> [ 28.078607] 0000000000000009 ffff8800bbb03ad8 ffffffff8144f898 ffff8800bbb03b18
>>> [ 28.078612] ffffffff8103e1eb 0000000000000002 ffff8800b719f480 ffff8800b7b9c010
>>> [ 28.078617] ffffffff824204c0 ffffffff81754d57 0000000000000754 ffff8800bbb03b78
>>> [ 28.078622] Call Trace:
>>> [ 28.078624] <IRQ> [<ffffffff8144f898>] dump_stack+0x19/0x1b
>>> [ 28.078634] [<ffffffff8103e1eb>] warn_slowpath_common+0x6b/0xa0
>>> [ 28.078638] [<ffffffff8103e2c1>] warn_slowpath_fmt+0x41/0x50
>>> [ 28.078650] [<ffffffff8122d7ae>] check_unmap+0x47e/0x930
>>> [ 28.078655] [<ffffffff8122de4c>] debug_dma_unmap_page+0x5c/0x70
>>> [ 28.078679] [<ffffffffa04a808c>] dma64_getnextrxp+0x10c/0x190 [brcmsmac]
>>> [ 28.078691] [<ffffffffa04a9042>] dma_rx+0x62/0x240 [brcmsmac]
>>> [ 28.078707] [<ffffffffa0479101>] brcms_c_dpc+0x211/0x9d0 [brcmsmac]
>>> [ 28.078717] [<ffffffffa046d927>] ? brcms_dpc+0x27/0xf0 [brcmsmac]
>>> [ 28.078731] [<ffffffffa046d947>] brcms_dpc+0x47/0xf0 [brcmsmac]
>>> [ 28.078736] [<ffffffff81047dcc>] tasklet_action+0x6c/0xf0
>>> --snip--
>>> [ 28.078974] [<ffffffff813891bd>] SyS_sendmsg+0xd/0x20
>>> [ 28.078979] [<ffffffff81455c24>] tracesys+0xdd/0xe2
>>> [ 28.078982] ---[ end trace 6164d1a08148e9c8 ]---
>>> [ 28.078984] Mapped at:
>>> [ 28.078985] [<ffffffff8122c8fd>] debug_dma_map_page+0x9d/0x150
>>> [ 28.078989] [<ffffffffa04a9322>] dma_rxfill+0x102/0x3d0 [brcmsmac]
>>> [ 28.079001] [<ffffffffa047a13d>] brcms_c_init+0x87d/0x1100 [brcmsmac]
>>> [ 28.079010] [<ffffffffa046d851>] brcms_init+0x21/0x30 [brcmsmac]
>>> [ 28.079018] [<ffffffffa04786e0>] brcms_c_up+0x150/0x430 [brcmsmac]
>>>
>>> As the patch adds a new failure mechanism to dma_rxfill(). When I changed the
>>> comment at the start of the routine to add that information, I also polished
>>> the wording.
>>>
>>> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
>>> Cc: Stable <stable@vger.kernel.org>
>>> Cc: Brett Rudley <brudley@broadcom.com>
>>> Cc: Arend van Spriel <arend@broadcom.com>
>>> Cc: Franky (Zhenhui) Lin <frankyl@broadcom.com>
>>> Cc: Hante Meuleman <meuleman@broadcom.com>
>>> Cc: brcm80211-dev-list@broadcom.com
>>> ---
>>>
>>> V2 - fixed two patch errors.
>>
>> Hi Larry,
>>
>> Are you planning to do a V3, ie. address my review comments sent
>> earlier today? I can resend them if needed.
>>
>> Regards,
>> Arend
>
> Is there going to be a V3?
>
Hi Larry
Do you want me to take this one of your shoulder and have a shot at it?
Regards,
Arend
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox