- 03 1月, 2013 8 次提交
-
-
由 Johannes Berg 提交于
It would be a major problem if anything were to run concurrently while the module is being unloaded so remove the locking that doesn't help anything. Acked-by: NLuis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
Clean up various things like indentation, extra parentheses, too many/few line breaks, etc. Acked-by: NLuis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
There's no need to unlock before calling queue_regulatory_request(), so simplify the function. Acked-by: NLuis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
There's no need to test whether a list is empty or not before iterating. Acked-by: NLuis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
Use ERR_PTR/IS_ERR to return the result or errors, also do some code cleanups. Acked-by: NLuis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
As the dummy_rule (also renamed from irule) is only used for output by the reg_rules_intersect() function there's no need to clear it at all, remove that. Acked-by: NLuis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
There's no need to allocate one reg rule more than will be used, reduce the allocations. The allocation in nl80211 already doesn't allocate too much space. Acked-by: NLuis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
When intersecting rules, we count first to know how many rules need to be allocated, and then do the intersection into the allocated array. However, the code doing this writes past the end of the array because it attempts to do all intersections. Make it stop when the right number of rules has been reached. Acked-by: NLuis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 30 11月, 2012 1 次提交
-
-
由 Johannes Berg 提交于
When a BSS struct is updated, the IEs are currently overwritten or freed. This can lead to races if some other CPU is accessing the BSS struct and using the IEs concurrently. Fix this by always allocating the IEs in a new struct that holds the data and length and protecting access to this new struct with RCU. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 12 11月, 2012 1 次提交
-
-
由 Johannes Berg 提交于
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. Cc: stable@vger.kernel.org Reported-by: NEddie Chapman <eddie@ehuk.net> Tested-by: NEddie Chapman <eddie@ehuk.net> Acked-by: NLuis R. Rodriguez <mcgrof@qca.qualcomm.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 18 10月, 2012 1 次提交
-
-
由 Felix Fietkau 提交于
A few places touch chan->max_power based on updated tx power rules, but forget to do the same to chan->max_reg_power. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 25 9月, 2012 1 次提交
-
-
由 Vladimir Kondratiev 提交于
The current regulatory code on cfg80211 performs a check to see if a regulatory rule belongs to an IEEE band so that if a Country IE is received and no rules are specified for a band (which is allowed by IEEE) those bands are left intact. The current band check assumes a rule is bound to a band if the rule's start or end frequency is less than 2 GHz apart from the center of frequency being inspected. In order to support 60 GHz for 802.11ad we need to increase this to account for the channel spacing of 2160 MHz whereby a channel somewhere in the middle of a regulatory rule may be more than 2 GHz apart from either the beginning or end of the frequency rule. Without a fix for this even though channels 1-3 are allowed world wide on the rule (57240 - 63720 @ 2160), channel 2 at 60480 MHz will end up getting disabled given that it is 3240 MHz from both the frequency rule start and end frequency. Fix this by using 2 GHz separation assumption for the 2.4 and 5 GHz bands but for 60 GHz use a 10 GHz separation before assuming a rule is not part of the band. Since we have no 802.11ad drivers yet merged this change has no impact to existing Linux upstream device drivers. Signed-off-by: NVladimir Kondratiev <qca_vkondrat@qca.qualcomm.com> Acked-by: NLuis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 19 9月, 2012 2 次提交
-
-
由 Luis R. Rodriguez 提交于
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: NFelix Fietkau <nbd@openwrt.org> Tested-by: NFelix Fietkau <nbd@openwrt.org> Cc: stable@vger.kernel.org Signed-off-by: NLuis R. Rodriguez <mcgrof@do-not-panic.com> Reviewed-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Alan Cox 提交于
The only case where intersected_rd can become non NULL is within an if. All paths from that if return, so the end chunk has therefore squawked its last and is no more. Signed-off-by: NAlan Cox <alan@linux.intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 05 9月, 2012 1 次提交
-
-
由 Wei Yongjun 提交于
Using list_move_tail() instead of list_del() + list_add_tail(). Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 02 8月, 2012 2 次提交
-
-
由 Paul Stewart 提交于
Restore the default state to the "beacon_found" flag when the channel flags are restored. Otherwise, we can end up with a channel that we can no longer transmit on even when we can see beacons on that channel. Signed-off-by: NPaul Stewart <pstew@chromium.org> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Seth Forshee 提交于
Currently the only way for wireless drivers to tell whether or not OFDM is allowed on the current channel is to check the regulatory information. However, this requires hodling cfg80211_mutex, which is not visible to the drivers. Other regulatory restrictions are provided as flags in the channel definition, so let's do similarly with OFDM. This patch adds a new flag, IEEE80211_CHAN_NO_OFDM, to tell drivers that OFDM on a channel is not allowed. This flag is set on any channels for which regulatory indicates that OFDM is prohibited. Signed-off-by: NSeth Forshee <seth.forshee@canonical.com> Tested-by: NArend van Spriel <arend@broadcom.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 25 7月, 2012 1 次提交
-
-
由 Stanislaw Gruszka 提交于
commit eccc068e Author: Hong Wu <Hong.Wu@dspg.com> 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 eccc068e 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. Cc: stable@vger.kernel.org # 3.4+ Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com> Acked-by: NLuis R. Rodriguez <mcgrof@qca.qualcomm.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 18 7月, 2012 1 次提交
-
-
由 Mohammed Shafi Shajakhan 提交于
should fix the following issue [ 3229.815012] [ BUG: lock held when returning to user space! ] [ 3229.815016] 3.5.0-rc7-wl #28 Tainted: G W O [ 3229.815017] ------------------------------------------------ [ 3229.815019] wpa_supplicant/5783 is leaving the kernel with locks still held! [ 3229.815022] 1 lock held by wpa_supplicant/5783: [ 3229.815023] #0: (reg_mutex){+.+.+.}, at: [<fa65834d>] reg_last_request_cell_base+0x1d/0x60 [cfg80211] Cc: Luis Rodriguez <mcgrof@gmail.com> Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Tested-by: NLuciano Coelho <coelho@ti.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 17 7月, 2012 5 次提交
-
-
由 Luis R. Rodriguez 提交于
regulatory_update() just calls wiphy_update_regulatory(). wiphy_update_regulatory() assumes you already have the reg_mutex held so just move the call within locking context and kill the superfluous regulatory_update(). Signed-off-by: NLuis R. Rodriguez <mcgrof@qca.qualcomm.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Luis R. Rodriguez 提交于
Now that we have wiphy_regulatory_register() we can tuck away the core's regulatory_update() call there and make it static. Signed-off-by: NLuis R. Rodriguez <mcgrof@qca.qualcomm.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Luis R. Rodriguez 提交于
This makes it clearer what we're doing. This now makes a bit more sense given that regardless of the wiphy if the cell base station hint feature is supported we will be modifying the way the regulatory core behaves. Signed-off-by: NLuis R. Rodriguez <mcgrof@qca.qualcomm.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Luis R. Rodriguez 提交于
Cellular base stations can provide hints to cfg80211 about where they think we are. This can be done for example on a cell phone. To enable these hints we simply allow them through as user regulatory hints but we allow userspace to clasify the hint as either coming directly from the user or coming from a cellular base station. This option is only available when you enable CONFIG_CFG80211_CERTIFICATION_ONUS. The base station hints themselves will not be processed by the core unless at least one device on the system supports this feature. Signed-off-by: NLuis R. Rodriguez <mcgrof@qca.qualcomm.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Kalle Valo 提交于
While adding regulatory support to ath6kl I noticed that I easily got the regulatory code confused. The way to reproduce the bug was: 1. iw reg set FI (in userspace) 2. cfg80211 calls ath6kl_reg_notify(FI) 3. ath6kl sets regdomain in firmware 4. firmware sends regdomain event to notify about the new regdomain (FI) 5. ath6kl calls regulatory_hint(FI) And this (from FI to FI transition) confuses cfg80211 and after that I only get "Pending regulatory request, waiting for it to be processed...." messages and regdomain changes won't work anymore. The reason why ath6kl calls regulatory_hint() is that firmware can change the regulatory domain by it's own, for example due to 11d IEs. I could of course workaround this in ath6kl but I think it's better to handle the case in cfg80211. The fix is pretty simple, use a different error code if the regdomain is same and then just set the request processed so that it doesn't block new requests. Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 02 7月, 2012 1 次提交
-
-
由 Vladimir Kondratiev 提交于
Add regulatory rule for the 60g band Signed-off-by: NVladimir Kondratiev <qca_vkondrat@qca.qualcomm.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 13 6月, 2012 1 次提交
-
-
由 Eliad Peller 提交于
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: [<bf28ae00>] restore_regulatory_settings+0x34/0x418 [cfg80211] but task is already holding lock: ((reg_timeout).work){+.+...}, at: [<c0059e94>] 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){+.+...}: [<c008fd44>] validate_chain+0xb94/0x10f0 [<c0090b68>] __lock_acquire+0x8c8/0x9b0 [<c0090d40>] lock_acquire+0xf0/0x114 [<c005b600>] wait_on_work+0x4c/0x154 [<c005c000>] __cancel_work_timer+0xd4/0x11c [<c005c064>] cancel_delayed_work_sync+0x1c/0x20 [<bf28b274>] reg_set_request_processed+0x50/0x78 [cfg80211] [<bf28bd84>] set_regdom+0x550/0x600 [cfg80211] [<bf294cd8>] nl80211_set_reg+0x218/0x258 [cfg80211] [<c03c7738>] genl_rcv_msg+0x1a8/0x1e8 [<c03c6a00>] netlink_rcv_skb+0x5c/0xc0 [<c03c7584>] genl_rcv+0x28/0x34 [<c03c6720>] netlink_unicast+0x15c/0x228 [<c03c6c7c>] netlink_sendmsg+0x218/0x298 [<c03933c8>] sock_sendmsg+0xa4/0xc0 [<c039406c>] __sys_sendmsg+0x1e4/0x268 [<c0394228>] sys_sendmsg+0x4c/0x70 [<c0013840>] ret_fast_syscall+0x0/0x3c -> #1 (reg_mutex){+.+.+.}: [<c008fd44>] validate_chain+0xb94/0x10f0 [<c0090b68>] __lock_acquire+0x8c8/0x9b0 [<c0090d40>] lock_acquire+0xf0/0x114 [<c04734dc>] mutex_lock_nested+0x48/0x320 [<bf28b2cc>] reg_todo+0x30/0x538 [cfg80211] [<c0059f44>] process_one_work+0x2a0/0x480 [<c005a4b4>] worker_thread+0x1bc/0x2bc [<c0061148>] kthread+0x98/0xa4 [<c0014af4>] kernel_thread_exit+0x0/0x8 -> #0 (cfg80211_mutex){+.+.+.}: [<c008ed58>] print_circular_bug+0x68/0x2cc [<c008fb28>] validate_chain+0x978/0x10f0 [<c0090b68>] __lock_acquire+0x8c8/0x9b0 [<c0090d40>] lock_acquire+0xf0/0x114 [<c04734dc>] mutex_lock_nested+0x48/0x320 [<bf28ae00>] restore_regulatory_settings+0x34/0x418 [cfg80211] [<bf28b200>] reg_timeout_work+0x1c/0x20 [cfg80211] [<c0059f44>] process_one_work+0x2a0/0x480 [<c005a4b4>] worker_thread+0x1bc/0x2bc [<c0061148>] kthread+0x98/0xa4 [<c0014af4>] 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: [<c0059e94>] process_one_work+0x1f0/0x480 #1: ((reg_timeout).work){+.+...}, at: [<c0059e94>] process_one_work+0x1f0/0x480 stack backtrace: [<c001b928>] (unwind_backtrace+0x0/0x12c) from [<c0471d3c>] (dump_stack+0x20/0x24) [<c0471d3c>] (dump_stack+0x20/0x24) from [<c008ef70>] (print_circular_bug+0x280/0x2cc) [<c008ef70>] (print_circular_bug+0x280/0x2cc) from [<c008fb28>] (validate_chain+0x978/0x10f0) [<c008fb28>] (validate_chain+0x978/0x10f0) from [<c0090b68>] (__lock_acquire+0x8c8/0x9b0) [<c0090b68>] (__lock_acquire+0x8c8/0x9b0) from [<c0090d40>] (lock_acquire+0xf0/0x114) [<c0090d40>] (lock_acquire+0xf0/0x114) from [<c04734dc>] (mutex_lock_nested+0x48/0x320) [<c04734dc>] (mutex_lock_nested+0x48/0x320) from [<bf28ae00>] (restore_regulatory_settings+0x34/0x418 [cfg80211]) [<bf28ae00>] (restore_regulatory_settings+0x34/0x418 [cfg80211]) from [<bf28b200>] (reg_timeout_work+0x1c/0x20 [cfg80211]) [<bf28b200>] (reg_timeout_work+0x1c/0x20 [cfg80211]) from [<c0059f44>] (process_one_work+0x2a0/0x480) [<c0059f44>] (process_one_work+0x2a0/0x480) from [<c005a4b4>] (worker_thread+0x1bc/0x2bc) [<c005a4b4>] (worker_thread+0x1bc/0x2bc) from [<c0061148>] (kthread+0x98/0xa4) [<c0061148>] (kthread+0x98/0xa4) from [<c0014af4>] (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) Cc: stable@kernel.org Signed-off-by: NEliad Peller <eliad@wizery.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 10 4月, 2012 1 次提交
-
-
由 Luis R. Rodriguez 提交于
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 <sfr@canb.auug.org.au> Cc: Youngsin Lee <youngsin@qualcomm.com> Cc: Raja Mani <rmani@qca.qualcomm.com> Cc: Senthil Kumar Balasubramanian <senthilb@qca.qualcomm.com> Cc: Vipin Mehta <vipimeht@qca.qualcomm.com> 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 Cc: stable@vger.kernel.org Signed-off-by: NLuis R. Rodriguez <mcgrof@frijolero.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 25 1月, 2012 1 次提交
-
-
由 Hong Wu 提交于
wireless: Save original maximum regulatory transmission power for the calucation of the local maximum transmit power 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: NHong Wu <hong.wu@dspg.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 05 1月, 2012 4 次提交
-
-
由 Luis R. Rodriguez 提交于
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 <elendil@planet.nl> - Frans Pop <fjp@debian.org> 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 <petri.karhula@nokia.com> 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.gitAcked-by: NThadeu Lima de Souza Cascardo <cascardo@holoscopio.com> Acked-by: NDan Carpenter <error27@gmail.com> Acked-by: NMihai Moldovan <ionic@ionic.de> Acked-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: NSven Neumann <s.neumann@raumfeld.com> Acked-by: NJohannes Berg <johannes@sipsolutions.net> Acked-by: NTomas Winkler <tomas.winkler@intel.com> Acked-by: NTony Vroon <tony@linx.net> Acked-by: NPavel Roskin <proski@gnu.org> Acked-by: NBob Copeland <me@bobcopeland.com> Acked-by: NLucas De Marchi <lucas.demarchi@profusion.mobi> Acked-by: NPat Erley <pat-lkml@erley.org> Acked-by: NTejun Heo <tj@kernel.org> Acked-by: NJohn W. Linville <linville@tuxdriver.com> Acked-by: NChris Wright <chrisw@sous-sol.org> Acked-by: NJoe Perches <joe@perches.com> Acked-by: NPaul Gortmaker <paul.gortmaker@windriver.com> Acked-by: NJohn Gordon <john@devicescape.com> Acked-by: NSimon Barber <protocolmagic@gmail.com> Acked-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com> Acked-by: NJiri Benc <jbenc@upir.cz> Acked-by: NBruno Randolf <br1@einfach.org> Acked-by: NScott James Remnant <keybuk@google.com> Acked-by: NRoel Kluin <roel.kluin@gmail.com> Signed-off-by: NLuis R. Rodriguez <mcgrof@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
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 269ac5fd Author: Kalle Valo <kalle.valo@nokia.com> 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: NKalle Valo <kalle.valo@nokia.com> Acked: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com> Cc: Petri Karhula <petri.karhula@nokia.com> Signed-off-by: NLuis R. Rodriguez <mcgrof@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
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 c4c32294 Author: Yuri Ershov <ext-yuri.ershov@nokia.com> 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: NYuri Ershov <ext-yuri.ershov@nokia.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com> Cc: Petri Karhula <petri.karhula@nokia.com> Signed-off-by: NLuis R. Rodriguez <mcgrof@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Dmitry Shmidt 提交于
Signed-off-by: NDmitry Shmidt <dimitrysh@google.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 16 12月, 2011 2 次提交
-
-
由 Rajkumar Manoharan 提交于
When we restore regulatory settings the world regulatory domain is properly reset on cfg80211 (or user prefered regulatory domain) but we were never setting back channel values for drivers that use WIPHY_FLAG_CUSTOM_REGULATORY. Set these values up again by using the orig_ channel parameters. This fixes restoring custom regulatory settings upon disconnect events. Cc: compat@orbit-lab.org Cc: Paul Stewart <pstew@google.com> Cc: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Cc: Senthilkumar Balasubramanian <senthilb@qca.qualcomm.com> Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: NLuis R. Rodriguez <mcgrof@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
By definition WIPHY_FLAG_STRICT_REGULATORY was intended to allow the wiphy to adjust itself to the country IE power information if the card had no regulatory data but we had no way to tell cfg80211 that if the card also had its own custom regulatory domain (these are typically custom world regulatory domains) that we want to follow the country IE's noted values for power for each channel. We add support for this and document it. This is not a critical fix but a performance optimization for cards with custom regulatory domains that associate to an AP with sends out country IEs with a higher EIRP than the one on the custom regulatory domain. In practice the only driver affected right now are the Atheros drivers as they are the only drivers using both WIPHY_FLAG_STRICT_REGULATORY and WIPHY_FLAG_CUSTOM_REGULATORY -- used on cards that have an Atheros world regulatory domain. Cards that have been programmed to follow a country specifically will not follow the country IE power. So although not a stable fix distributions should consider cherry picking this. Cc: compat@orbit-lab.org Cc: Paul Stewart <pstew@google.com> Cc: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Cc: Senthilkumar Balasubramanian <senthilb@qca.qualcomm.com> Reported-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: NLuis R. Rodriguez <mcgrof@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 14 12月, 2011 1 次提交
-
-
由 Rajkumar Manoharan 提交于
Regulatory updates set by CORE are ignored for custom regulatory cards. Let us notify the changes to the driver, as some drivers uses core hint to restore its orig_* reg domain setting. Cc: Paul Stewart <pstew@google.com> Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com> Acked-by: NLuis R. Rodriguez <mcgrof@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 01 12月, 2011 2 次提交
-
-
由 Luis R. Rodriguez 提交于
Johannes' patch for "cfg80211: fix regulatory NULL dereference" broke user regulaotry hints and it did not address the fact that last_request was left populated even if the previous regulatory hint was stale due to the wiphy disappearing. Fix user reguluatory hints by only bailing out if for those regulatory hints where a request_wiphy is expected. The stale last_request considerations are addressed through the previous fixes on last_request where we reset the last_request to a static world regdom request upon reset_regdomains(). In this case though we further enhance the effect by simply restoring reguluatory settings completely. Cc: stable@vger.kernel.org Cc: Johannes Berg <johannes.berg@intel.com> Signed-off-by: NLuis R. Rodriguez <mcgrof@qca.qualcomm.com> Reviewed-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
There is a theoretical race that if hit will trigger a crash. The race is between when we issue the first regulatory hint, regulatory_hint_core(), gets processed by the workqueue and between when the first device gets registered to the wireless core. This is not easy to reproduce but it was easy to do so through the regulatory simulator I have been working on. This is a port of the fix I implemented there [1]. [1] https://github.com/mcgrof/regsim/commit/a246ccf81f059cb662eee288aa13100f631e4cc8 Cc: stable@vger.kernel.org Cc: Johannes Berg <johannes.berg@intel.com> Signed-off-by: NLuis R. Rodriguez <mcgrof@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 22 11月, 2011 3 次提交
-
-
由 Luis R. Rodriguez 提交于
This grants drivers access to the DFS region that a regulatory domain belongs to. Signed-off-by: NLuis R. Rodriguez <mcgrof@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
The wireless-regdb now has support for mapping a country to one DFS region. CRDA sends this to us now so process it so we can provide that hint to drivers. This will later be used by code for processing DFS in a way that meets the criteria for the DFS region the country belongs to. Signed-off-by: NLuis R. Rodriguez <mcgrof@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
By the time userspace returns with a response to the regulatory domain request, the wiphy causing the request might have gone away. If this is so, reject the update but mark the request as having been processed anyway. Cc: Luis R. Rodriguez <lrodriguez@qca.qualcomm.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Cc: stable@vger.kernel.org Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-