linux-toradex.git/net/wireless/reg.c, branch v3.4.34

wireless: allow 40 MHz on world roaming channels 12/13

2012-11-26T19:37:46+00:00

commit 43c771a1963ab461a2f194e3c97fded1d5fe262f upstream.

When in world roaming mode, allow 40 MHz to be used
on channels 12 and 13 so that an AP that is, e.g.,
using HT40+ on channel 9 (in the UK) can be used.

Reported-by: Eddie Chapman 
Tested-by: Eddie Chapman 
Acked-by: Luis R. Rodriguez 
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman

cfg80211: fix possible circular lock on reg_regdb_search()

2012-10-02T17:30:09+00:00

commit a85d0d7f3460b1a123b78e7f7e39bf72c37dfb78 upstream.

When call_crda() is called we kick off a witch hunt search
for the same regulatory domain on our internal regulatory
database and that work gets kicked off on a workqueue, this
is done while the cfg80211_mutex is held. If that workqueue
kicks off it will first lock reg_regdb_search_mutex and
later cfg80211_mutex but to ensure two CPUs will not contend
against cfg80211_mutex the right thing to do is to have the
reg_regdb_search() wait until the cfg80211_mutex is let go.

The lockdep report is pasted below.

cfg80211: Calling CRDA to update world regulatory domain

======================================================
[ INFO: possible circular locking dependency detected ]
3.3.8 #3 Tainted: G           O
-------------------------------------------------------
kworker/0:1/235 is trying to acquire lock:
 (cfg80211_mutex){+.+...}, at: [<816468a4>] set_regdom+0x78c/0x808 [cfg80211]

but task is already holding lock:
 (reg_regdb_search_mutex){+.+...}, at: [<81646828>] set_regdom+0x710/0x808 [cfg80211]

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #2 (reg_regdb_search_mutex){+.+...}:
       [<800a8384>] lock_acquire+0x60/0x88
       [<802950a8>] mutex_lock_nested+0x54/0x31c
       [<81645778>] is_world_regdom+0x9f8/0xc74 [cfg80211]

-> #1 (reg_mutex#2){+.+...}:
       [<800a8384>] lock_acquire+0x60/0x88
       [<802950a8>] mutex_lock_nested+0x54/0x31c
       [<8164539c>] is_world_regdom+0x61c/0xc74 [cfg80211]

-> #0 (cfg80211_mutex){+.+...}:
       [<800a77b8>] __lock_acquire+0x10d4/0x17bc
       [<800a8384>] lock_acquire+0x60/0x88
       [<802950a8>] mutex_lock_nested+0x54/0x31c
       [<816468a4>] set_regdom+0x78c/0x808 [cfg80211]

other info that might help us debug this:

