linux.git/net/wireless/reg.c, branch v2.6.38

cfg80211: fix transposition of words in printk

2011-01-04T19:43:01+00:00

Fixes the misplaced article in the following:

"cfg80211: Updating information on frequency 5785 MHz for
    20 a MHz width channel with regulatory rule:"

Signed-off-by: Bob Copeland 
Signed-off-by: John W. Linville

cfg80211: fix null pointer dereference with a custom regulatory request

2010-12-16T20:22:31+00:00

Once we moved the core regulatory request to the queue and let
the scheduler process it last_request will have been left NULL
until the schedular decides to process the first request. When
this happens and we are loading a driver with a custom regulatory
request like all Atheros drivers we end up with a NULL pointer
dereference. We fix this by checking if the request was a
custom one.

BUG: unable to handle kernel NULL pointer dereference at 0000000000000004
IP: [] freq_reg_info_regd.clone.2+0x27/0x130 [cfg80211]
PGD 71f91067 PUD 712b2067 PMD 0
Oops: 0000 [#1] PREEMPT SMP
last sysfs file: /sys/devices/pci0000:00/0000:00:1d.7/usb2/2-1/firmware/2-1/loading
CPU 0
Modules linked in: ath9k_htc(+) ath9k_common ath9k_hw ath 
Pid: 3094, comm: insmod Tainted: G        W   2.6.37-rc5-wl #16 INVALID/28427ZQ
RIP: 0010:[]  [] freq_reg_info_regd.clone.2+0x27/0x130 [cfg80211]
RSP: 0018:ffff88007045db78  EFLAGS: 00010282
RAX: 0000000000000000 RBX: ffffffffa047d9a0 RCX: ffff88007045dbd0
RDX: 0000000000004e20 RSI: 000000000024cde0 RDI: ffff8800700483e0
RBP: ffff88007045db98 R08: ffffffffa02f5b40 R09: 0000000000000001
R10: 000000000000000e R11: 0000000000000001 R12: 0000000000000000
R13: ffff88007004e3b0 R14: 0000000000000000 R15: ffff880070048340
FS:  00007f635a707700(0000) GS:ffff880077400000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000004 CR3: 00000000708a9000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process insmod (pid: 3094, threadinfo ffff88007045c000, task ffff8800713e3ec0)
Stack:
 ffffffffa047d9a0 0000000000000000 ffff88007004e3b0 0000000000000000
 ffff88007045dc08 ffffffffa016e147 000000007045dc08 0000000000000002
 ffff8800700483e0 ffffffffa02f5b40 ffff88007045dbd8 0000000000000000
Call Trace:
 [] wiphy_apply_custom_regulatory+0x137/0x1d0 [cfg80211]
 [] ? ath9k_reg_notifier+0x0/0x50 [ath9k_htc]
 [] ath_regd_init+0x347/0x430 [ath]
 [] ath9k_htc_probe_device+0x6c5/0x960 [ath9k_htc]
 [] ath9k_htc_hw_init+0xc/0x30 [ath9k_htc]
 [] ath9k_hif_usb_probe+0x216/0x3b0 [ath9k_htc]
 [] usb_probe_interface+0x10c/0x210 [usbcore]
 [] driver_probe_device+0x96/0x1c0
 [] __driver_attach+0xa3/0xb0
 [] ? __driver_attach+0x0/0xb0
 [] bus_for_each_dev+0x5e/0x90
 [] driver_attach+0x19/0x20
 [] bus_add_driver+0x168/0x320
 [] driver_register+0x71/0x140
 [] ? __raw_spin_lock_init+0x38/0x70
 [] usb_register_driver+0xdc/0x190 [usbcore]
 [] ? ath9k_htc_init+0x0/0x4f [ath9k_htc]
 [] ath9k_hif_usb_init+0x1e/0x20 [ath9k_htc]
 [] ath9k_htc_init+0x2b/0x4f [ath9k_htc]
 [] do_one_initcall+0x3f/0x180
 [] sys_init_module+0xbb/0x200
 [] system_call_fastpath+0x16/0x1b
Code: 
RIP  [] freq_reg_info_regd.clone.2+0x27/0x130 [cfg80211]
 RSP 
CR2: 0000000000000004
---[ end trace 79e4193601c8b713 ]---

Reported-by: Sujith Manoharan 
Signed-off-by: Luis R. Rodriguez 
Signed-off-by: John W. Linville

net/wireless: Use pr_ and netdev_

2010-11-24T21:19:33+00:00

No change in output for pr_ prefixes.
netdev_ output is different, arguably improved.

Signed-off-by: Joe Perches 
Signed-off-by: John W. Linville

cfg80211: Fix regulatory bug with multiple cards and delays

2010-11-22T20:48:51+00:00

When two cards are connected with the same regulatory domain
if CRDA had a delayed response then cfg80211's own set regulatory
domain would still be the world regulatory domain. There was a bug
on cfg80211's logic such that it assumed that once you pegged a
request as the last request it was already the currently set
regulatory domain. This would mean we would race setting a stale
regulatory domain to secondary cards which had the same regulatory
domain since the alpha2 would match.

We fix this by processing each regulatory request atomically,
and only move on to the next one once we get it fully processed.
In the case CRDA is not present we will simply world roam.

This issue is only present when you have a slow system and the
CRDA processing is delayed. Because of this it is not a known
regression.

Without this fix when a delay is present with CRDA the second card
would end up with an intersected regulatory domain and not allow it
to use the channels it really is designed for. When two cards with
two different regulatory domains were inserted you'd end up
rejecting the second card's regulatory domain request.
This fails with mac80211_hswim's regtest=2 (two requests, same alpha2)
and regtest=3 (two requests, different alpha2) module parameter
options.

This was reproduced and tested against mac80211_hwsim using this
CRDA delayer:

       #!/bin/bash
       echo $COUNTRY >> /tmp/log
       sleep 2
       /sbin/crda.orig

And these regulatory tests:

       modprobe mac80211_hwsim regtest=2
       modprobe mac80211_hwsim regtest=3

Reported-by: Mark Mentovai 
Signed-off-by: Luis R. Rodriguez 
Tested-by: Mark Mentovai 
Tested-by: Bruno Randolf 
Signed-off-by: John W. Linville

cfg80211: move mutex locking to reg_process_pending_hints()

2010-11-22T20:48:50+00:00

This will be required in the next patch and it makes the
next patch easier to review.

Signed-off-by: Luis R. Rodriguez 
Tested-by: Mark Mentovai 
Tested-by: Bruno Randolf 
Signed-off-by: John W. Linville

cfg80211: move reg_work and reg_todo above

2010-11-22T20:48:50+00:00

These will be used earlier in the next few patches.

Signed-off-by: Luis R. Rodriguez 
Tested-by: Mark Mentovai 
Tested-by: Bruno Randolf 
Signed-off-by: John W. Linville

cfg80211: put core regulatory request into queue

2010-11-22T20:48:50+00:00

This will simplify the synchronization for pending requests.
Without this we have a race between the core and when we
restore regulatory settings, although this is unlikely
its best to just avoid that race altogether.

Signed-off-by: Luis R. Rodriguez 
Tested-by: Mark Mentovai 
Tested-by: Bruno Randolf 
Signed-off-by: John W. Linville

cfg80211: prefix REG_DBG_PRINT() with cfg80211

2010-11-15T18:24:15+00:00

Everyone's doing it, its the cool thing.

Cc: Easwar Krishnan 
Signed-off-by: Luis R. Rodriguez 
Signed-off-by: John W. Linville

cfg80211: add debug print when processing a channel

2010-11-15T18:24:14+00:00

In the worst case you are seeing really odd things you want
more information than what is provided right now, for those
that insist and want debug info through CONFIG_CFG80211_REG_DEBUG
provide a print of when we are processing a channel and with what
regulatory rule.

Cc: Easwar Krishnan 
Signed-off-by: Luis R. Rodriguez 
Signed-off-by: Senthil Balasubramanian 
Signed-off-by: John W. Linville

cfg80211: add debug print when disabling a channel on a custom regd

2010-11-15T18:24:13+00:00

Cc: Easwar Krishnan 
Signed-off-by: Luis R. Rodriguez 
Signed-off-by: John W. Linville