Chain exists of:
  cfg80211_mutex --> reg_mutex#2 --> reg_regdb_search_mutex

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(reg_regdb_search_mutex);
                               lock(reg_mutex#2);
                               lock(reg_regdb_search_mutex);
  lock(cfg80211_mutex);

 *** DEADLOCK ***

3 locks held by kworker/0:1/235:
 #0:  (events){.+.+..}, at: [<80089a00>] process_one_work+0x230/0x460
 #1:  (reg_regdb_work){+.+...}, at: [<80089a00>] process_one_work+0x230/0x460
 #2:  (reg_regdb_search_mutex){+.+...}, at: [<81646828>] set_regdom+0x710/0x808 [cfg80211]

stack backtrace:
Call Trace:
[<80290fd4>] dump_stack+0x8/0x34
[<80291bc4>] print_circular_bug+0x2ac/0x2d8
[<800a77b8>] __lock_acquire+0x10d4/0x17bc
[<800a8384>] lock_acquire+0x60/0x88
[<802950a8>] mutex_lock_nested+0x54/0x31c
[<816468a4>] set_regdom+0x78c/0x808 [cfg80211]

Reported-by: Felix Fietkau 
Tested-by: Felix Fietkau 
Signed-off-by: Luis R. Rodriguez 
Reviewed-by: Johannes Berg 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

wireless: reg: restore previous behaviour of chan->max_power calculations

2012-08-15T15:10:10+00:00

commit 5e31fc0815a4e2c72b1b495fe7a0d8f9bfb9e4b4 upstream.

commit eccc068e8e84c8fe997115629925e0422a98e4de
Author: Hong Wu 
Date:   Wed Jan 11 20:33:39 2012 +0200

    wireless: Save original maximum regulatory transmission power for the calucation of the local maximum transmit pow

changed the way we calculate chan->max_power as min(chan->max_power,
chan->max_reg_power). That broke rt2x00 (and perhaps some other
drivers) that do not set chan->max_power. It is not so easy to fix this
problem correctly in rt2x00.

According to commit eccc068e8 changelog, change claim only to save
maximum regulatory power - changing setting of chan->max_power was side
effect. This patch restore previous calculations of chan->max_power and
do not touch chan->max_reg_power.

Signed-off-by: Stanislaw Gruszka 
Acked-by: Luis R. Rodriguez 
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman

cfg80211: fix potential deadlock in regulatory

2012-07-16T16:04:11+00:00

commit fe20b39ec32e975f1054c0b7866c873a954adf05 upstream.

reg_timeout_work() calls restore_regulatory_settings() which
takes cfg80211_mutex.

reg_set_request_processed() already holds cfg80211_mutex
before calling cancel_delayed_work_sync(reg_timeout),
so it might deadlock.

Call the async cancel_delayed_work instead, in order
to avoid the potential deadlock.

This is the relevant lockdep warning:

cfg80211: Calling CRDA for country: XX

======================================================
[ INFO: possible circular locking dependency detected ]
3.4.0-rc5-wl+ #26 Not tainted
-------------------------------------------------------
kworker/0:2/1391 is trying to acquire lock:
 (cfg80211_mutex){+.+.+.}, at: [] restore_regulatory_settings+0x34/0x418 [cfg80211]

but task is already holding lock:
 ((reg_timeout).work){+.+...}, at: [] process_one_work+0x1f0/0x480

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #2 ((reg_timeout).work){+.+...}:
       [] validate_chain+0xb94/0x10f0
       [] __lock_acquire+0x8c8/0x9b0
       [] lock_acquire+0xf0/0x114
       [] wait_on_work+0x4c/0x154
       [] __cancel_work_timer+0xd4/0x11c
       [] cancel_delayed_work_sync+0x1c/0x20
       [] reg_set_request_processed+0x50/0x78 [cfg80211]
       [] set_regdom+0x550/0x600 [cfg80211]
       [] nl80211_set_reg+0x218/0x258 [cfg80211]
       [] genl_rcv_msg+0x1a8/0x1e8
       [] netlink_rcv_skb+0x5c/0xc0
       [] genl_rcv+0x28/0x34
       [] netlink_unicast+0x15c/0x228
       [] netlink_sendmsg+0x218/0x298
       [] sock_sendmsg+0xa4/0xc0
       [] __sys_sendmsg+0x1e4/0x268
       [] sys_sendmsg+0x4c/0x70
       [] ret_fast_syscall+0x0/0x3c

-> #1 (reg_mutex){+.+.+.}:
       [] validate_chain+0xb94/0x10f0
       [] __lock_acquire+0x8c8/0x9b0
       [] lock_acquire+0xf0/0x114
       [] mutex_lock_nested+0x48/0x320
       [] reg_todo+0x30/0x538 [cfg80211]
       [] process_one_work+0x2a0/0x480
       [] worker_thread+0x1bc/0x2bc
       [] kthread+0x98/0xa4
       [] kernel_thread_exit+0x0/0x8

-> #0 (cfg80211_mutex){+.+.+.}:
       [] print_circular_bug+0x68/0x2cc
       [] validate_chain+0x978/0x10f0
       [] __lock_acquire+0x8c8/0x9b0
       [] lock_acquire+0xf0/0x114
       [] mutex_lock_nested+0x48/0x320
       [] restore_regulatory_settings+0x34/0x418 [cfg80211]
       [] reg_timeout_work+0x1c/0x20 [cfg80211]
       [] process_one_work+0x2a0/0x480
       [] worker_thread+0x1bc/0x2bc
       [] kthread+0x98/0xa4
       [] kernel_thread_exit+0x0/0x8

other info that might help us debug this:

Chain exists of:
  cfg80211_mutex --> reg_mutex --> (reg_timeout).work

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock((reg_timeout).work);
                               lock(reg_mutex);
                               lock((reg_timeout).work);
  lock(cfg80211_mutex);

 *** DEADLOCK ***

2 locks held by kworker/0:2/1391:
 #0:  (events){.+.+.+}, at: [] process_one_work+0x1f0/0x480
 #1:  ((reg_timeout).work){+.+...}, at: [] process_one_work+0x1f0/0x480

stack backtrace:
[] (unwind_backtrace+0x0/0x12c) from [] (dump_stack+0x20/0x24)
[] (dump_stack+0x20/0x24) from [] (print_circular_bug+0x280/0x2cc)
[] (print_circular_bug+0x280/0x2cc) from [] (validate_chain+0x978/0x10f0)
[] (validate_chain+0x978/0x10f0) from [] (__lock_acquire+0x8c8/0x9b0)
[] (__lock_acquire+0x8c8/0x9b0) from [] (lock_acquire+0xf0/0x114)
[] (lock_acquire+0xf0/0x114) from [] (mutex_lock_nested+0x48/0x320)
[] (mutex_lock_nested+0x48/0x320) from [] (restore_regulatory_settings+0x34/0x418 [cfg80211])
[] (restore_regulatory_settings+0x34/0x418 [cfg80211]) from [] (reg_timeout_work+0x1c/0x20 [cfg80211])
[] (reg_timeout_work+0x1c/0x20 [cfg80211]) from [] (process_one_work+0x2a0/0x480)
[] (process_one_work+0x2a0/0x480) from [] (worker_thread+0x1bc/0x2bc)
[] (worker_thread+0x1bc/0x2bc) from [] (kthread+0x98/0xa4)
[] (kthread+0x98/0xa4) from [] (kernel_thread_exit+0x0/0x8)
cfg80211: Calling CRDA to update world regulatory domain
cfg80211: World regulatory domain updated:
cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
cfg80211:   (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
cfg80211:   (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
cfg80211:   (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
cfg80211:   (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
cfg80211:   (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)

Signed-off-by: Eliad Peller 
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman

cfg80211: warn if db.txt is empty with CONFIG_CFG80211_INTERNAL_REGDB

2012-06-01T07:18:14+00:00

commit 80007efeff0568375b08faf93c7aad65602cb97e upstream.

It has happened twice now where elaborate troubleshooting has
undergone on systems where CONFIG_CFG80211_INTERNAL_REGDB [0]
has been set but yet net/wireless/db.txt was not updated.

Despite the documentation on this it seems system integrators could
use some more help with this, so throw out a kernel warning at boot time
when their database is empty.

This does mean that the error-prone system integrator won't likely
realize the issue until they boot the machine but -- it does not seem
to make sense to enable a build bug breaking random build testing.

[0] http://wireless.kernel.org/en/developers/Regulatory/CRDA#CONFIG_CFG80211_INTERNAL_REGDB

Cc: Stephen Rothwell 
Cc: Youngsin Lee 
Cc: Raja Mani 
Cc: Senthil Kumar Balasubramanian 
Cc: Vipin Mehta 
Cc: yahuan@qca.qualcomm.com
Cc: jjan@qca.qualcomm.com
Cc: vthiagar@qca.qualcomm.com
Cc: henrykim@qualcomm.com
Cc: jouni@qca.qualcomm.com
Cc: athiruve@qca.qualcomm.com
Cc: cjkim@qualcomm.com
Cc: philipk@qca.qualcomm.com
Cc: sunnykim@qualcomm.com
Cc: sskwak@qualcomm.com
Cc: kkim@qualcomm.com
Cc: mattbyun@qualcomm.com
Cc: ryanlee@qualcomm.com
Cc: simbap@qualcomm.com
Cc: krislee@qualcomm.com
Cc: conner@qualcomm.com
Cc: hojinkim@qualcomm.com
Cc: honglee@qualcomm.com
Cc: johnwkim@qualcomm.com
Cc: jinyong@qca.qualcomm.com
Signed-off-by: Luis R. Rodriguez 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

wireless: Save original maximum regulatory transmission power for the calucation of the local maximum transmit power

2012-01-24T19:16:54+00:00

The local maximum transmit power is the maximum power a wireless device
allowed to transmit. If Power Constraint is presented, the local maximum
power equals to the maximum allowed power defined in regulatory domain
minus power constraint.

The maximum transmit power is maximum power a wireless device capable of
transmitting, and should be used in Power Capability element (7.3.2.16
IEEE802.11 2007).

The transmit power from a wireless device should not greater than the
local maximum transmit power.

The maximum transmit power was not calculated correctly in the current
Linux wireless/mac80211 when Power Constraint is presented.

Signed-off-by: Hong Wu 
Signed-off-by: John W. Linville

cfg80211: relicense reg.c reg.h and genregdb.awk to ISC

2012-01-04T19:30:41+00:00

Following the tradition we have had with ath5k, ath9k, CRDA,
wireless-regdb I'd like to license this code under the permissive ISC
license for the code sharing purposes with other OSes, it'd sure be nice
to help the landscape in this area. Although I am %82.89 owner of the
regulatory code I have asked every contributor to the regulatory code
and have receieved positive Acked-bys from everyone except two deceased
entities:

 o Frans Pop RIP 2010 [0]
	- Frans Pop 
	- Frans Pop 
 o Nokia     RIP February, 11, 2011 [1], [2]
	- ext-yuri.ershov@nokia.com
	- kalle.valo@nokia.com

Frans Pop's contribution was a simple patch 55f98938, titled,
"wireless: remove trailing space in messages" which just add a \n
to some printk lines. I'm going to treat these additions as
uncopyrightable.

As for the contributions made by employees on behalf of Nokia
my contact point was Petri Karhula  but
after one month he noted he had not been able to get traction from the
legal department on this request, as such it I proceeded by replacing
their contributions in previous patches.

The end goal is to help a clean rewrite that starts in userspace
that is shared under ISC license which currently is taking place with
the regulatory simulator [3].

[0] http://lists.debian.org/debian-devel/2011/12/msg00263.html
[1] http://press.nokia.com/2011/02/11/nokia-outlines-new-strategy-introduces-new-leadership-operational-structure/
[2] http://NokiaPlanB.com
[3] git://github.com/mcgrof/regsim.git

Acked-by: Thadeu Lima de Souza Cascardo 
Acked-by: Dan Carpenter 
Acked-by: Mihai Moldovan 
Acked-by: Uwe Kleine-König 
Acked-by: Sven Neumann 
Acked-by: Johannes Berg 
Acked-by: Tomas Winkler 
Acked-by: Tony Vroon 
Acked-by: Pavel Roskin 
Acked-by: Bob Copeland 
Acked-by: Lucas De Marchi 
Acked-by: Pat Erley 
Acked-by: Tejun Heo 
Acked-by: John W. Linville 
Acked-by: Chris Wright 
Acked-by: Joe Perches 
Acked-by: Paul Gortmaker 
Acked-by: John Gordon 
Acked-by: Simon Barber 
Acked-by: Rajkumar Manoharan 
Acked-by: Jiri Benc 
Acked-by: Bruno Randolf 
Acked-by: Scott James Remnant 
Acked-by: Roel Kluin 
Signed-off-by: Luis R. Rodriguez 
Signed-off-by: John W. Linville

cfg80211: replace reg.c Nokia commit 269ac5

2012-01-04T19:30:40+00:00

Nokia hasn't gotten back to me in over 1 month for a relicense
change request. There are only a few changes that they contributed,
so just reverting their changes but replacing with another set.
This change replaces this commit:

commit 269ac5fd2d75b118d76a2291e28796527db2f3f8
Author: Kalle Valo 
Date:   Tue Dec 1 10:47:15 2009 +0200

    cfg80211: indent regulatory messages with spaces

    The regulatory messages in syslog look weird:

    kernel: cfg80211: Regulatory domain: US
    kernel: ^I(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
    kernel: ^I(2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2700 mBm)
    kernel: ^I(5170000 KHz - 5190000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
    kernel: ^I(5190000 KHz - 5210000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
    kernel: ^I(5210000 KHz - 5230000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
    kernel: ^I(5230000 KHz - 5330000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
    kernel: ^I(5735000 KHz - 5835000 KHz @ 40000 KHz), (600 mBi, 3000 mBm)

    Indent them with four spaces instead of the tab character to get prettier
    output.

    Signed-off-by: Kalle Valo 
    Acked: Luis R. Rodriguez 
    Signed-off-by: John W. Linville 

Cc: Petri Karhula 
Signed-off-by: Luis R. Rodriguez 
Signed-off-by: John W. Linville

cfg80211: replace reg.c Nokia commit c4c32294

2012-01-04T19:30:40+00:00

Nokia hasn't gotten back to me in over 1 month for a relicense
change request. There are only a few changes that they contributed,
so just reverting their changes but replacing with another set.
This change replaces this commit:

commit c4c322941ce0d7e2b7b8794ad70683123d9cb26a
Author: Yuri Ershov 
Date:   Tue Jun 29 15:08:08 2010 +0400

    cfg80211: Update of regulatory request initiator handling

    In some cases there could be possible dereferencing freed pointer. The
    update is intended to avoid this issue.

    Signed-off-by: Yuri Ershov 
    Signed-off-by: John W. Linville 

Cc: Petri Karhula 
Signed-off-by: Luis R. Rodriguez 
Signed-off-by: John W. Linville

wireless: Protect regdomain change by mutex

2012-01-04T19:30:39+00:00

Signed-off-by: Dmitry Shmidt 
Signed-off-by: John W. Linville