]> git.proxmox.com Git - mirror_ubuntu-eoan-kernel.git/log
mirror_ubuntu-eoan-kernel.git
12 years agoiwlwifi: kill iwl_down and s/__iwl_down/iwl_down
Emmanuel Grumbach [Fri, 17 Feb 2012 18:34:53 +0000 (10:34 -0800)]
iwlwifi: kill iwl_down and s/__iwl_down/iwl_down

iwl_down was just a wrapper around __iwl_down which was called from
one place only. Replace it to direct call to iwl_down. Add lockdep
warning in iwl_down to ensure it was called with the mutex held.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
12 years agoiwlwifi: change args to ucode routines
Don Fry [Tue, 7 Feb 2012 00:37:46 +0000 (16:37 -0800)]
iwlwifi: change args to ucode routines

Change the prameters to the ucode (de)allocate routines to iwl_nic as
they are not transport operations.

Signed-off-by: Don Fry <donald.h.fry@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
12 years agoiwlwifi: Move ucode pointers to iwl_fw
Don Fry [Tue, 7 Feb 2012 23:00:12 +0000 (15:00 -0800)]
iwlwifi: Move ucode pointers to iwl_fw

The ucode image is a ucode related thing not a transport one.  Move them.

Signed-off-by: Don Fry <donald.h.fry@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
12 years agoiwlwifi: move firmware_loading_complete to iwl_nic
Don Fry [Tue, 7 Feb 2012 00:00:14 +0000 (16:00 -0800)]
iwlwifi: move firmware_loading_complete to iwl_nic

Move firmware_loading_complete from iwl_priv to iwl_nic and rename it
to more accurately reflect what it does.

Signed-off-by: Don Fry <donald.h.fry@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
12 years agoiwlwifi: move firmware_name to iwl_nic
Don Fry [Mon, 6 Feb 2012 23:57:40 +0000 (15:57 -0800)]
iwlwifi: move firmware_name to iwl_nic

Delete firmware_name from iwl_priv and use iwl_nic instead.

Signed-off-by: Don Fry <donald.h.fry@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
12 years agoiwlwifi: move fw_index from iwl_priv to iwl_nic
Don Fry [Mon, 6 Feb 2012 23:54:31 +0000 (15:54 -0800)]
iwlwifi: move fw_index from iwl_priv to iwl_nic

Delete fw_index from iwl_priv and use iwl_nic instead.

Signed-off-by: Don Fry <donald.h.fry@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
12 years agoiwlwifi: move ucode_ver to iwl_nic
Don Fry [Mon, 6 Feb 2012 23:51:15 +0000 (15:51 -0800)]
iwlwifi: move ucode_ver to iwl_nic

Delete ucode_ver from iwl_priv and use iwl_nic instead.

Signed-off-by: Don Fry <donald.h.fry@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
12 years agoiwlwifi: create iwl_nic structure
Don Fry [Tue, 7 Feb 2012 22:45:58 +0000 (14:45 -0800)]
iwlwifi: create iwl_nic structure

Create iwl_nic structure and link it together.

Signed-off-by: Don Fry <donald.h.fry@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
12 years agoiwlwifi: give PCIe its own lock
Johannes Berg [Sun, 5 Feb 2012 21:55:11 +0000 (13:55 -0800)]
iwlwifi: give PCIe its own lock

Instead of using a global lock, the PCIe transport
can use an own lock for its IRQ. This will make it
possible to not disable IRQs for the shared lock.
The lock is currently used throughout the code but
this can be improved even further by splitting up
the locking for the queues.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Wey-Yi W Guy <wey-yi.w.guy@intel.com>
12 years agoiwlwifi: move workqueue to priv
Johannes Berg [Fri, 17 Feb 2012 18:07:44 +0000 (10:07 -0800)]
iwlwifi: move workqueue to priv

In order to separate the different parts of the
driver better, we are reducing the shared data.
This moves the workqueue to "priv", and removes
it from the transport. To do this, simply use
schedule_work() in the transport.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
12 years agoiwlwifi: trace debug messages
Johannes Berg [Wed, 1 Feb 2012 05:08:37 +0000 (21:08 -0800)]
iwlwifi: trace debug messages

Make iwlwifi record all debug messages into
tracing, even if debug_level is not enabled.
Due to the lack of APIs, the debug messages
are now recorded up to a max length of 100,
the only one above that is the RXON which is
not needed if you trace the commands as well
as it only dumps the command contents.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi W Guy <wey-yi.w.guy@intel.com>
12 years agoiwlwifi: added reply data to testmode HCMD send
Amit Beka [Tue, 31 Jan 2012 13:30:39 +0000 (15:30 +0200)]
iwlwifi: added reply data to testmode HCMD send

The testmode command for host command send now replies
with a nl80211 message and the response it recieved from
the device.

This does not change the API directly, but adds a reply
to the testmode call.

Signed-off-by: Amit Beka <amit.beka@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
12 years agoiwlwifi: testmode new indirect RW API
Amit Beka [Wed, 25 Jan 2012 11:30:27 +0000 (13:30 +0200)]
iwlwifi: testmode new indirect RW API

Replaced the old SRAM and periphery indirect access functions
with a unified indirect memory access functions. These include
new IWL_TM_CMDs for buffer read/write/dump which replace the
SRAM read/dump commands, but the API for IWL_TM_CMD_INDIRECT_REG
read/write will now not be supported (returns error).

This also handles writing to periphery registers in 1-3 bytes.

Requires the corresponding patch in the library for the API change.

Signed-off-by: Amit Beka <amit.beka@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
12 years agoiwlwifi: log as error when error detected
Wey-Yi Guy [Fri, 3 Feb 2012 21:06:57 +0000 (13:06 -0800)]
iwlwifi: log as error when error detected

A lot of error conditions in testmode log as IWL_DEBUG_INFO which is not
logged by default. Change it

Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
12 years agoMerge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless
John W. Linville [Wed, 15 Feb 2012 21:24:37 +0000 (16:24 -0500)]
Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless

Conflicts:
net/mac80211/debugfs_sta.c
net/mac80211/sta_info.h

12 years agoath9k: stop on rates with idx -1 in ath9k rate control's .tx_status
Pavel Roskin [Sat, 11 Feb 2012 15:01:53 +0000 (10:01 -0500)]
ath9k: stop on rates with idx -1 in ath9k rate control's .tx_status

Rate control algorithms are supposed to stop processing when they
encounter a rate with the index -1.  Checking for rate->count not being
zero is not enough.

Allowing a rate with negative index leads to memory corruption in
ath_debug_stat_rc().

One consequence of the bug is discussed at
https://bugzilla.redhat.com/show_bug.cgi?id=768639

Signed-off-by: Pavel Roskin <proski@gnu.org>
Cc: stable@vger.kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agomwifiex: clear previous security setting during association
Amitkumar Karwar [Fri, 10 Feb 2012 02:32:22 +0000 (18:32 -0800)]
mwifiex: clear previous security setting during association

Driver maintains different flags for WEP, WPA, WPA2 security modes.
Appropriate flag is set using security information provided in
connect request. mwifiex_is_network_compatible() routine uses them
to check if driver's setting is compatible with AP. Association is
aborted if the routine fails.

For some corner cases, it is observed that association is failed
even for valid security information based on association history.
This patch fixes the problem by clearing previous security setting
during each association.

We should set WEP key provided in connect request as default tx key.
This missing change is also added here.

Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agomac80211: do not call rate control .tx_status before .rate_init
Felix Fietkau [Wed, 8 Feb 2012 18:17:11 +0000 (19:17 +0100)]
mac80211: do not call rate control .tx_status before .rate_init

Most rate control implementations assume .get_rate and .tx_status are only
called once the per-station data has been fully initialized.
minstrel_ht crashes if this assumption is violated.

Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Tested-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agomac80211: call rate control only after init
Johannes Berg [Fri, 20 Jan 2012 12:55:23 +0000 (13:55 +0100)]
mac80211: call rate control only after init

There are situations where we don't have the
necessary rate control information yet for
station entries, e.g. when associating. This
currently doesn't really happen due to the
dummy station handling; explicitly disabling
rate control when it's not initialised will
allow us to remove dummy stations.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agoBluetooth: Fix possible use after free in delete path
Ulisses Furquim [Mon, 30 Jan 2012 20:26:29 +0000 (18:26 -0200)]
Bluetooth: Fix possible use after free in delete path

We need to use the _sync() version for cancelling the info and security
timer in the L2CAP connection delete path. Otherwise the delayed work
handler might run after the connection object is freed.

Signed-off-by: Ulisses Furquim <ulisses@profusion.mobi>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
12 years agoBluetooth: Remove usage of __cancel_delayed_work()
Ulisses Furquim [Mon, 30 Jan 2012 20:26:28 +0000 (18:26 -0200)]
Bluetooth: Remove usage of __cancel_delayed_work()

__cancel_delayed_work() is being used in some paths where we cannot
sleep waiting for the delayed work to finish. However, that function
might return while the timer is running and the work will be queued
again. Replace the calls with safer cancel_delayed_work() version
which spins until the timer handler finishes on other CPUs and
cancels the delayed work.

Signed-off-by: Ulisses Furquim <ulisses@profusion.mobi>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
12 years agoBluetooth: btusb: Add vendor specific ID (0a5c 21f3) for BCM20702A0
Manoj Iyer [Thu, 2 Feb 2012 15:32:36 +0000 (09:32 -0600)]
Bluetooth: btusb: Add vendor specific ID (0a5c 21f3) for BCM20702A0

T: Bus=01 Lev=02 Prnt=02 Port=03 Cnt=03 Dev#= 5 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0a5c ProdID=21f3 Rev=01.12
S: Manufacturer=Broadcom Corp
S: Product=BCM20702A0
S: SerialNumber=74DE2B344A7B
C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)

Signed-off-by: Manoj Iyer <manoj.iyer@canonical.com>
Tested-by: Dennis Chua <dennis.chua@canonical.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
12 years agoBluetooth: Add missing QUIRK_NO_RESET test to hci_dev_do_close
Johan Hedberg [Fri, 3 Feb 2012 19:29:40 +0000 (21:29 +0200)]
Bluetooth: Add missing QUIRK_NO_RESET test to hci_dev_do_close

We should only perform a reset in hci_dev_do_close if the
HCI_QUIRK_NO_RESET flag is set (since in such a case a reset will not be
performed when initializing the device).

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
12 years agoBluetooth: Fix RFCOMM session reference counting issue
Octavian Purdila [Fri, 27 Jan 2012 17:32:39 +0000 (19:32 +0200)]
Bluetooth: Fix RFCOMM session reference counting issue

There is an imbalance in the rfcomm_session_hold / rfcomm_session_put
operations which causes the following crash:

[  685.010159] BUG: unable to handle kernel paging request at 6b6b6b6b
[  685.010169] IP: [<c149d76d>] rfcomm_process_dlcs+0x1b/0x15e
[  685.010181] *pdpt = 000000002d665001 *pde = 0000000000000000
[  685.010191] Oops: 0000 [#1] PREEMPT SMP
[  685.010247]
[  685.010255] Pid: 947, comm: krfcommd Tainted: G         C  3.0.16-mid8-dirty #44
[  685.010266] EIP: 0060:[<c149d76d>] EFLAGS: 00010246 CPU: 1
[  685.010274] EIP is at rfcomm_process_dlcs+0x1b/0x15e
[  685.010281] EAX: e79f551c EBX: 6b6b6b6b ECX: 00000007 EDX: e79f40b4
[  685.010288] ESI: e79f4060 EDI: ed4e1f70 EBP: ed4e1f68 ESP: ed4e1f50
[  685.010295]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[  685.010303] Process krfcommd (pid: 947, ti=ed4e0000 task=ed43e5e0 task.ti=ed4e0000)
[  685.010308] Stack:
[  685.010312]  ed4e1f68 c149eb53 e5925150 e79f4060 ed500000 ed4e1f70 ed4e1f80 c149ec10
[  685.010331]  00000000 ed43e5e0 00000000 ed4e1f90 ed4e1f9c c149ec87 0000bf54 00000000
[  685.010348]  00000000 ee03bf54 c149ec37 ed4e1fe4 c104fe01 00000000 00000000 00000000
[  685.010367] Call Trace:
[  685.010376]  [<c149eb53>] ? rfcomm_process_rx+0x6e/0x74
[  685.010387]  [<c149ec10>] rfcomm_process_sessions+0xb7/0xde
[  685.010398]  [<c149ec87>] rfcomm_run+0x50/0x6d
[  685.010409]  [<c149ec37>] ? rfcomm_process_sessions+0xde/0xde
[  685.010419]  [<c104fe01>] kthread+0x63/0x68
[  685.010431]  [<c104fd9e>] ? __init_kthread_worker+0x42/0x42
[  685.010442]  [<c14dae82>] kernel_thread_helper+0x6/0xd

This issue has been brought up earlier here:

https://lkml.org/lkml/2011/5/21/127

The issue appears to be the rfcomm_session_put in rfcomm_recv_ua. This
operation doesn't seem be to required as for the non-initiator case we
have the rfcomm_process_rx doing an explicit put and in the initiator
case the last dlc_unlink will drive the reference counter to 0.

There have been several attempts to fix these issue:

6c2718d Bluetooth: Do not call rfcomm_session_put() for RFCOMM UA on closed socket
683d949 Bluetooth: Never deallocate a session when some DLC points to it

but AFAICS they do not fix the issue just make it harder to reproduce.

Signed-off-by: Octavian Purdila <octavian.purdila@intel.com>
Signed-off-by: Gopala Krishna Murala <gopala.krishna.murala@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
12 years agoBluetooth: Fix potential deadlock
Andre Guedes [Fri, 27 Jan 2012 22:42:02 +0000 (19:42 -0300)]
Bluetooth: Fix potential deadlock

We don't need to use the _sync variant in hci_conn_hold and
hci_conn_put to cancel conn->disc_work delayed work. This way
we avoid potential deadlocks like this one reported by lockdep.

======================================================
[ INFO: possible circular locking dependency detected ]
3.2.0+ #1 Not tainted
-------------------------------------------------------
kworker/u:1/17 is trying to acquire lock:
 (&hdev->lock){+.+.+.}, at: [<ffffffffa0041155>] hci_conn_timeout+0x62/0x158 [bluetooth]

but task is already holding lock:
 ((&(&conn->disc_work)->work)){+.+...}, at: [<ffffffff81035751>] process_one_work+0x11a/0x2bf

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #2 ((&(&conn->disc_work)->work)){+.+...}:
       [<ffffffff81057444>] lock_acquire+0x8a/0xa7
       [<ffffffff81034ed1>] wait_on_work+0x3d/0xaa
       [<ffffffff81035b54>] __cancel_work_timer+0xac/0xef
       [<ffffffff81035ba4>] cancel_delayed_work_sync+0xd/0xf
       [<ffffffffa00554b0>] smp_chan_create+0xde/0xe6 [bluetooth]
       [<ffffffffa0056160>] smp_conn_security+0xa3/0x12d [bluetooth]
       [<ffffffffa0053640>] l2cap_connect_cfm+0x237/0x2e8 [bluetooth]
       [<ffffffffa004239c>] hci_proto_connect_cfm+0x2d/0x6f [bluetooth]
       [<ffffffffa0046ea5>] hci_event_packet+0x29d1/0x2d60 [bluetooth]
       [<ffffffffa003dde3>] hci_rx_work+0xd0/0x2e1 [bluetooth]
       [<ffffffff810357af>] process_one_work+0x178/0x2bf
       [<ffffffff81036178>] worker_thread+0xce/0x152
       [<ffffffff81039a03>] kthread+0x95/0x9d
       [<ffffffff812e7754>] kernel_thread_helper+0x4/0x10

-> #1 (slock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+...}:
       [<ffffffff81057444>] lock_acquire+0x8a/0xa7
       [<ffffffff812e553a>] _raw_spin_lock_bh+0x36/0x6a
       [<ffffffff81244d56>] lock_sock_nested+0x24/0x7f
       [<ffffffffa004d96f>] lock_sock+0xb/0xd [bluetooth]
       [<ffffffffa0052906>] l2cap_chan_connect+0xa9/0x26f [bluetooth]
       [<ffffffffa00545f8>] l2cap_sock_connect+0xb3/0xff [bluetooth]
       [<ffffffff81243b48>] sys_connect+0x69/0x8a
       [<ffffffff812e6579>] system_call_fastpath+0x16/0x1b

-> #0 (&hdev->lock){+.+.+.}:
       [<ffffffff81056d06>] __lock_acquire+0xa80/0xd74
       [<ffffffff81057444>] lock_acquire+0x8a/0xa7
       [<ffffffff812e3870>] __mutex_lock_common+0x48/0x38e
       [<ffffffff812e3c75>] mutex_lock_nested+0x2a/0x31
       [<ffffffffa0041155>] hci_conn_timeout+0x62/0x158 [bluetooth]
       [<ffffffff810357af>] process_one_work+0x178/0x2bf
       [<ffffffff81036178>] worker_thread+0xce/0x152
       [<ffffffff81039a03>] kthread+0x95/0x9d
       [<ffffffff812e7754>] kernel_thread_helper+0x4/0x10

other info that might help us debug this:

Chain exists of:
  &hdev->lock --> slock-AF_BLUETOOTH-BTPROTO_L2CAP --> (&(&conn->disc_work)->work)

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock((&(&conn->disc_work)->work));
                               lock(slock-AF_BLUETOOTH-BTPROTO_L2CAP);
                               lock((&(&conn->disc_work)->work));
  lock(&hdev->lock);

 *** DEADLOCK ***

2 locks held by kworker/u:1/17:
 #0:  (hdev->name){.+.+.+}, at: [<ffffffff81035751>] process_one_work+0x11a/0x2bf
 #1:  ((&(&conn->disc_work)->work)){+.+...}, at: [<ffffffff81035751>] process_one_work+0x11a/0x2bf

stack backtrace:
Pid: 17, comm: kworker/u:1 Not tainted 3.2.0+ #1
Call Trace:
 [<ffffffff812e06c6>] print_circular_bug+0x1f8/0x209
 [<ffffffff81056d06>] __lock_acquire+0xa80/0xd74
 [<ffffffff81021ef2>] ? arch_local_irq_restore+0x6/0xd
 [<ffffffff81022bc7>] ? vprintk+0x3f9/0x41e
 [<ffffffff81057444>] lock_acquire+0x8a/0xa7
 [<ffffffffa0041155>] ? hci_conn_timeout+0x62/0x158 [bluetooth]
 [<ffffffff812e3870>] __mutex_lock_common+0x48/0x38e
 [<ffffffffa0041155>] ? hci_conn_timeout+0x62/0x158 [bluetooth]
 [<ffffffff81190fd6>] ? __dynamic_pr_debug+0x6d/0x6f
 [<ffffffffa0041155>] ? hci_conn_timeout+0x62/0x158 [bluetooth]
 [<ffffffff8105320f>] ? trace_hardirqs_off+0xd/0xf
 [<ffffffff812e3c75>] mutex_lock_nested+0x2a/0x31
 [<ffffffffa0041155>] hci_conn_timeout+0x62/0x158 [bluetooth]
 [<ffffffff810357af>] process_one_work+0x178/0x2bf
 [<ffffffff81035751>] ? process_one_work+0x11a/0x2bf
 [<ffffffff81055af3>] ? lock_acquired+0x1d0/0x1df
 [<ffffffffa00410f3>] ? hci_acl_disconn+0x65/0x65 [bluetooth]
 [<ffffffff81036178>] worker_thread+0xce/0x152
 [<ffffffff810407ed>] ? finish_task_switch+0x45/0xc5
 [<ffffffff810360aa>] ? manage_workers.isra.25+0x16a/0x16a
 [<ffffffff81039a03>] kthread+0x95/0x9d
 [<ffffffff812e7754>] kernel_thread_helper+0x4/0x10
 [<ffffffff812e5db4>] ? retint_restore_args+0x13/0x13
 [<ffffffff8103996e>] ? __init_kthread_worker+0x55/0x55
 [<ffffffff812e7750>] ? gs_change+0x13/0x13

Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Reviewed-by: Ulisses Furquim <ulisses@profusion.mobi>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
12 years agoBluetooth: silence lockdep warning
Octavian Purdila [Sat, 21 Jan 2012 22:28:34 +0000 (00:28 +0200)]
Bluetooth: silence lockdep warning

Since bluetooth uses multiple protocols types, to avoid lockdep
warnings, we need to use different lockdep classes (one for each
protocol type).

This is already done in bt_sock_create but it misses a couple of cases
when new connections are created. This patch corrects that to fix the
following warning:

<4>[ 1864.732366] =======================================================
<4>[ 1864.733030] [ INFO: possible circular locking dependency detected ]
<4>[ 1864.733544] 3.0.16-mid3-00007-gc9a0f62 #3
<4>[ 1864.733883] -------------------------------------------------------
<4>[ 1864.734408] t.android.btclc/4204 is trying to acquire lock:
<4>[ 1864.734869]  (rfcomm_mutex){+.+.+.}, at: [<c14970ea>] rfcomm_dlc_close+0x15/0x30
<4>[ 1864.735541]
<4>[ 1864.735549] but task is already holding lock:
<4>[ 1864.736045]  (sk_lock-AF_BLUETOOTH){+.+.+.}, at: [<c1498bf7>] lock_sock+0xa/0xc
<4>[ 1864.736732]
<4>[ 1864.736740] which lock already depends on the new lock.
<4>[ 1864.736750]
<4>[ 1864.737428]
<4>[ 1864.737437] the existing dependency chain (in reverse order) is:
<4>[ 1864.738016]
<4>[ 1864.738023] -> #1 (sk_lock-AF_BLUETOOTH){+.+.+.}:
<4>[ 1864.738549]        [<c1062273>] lock_acquire+0x104/0x140
<4>[ 1864.738977]        [<c13d35c1>] lock_sock_nested+0x58/0x68
<4>[ 1864.739411]        [<c1493c33>] l2cap_sock_sendmsg+0x3e/0x76
<4>[ 1864.739858]        [<c13d06c3>] __sock_sendmsg+0x50/0x59
<4>[ 1864.740279]        [<c13d0ea2>] sock_sendmsg+0x94/0xa8
<4>[ 1864.740687]        [<c13d0ede>] kernel_sendmsg+0x28/0x37
<4>[ 1864.741106]        [<c14969ca>] rfcomm_send_frame+0x30/0x38
<4>[ 1864.741542]        [<c1496a2a>] rfcomm_send_ua+0x58/0x5a
<4>[ 1864.741959]        [<c1498447>] rfcomm_run+0x441/0xb52
<4>[ 1864.742365]        [<c104f095>] kthread+0x63/0x68
<4>[ 1864.742742]        [<c14d5182>] kernel_thread_helper+0x6/0xd
<4>[ 1864.743187]
<4>[ 1864.743193] -> #0 (rfcomm_mutex){+.+.+.}:
<4>[ 1864.743667]        [<c1061ada>] __lock_acquire+0x988/0xc00
<4>[ 1864.744100]        [<c1062273>] lock_acquire+0x104/0x140
<4>[ 1864.744519]        [<c14d2c70>] __mutex_lock_common+0x3b/0x33f
<4>[ 1864.744975]        [<c14d303e>] mutex_lock_nested+0x2d/0x36
<4>[ 1864.745412]        [<c14970ea>] rfcomm_dlc_close+0x15/0x30
<4>[ 1864.745842]        [<c14990d9>] __rfcomm_sock_close+0x5f/0x6b
<4>[ 1864.746288]        [<c1499114>] rfcomm_sock_shutdown+0x2f/0x62
<4>[ 1864.746737]        [<c13d275d>] sys_socketcall+0x1db/0x422
<4>[ 1864.747165]        [<c14d42f0>] syscall_call+0x7/0xb

Signed-off-by: Octavian Purdila <octavian.purdila@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
12 years agoBluetooth: Fix using an absolute timeout on hci_conn_put()
Vinicius Costa Gomes [Wed, 4 Jan 2012 14:57:17 +0000 (11:57 -0300)]
Bluetooth: Fix using an absolute timeout on hci_conn_put()

queue_delayed_work() expects a relative time for when that work
should be scheduled.

Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
12 years agoBluetooth: l2cap_set_timer needs jiffies as timeout value
Andrzej Kaczmarek [Wed, 4 Jan 2012 11:10:42 +0000 (12:10 +0100)]
Bluetooth: l2cap_set_timer needs jiffies as timeout value

After moving L2CAP timers to workqueues l2cap_set_timer expects timeout
value to be specified in jiffies but constants defined in miliseconds
are used. This makes timeouts unreliable when CONFIG_HZ is not set to
1000.

__set_chan_timer macro still uses jiffies as input to avoid multiple
conversions from/to jiffies for sk_sndtimeo value which is already
specified in jiffies.

Signed-off-by: Andrzej Kaczmarek <andrzej.kaczmarek@tieto.com>
Ackec-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
12 years agoBluetooth: Fix sk_sndtimeo initialization for L2CAP socket
Andrzej Kaczmarek [Wed, 4 Jan 2012 11:10:41 +0000 (12:10 +0100)]
Bluetooth: Fix sk_sndtimeo initialization for L2CAP socket

sk_sndtime value should be specified in jiffies thus initial value
needs to be converted from miliseconds. Otherwise this timeout is
unreliable when CONFIG_HZ is not set to 1000.

Signed-off-by: Andrzej Kaczmarek <andrzej.kaczmarek@tieto.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
12 years agoBluetooth: Remove bogus inline declaration from l2cap_chan_connect
Johan Hedberg [Sun, 8 Jan 2012 20:51:16 +0000 (22:51 +0200)]
Bluetooth: Remove bogus inline declaration from l2cap_chan_connect

As reported by Dan Carpenter this function causes a Sparse warning and
shouldn't be declared inline:

include/net/bluetooth/l2cap.h:837:30 error: marked inline, but without a
definition"

Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
12 years agoBluetooth: Don't mark non xfer isoc endpoint URBs with URB_ISO_ASAP
Daniel Wagner [Tue, 3 Jan 2012 10:53:53 +0000 (11:53 +0100)]
Bluetooth: Don't mark non xfer isoc endpoint URBs with URB_ISO_ASAP

[ 2096.384084] btusb_send_frame:684: hci0
[ 2096.384087] usb 3-1: BOGUS urb flags, 2 --> 0
[ 2096.384091] Bluetooth: hci0 urb ffff8801b61d3a80 submission failed (22)

According the documentation in usb_submit_urb() URB_ISO_ASAP
flag is only allowed for endpoints of type USB_ENDPOINT_XFER_ISOC.

This reverts commit b8aabfc92249b239c425da7e4ca85b7e4855e984.

Signed-off-by: Daniel Wagner <daniel.wagner@bmw-carit.de>
Acked-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
12 years agoBluetooth: Fix l2cap conn failures for ssp devices
Peter Hurley [Fri, 13 Jan 2012 14:11:30 +0000 (15:11 +0100)]
Bluetooth: Fix l2cap conn failures for ssp devices

Commit 330605423c fixed l2cap conn establishment for non-ssp remote
devices by not setting HCI_CONN_ENCRYPT_PEND every time conn security
is tested (which was always returning failure on any subsequent
security checks).

However, this broke l2cap conn establishment for ssp remote devices
when an ACL link was already established at SDP-level security. This
fix ensures that encryption must be pending whenever authentication
is also pending.

Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Tested-by: Daniel Wagner <daniel.wagner@bmw-carit.de>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
12 years agortlwifi: Modify rtl_pci_init to return 0 on success
Simon Graham [Thu, 9 Feb 2012 14:55:13 +0000 (09:55 -0500)]
rtlwifi: Modify rtl_pci_init to return 0 on success

Fixes problem where caller would think routine succeeded when it failed
leading to divide by zero panic.

Signed-off-by: Simon Graham <simon.graham@virtualcomputer.com>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agomac80211: Fix a rwlock bad magic bug
Mohammed Shafi Shajakhan [Thu, 9 Feb 2012 14:29:43 +0000 (19:59 +0530)]
mac80211: Fix a rwlock bad magic bug

read_lock(&tpt_trig->trig.leddev_list_lock) is accessed via the path
ieee80211_open (->) ieee80211_do_open (->) ieee80211_mod_tpt_led_trig
(->) ieee80211_start_tpt_led_trig (->) tpt_trig_timer before initializing
it.
the intilization of this read/write lock happens via the path
ieee80211_led_init (->) led_trigger_register, but we are doing
'ieee80211_led_init'  after 'ieeee80211_if_add' where we
register netdev_ops.
so we access leddev_list_lock before initializing it and causes the
following bug in chrome laptops with AR928X cards with the following
script

while true
do
sudo modprobe -v ath9k
sleep 3
sudo modprobe -r ath9k
sleep 3
done

BUG: rwlock bad magic on CPU#1, wpa_supplicant/358, f5b9eccc
Pid: 358, comm: wpa_supplicant Not tainted 3.0.13 #1
Call Trace:

[<8137b9df>] rwlock_bug+0x3d/0x47
[<81179830>] do_raw_read_lock+0x19/0x29
[<8137f063>] _raw_read_lock+0xd/0xf
[<f9081957>] tpt_trig_timer+0xc3/0x145 [mac80211]
[<f9081f3a>] ieee80211_mod_tpt_led_trig+0x152/0x174 [mac80211]
[<f9076a3f>] ieee80211_do_open+0x11e/0x42e [mac80211]
[<f9075390>] ? ieee80211_check_concurrent_iface+0x26/0x13c [mac80211]
[<f9076d97>] ieee80211_open+0x48/0x4c [mac80211]
[<812dbed8>] __dev_open+0x82/0xab
[<812dc0c9>] __dev_change_flags+0x9c/0x113
[<812dc1ae>] dev_change_flags+0x18/0x44
[<8132144f>] devinet_ioctl+0x243/0x51a
[<81321ba9>] inet_ioctl+0x93/0xac
[<812cc951>] sock_ioctl+0x1c6/0x1ea
[<812cc78b>] ? might_fault+0x20/0x20
[<810b1ebb>] do_vfs_ioctl+0x46e/0x4a2
[<810a6ebb>] ? fget_light+0x2f/0x70
[<812ce549>] ? sys_recvmsg+0x3e/0x48
[<810b1f35>] sys_ioctl+0x46/0x69
[<8137fa77>] sysenter_do_call+0x12/0x2

Cc: <stable@vger.kernel.org>
Cc: Gary Morain <gmorain@google.com>
Cc: Paul Stewart <pstew@google.com>
Cc: Abhijit Pradhan <abhijit@qca.qualcomm.com>
Cc: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
Cc: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Acked-by: Johannes Berg <johannes.berg@intel.com>
Tested-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agortlwifi: Modify rtl_pci_init to return 0 on success
John W. Linville [Thu, 9 Feb 2012 19:48:25 +0000 (14:48 -0500)]
rtlwifi: Modify rtl_pci_init to return 0 on success

Fixes problem where caller would think routine succeeded when it failed
leading to divide by zero panic.

(This also reverts an earlier attempt, commit 42bc0c97 "rtlwifi: Return
correct failure code on error". -- JWL)

Signed-off-by: Simon Graham <simon.graham@virtualcomputer.com>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agomac80211: do not call rate control .tx_status before .rate_init
Felix Fietkau [Wed, 8 Feb 2012 18:17:11 +0000 (19:17 +0100)]
mac80211: do not call rate control .tx_status before .rate_init

Most rate control implementations assume .get_rate and .tx_status are only
called once the per-station data has been fully initialized.
minstrel_ht crashes if this assumption is violated.

Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Tested-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agortlwifi: Return correct failure code on error
Simon Graham [Wed, 8 Feb 2012 17:34:23 +0000 (12:34 -0500)]
rtlwifi: Return correct failure code on error

Callers of rtl_pci_init expect zero to be returned on error. Returning
the error code leads to, amongst other things, divide by zero panics
attempting to use the ring size that is set to zero.

Signed-off-by: Simon Graham <simon.graham@virtualcomputer.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agomac80211: rename mesh static path_lookup()
Luis R. Rodriguez [Wed, 8 Feb 2012 05:09:25 +0000 (21:09 -0800)]
mac80211: rename mesh static path_lookup()

If you want to use mesh support from mac80211 on a recent
kernel on 2.6.24 you'll run into a name clash when compiling
against include/linux/namei.h, so rename this routine.

/home/mcgrof/tmp/compat-wireless-3.2.5-1/net/mac80211/mesh_pathtbl.c: At top level:
/home/mcgrof/tmp/compat-wireless-3.2.5-1/net/mac80211/mesh_pathtbl.c:342:26: error: conflicting types for â€˜path_lookup’
include/linux/namei.h:71:12: note: previous declaration of â€˜path_lookup’ was here

Although this could sit as a separate patch in compat-wireless it seems
best to just merge upstream.

Cc: Javier Cardona <javier@cozybit.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@frijolero.org>
Acked-by: Javier Cardona <javier@cozybit.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agortlwifi: Handle previous allocation failures when freeing device memory
Simon Graham [Wed, 8 Feb 2012 00:07:38 +0000 (18:07 -0600)]
rtlwifi: Handle previous allocation failures when freeing device memory

Handle previous allocation failures when freeing device memory

Signed-off-by: Simon Graham <simon.graham@virtualcomputer.com>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agomac80211: add #ifdef CONFIG_MAC80211_VERBOSE_DEBUG for a debug printk
Felix Fietkau [Tue, 7 Feb 2012 11:45:44 +0000 (12:45 +0100)]
mac80211: add #ifdef CONFIG_MAC80211_VERBOSE_DEBUG for a debug printk

When not debugging mac80211 code, station state transitions do not need to
show up in the kernel log.

Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agort2x00: Correctly set txmixer_gain in RT3572 channel switching.
Gertjan van Wingerde [Mon, 6 Feb 2012 22:45:13 +0000 (23:45 +0100)]
rt2x00: Correctly set txmixer_gain in RT3572 channel switching.

Align with the v2.5.0.0 Ralink RT3572 driver.

Save the EEPROM txmixer_gain values inside the rt2800 driver data structure
and use it throughout the code.

Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agort2x00: Fix RT3572 channel switch RFCSR 7 programming.
Gertjan van Wingerde [Mon, 6 Feb 2012 22:45:12 +0000 (23:45 +0100)]
rt2x00: Fix RT3572 channel switch RFCSR 7 programming.

Align with the v2.5.0.0 Ralink RT3572 driver.

Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agort2x00: Align RT3572 channel switch RFCSR 1 programming with Ralink driver.
Gertjan van Wingerde [Mon, 6 Feb 2012 22:45:11 +0000 (23:45 +0100)]
rt2x00: Align RT3572 channel switch RFCSR 1 programming with Ralink driver.

Align with the v2.5.0.0 Ralink RT3572 driver.

Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agort2x00: Fix RFCSR 12 & 13 programming on RT3572 channel switching.
Gertjan van Wingerde [Mon, 6 Feb 2012 22:45:10 +0000 (23:45 +0100)]
rt2x00: Fix RFCSR 12 & 13 programming on RT3572 channel switching.

Align with v2.5.0.0 Ralink RT3572 driver for 2.4GHz band channel switch.

Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agort2x00: Use saved BBP 25 and 26 values when configuring channel on RT3572.
Gertjan van Wingerde [Mon, 6 Feb 2012 22:45:09 +0000 (23:45 +0100)]
rt2x00: Use saved BBP 25 and 26 values when configuring channel on RT3572.

This brings the rt2800 channel switching code for RT3572 closer to the
v2.5.0.0 Ralink RT3572 driver.

Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agort2x00: Update comment on freq_offset field in struct rt2x00_dev.
Gertjan van Wingerde [Mon, 6 Feb 2012 22:45:08 +0000 (23:45 +0100)]
rt2x00: Update comment on freq_offset field in struct rt2x00_dev.

The comment states that the field is only used for rt61pci and rt73usb.
However, it is now used by rt2800pci and rt2800usb as well, so the
comment is not correct anymore.

Update the comment to not state any low-level drivers anymore.

Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agort2x00: Use struct rt2x00_dev driver data in rt2800{pci,usb}.
Gertjan van Wingerde [Mon, 6 Feb 2012 22:45:07 +0000 (23:45 +0100)]
rt2x00: Use struct rt2x00_dev driver data in rt2800{pci,usb}.

Start using the struct rt2x00_dev driver data in rt2800 for the calibration
data.

Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agort2x00: Introduce concept of driver data in struct rt2x00_dev.
Gertjan van Wingerde [Mon, 6 Feb 2012 22:45:06 +0000 (23:45 +0100)]
rt2x00: Introduce concept of driver data in struct rt2x00_dev.

We are getting more and more fields in struct rt2x00_dev that are
specific to one or two of the low-level drivers. Instead of putting
these fields inside the main structure and thus clobbering all low-level
drivers with these fields, introduce the concept of driver data inside
struct rt2x00_dev, whose size is indicated by the low-level driver and
which can be populated by the low-level driver.

Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agoorinoco: Remove old mailing lists from MAINTAINERS
David Gibson [Mon, 6 Feb 2012 03:07:24 +0000 (14:07 +1100)]
orinoco: Remove old mailing lists from MAINTAINERS

The two orinoco mailing lists on sourceforge were set up many years
ago and are now more or less moribund.  I'd like to shut them down, so
I don't have to keep filtering the spam from them (which is most of
what comes through now).  In preparation, this patch removes the
reference to them from the MAINTAINERS file.  Any remaining discussion
of this approaching obsolete driver can go to the linux-wireless list.

Signed-off-by: David Gibson <hermes@gibson.dropbear.id.au>
Acked-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agozd1211rw: firmware needs duration_id set to zero for non-pspoll frames
Tomas Vanek [Sun, 5 Feb 2012 13:51:53 +0000 (15:51 +0200)]
zd1211rw: firmware needs duration_id set to zero for non-pspoll frames

Some devices (iwl5100) cannot connect to zd1211rw based AP. It appears that
zd1211 firmware messes up duration_id field if it is not set to zero by driver.

Sniffing traffic shows that zd1211 is transmitting frames with duration_id bits
14 and 15 set and other bits appearing random. Setting duration_id at driver to
zero results zd1211 outputting sane duration_id. This means that firmware is
setting correct values itself and expects duration_id to be zero in first
place.

Looking at vendor driver shows that only PSPoll frames have duration_id set by
driver, for other frames duration_id left zero.

Original bug-report and attached patch at:
  http://sourceforge.net/mailarchive/message.php?msg_id=28759111

Reported-by: Tomas Vanek <Tomas.Vanek@fbl.cz>
[modified original patch from bug-report, added check for pspoll frame]
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agomac80211: call rate control only after init
Johannes Berg [Fri, 20 Jan 2012 12:55:23 +0000 (13:55 +0100)]
mac80211: call rate control only after init

There are situations where we don't have the
necessary rate control information yet for
station entries, e.g. when associating. This
currently doesn't really happen due to the
dummy station handling; explicitly disabling
rate control when it's not initialised will
allow us to remove dummy stations.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agoiwlegacy: remove set_hw_params callback
Stanislaw Gruszka [Fri, 3 Feb 2012 16:32:01 +0000 (17:32 +0100)]
iwlegacy: remove set_hw_params callback

We do not need that callback, settings parameters can be done locally.

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agoiwlegacy: remove struct il_tx_info
Stanislaw Gruszka [Fri, 3 Feb 2012 16:32:00 +0000 (17:32 +0100)]
iwlegacy: remove struct il_tx_info

It's just wrapper to sk_buff pointers ...

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agoiwlegacy: merge il_base_params into il_cfg
Stanislaw Gruszka [Fri, 3 Feb 2012 16:31:59 +0000 (17:31 +0100)]
iwlegacy: merge il_base_params into il_cfg

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agoiwlegacy: move ops out of config
Stanislaw Gruszka [Fri, 3 Feb 2012 16:31:58 +0000 (17:31 +0100)]
iwlegacy: move ops out of config

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agoiwlegacy: get rid of ctx structure
Stanislaw Gruszka [Fri, 3 Feb 2012 16:31:57 +0000 (17:31 +0100)]
iwlegacy: get rid of ctx structure

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agoiwlegacy: remove il_setup_interface()
Stanislaw Gruszka [Fri, 3 Feb 2012 16:31:56 +0000 (17:31 +0100)]
iwlegacy: remove il_setup_interface()

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agoiwlegacy: get rid of ctx->is_active
Stanislaw Gruszka [Fri, 3 Feb 2012 16:31:55 +0000 (17:31 +0100)]
iwlegacy: get rid of ctx->is_active

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agoiwlegacy: get rid of ctx->ac_to_queue
Stanislaw Gruszka [Fri, 3 Feb 2012 16:31:54 +0000 (17:31 +0100)]
iwlegacy: get rid of ctx->ac_to_queue

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agoiwlegacy: get rid of ctx->ac_to_fifo
Stanislaw Gruszka [Fri, 3 Feb 2012 16:31:53 +0000 (17:31 +0100)]
iwlegacy: get rid of ctx->ac_to_fifo

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agoiwlegacy: move ht out of ctx structure
Stanislaw Gruszka [Fri, 3 Feb 2012 16:31:52 +0000 (17:31 +0100)]
iwlegacy: move ht out of ctx structure

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agoiwlegacy: move qos_data out of ctx structure
Stanislaw Gruszka [Fri, 3 Feb 2012 16:31:51 +0000 (17:31 +0100)]
iwlegacy: move qos_data out of ctx structure

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agoiwlegacy: remove ctx interface_modes
Stanislaw Gruszka [Fri, 3 Feb 2012 16:31:50 +0000 (17:31 +0100)]
iwlegacy: remove ctx interface_modes

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agoiwlegacy: get rid of ctx->station_flags
Stanislaw Gruszka [Fri, 3 Feb 2012 16:31:49 +0000 (17:31 +0100)]
iwlegacy: get rid of ctx->station_flags

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agoiwlegacy: move wep_keys out of context
Stanislaw Gruszka [Fri, 3 Feb 2012 16:31:48 +0000 (17:31 +0100)]
iwlegacy: move wep_keys out of context

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agoiwlegacy: get rid of mcast_queue
Stanislaw Gruszka [Fri, 3 Feb 2012 16:31:47 +0000 (17:31 +0100)]
iwlegacy: get rid of mcast_queue

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agoiwlegacy: get rid of ctxid
Stanislaw Gruszka [Fri, 3 Feb 2012 16:31:46 +0000 (17:31 +0100)]
iwlegacy: get rid of ctxid

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agoiwlegacy: get rid of *_devtype
Stanislaw Gruszka [Fri, 3 Feb 2012 16:31:45 +0000 (17:31 +0100)]
iwlegacy: get rid of *_devtype

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agoiwlegacy: move bcast_sta_id to hw_params
Stanislaw Gruszka [Fri, 3 Feb 2012 16:31:44 +0000 (17:31 +0100)]
iwlegacy: move bcast_sta_id to hw_params

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agoiwlegacy: get rid of ap_sta_id
Stanislaw Gruszka [Fri, 3 Feb 2012 16:31:43 +0000 (17:31 +0100)]
iwlegacy: get rid of ap_sta_id

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agoiwlegacy: get rid of wep_key_cmd
Stanislaw Gruszka [Fri, 3 Feb 2012 16:31:42 +0000 (17:31 +0100)]
iwlegacy: get rid of wep_key_cmd

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agoiwlegacy: get rid of qos_cmd
Stanislaw Gruszka [Fri, 3 Feb 2012 16:31:41 +0000 (17:31 +0100)]
iwlegacy: get rid of qos_cmd

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agoiwlegacy: get rid of rxon_assoc_cmd
Stanislaw Gruszka [Fri, 3 Feb 2012 16:31:40 +0000 (17:31 +0100)]
iwlegacy: get rid of rxon_assoc_cmd

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agoiwlegacy: get rid of ctx->rxon_timing_cmd
Stanislaw Gruszka [Fri, 3 Feb 2012 16:31:39 +0000 (17:31 +0100)]
iwlegacy: get rid of ctx->rxon_timing_cmd

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agoiwlegacy: get rid of ctx->rxon_cmd
Stanislaw Gruszka [Fri, 3 Feb 2012 16:31:38 +0000 (17:31 +0100)]
iwlegacy: get rid of ctx->rxon_cmd

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agoiwlegacy: move rxon commands out of ctx structure
Stanislaw Gruszka [Fri, 3 Feb 2012 16:31:37 +0000 (17:31 +0100)]
iwlegacy: move rxon commands out of ctx structure

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agomwifiex: update correct dtim_period in dump_station()
Amitkumar Karwar [Fri, 3 Feb 2012 04:48:58 +0000 (20:48 -0800)]
mwifiex: update correct dtim_period in dump_station()

Earlier we were using dtim period extracted from scan response
buffer provided by FW in scan operation. But it is observed that
sometimes the buffer doesn't contain dtim period tlv, and wrong
value (0) was sent to user space.

After association FW will start listening to beacon frames of
connected AP and store dtim period. Therefore we can get it from
FW in dump_station() instead of using wrong value obtained in
scanning.

Redundant code after adapting new approach for dtim period is
also removed in this patch.

Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agomwifiex: cleanup in snmp_mib command preparation code
Amitkumar Karwar [Fri, 3 Feb 2012 04:48:57 +0000 (20:48 -0800)]
mwifiex: cleanup in snmp_mib command preparation code

1) Remove unnecessary switch case usage.
2) Replace "X=cpu_to_le16(le16_to_cpu(X) + Y)" by "le16_add_cpu(X, Y)"
3) Declare "ul_temp" variable as u16 instead of u32 to avoid
unnecessary typecasting

Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agortlwifi: Fix PCI probe error path orphaned memory
Tim Gardner [Thu, 2 Feb 2012 20:48:06 +0000 (13:48 -0700)]
rtlwifi: Fix PCI probe error path orphaned memory

Memory allocated by ieee80211_alloc_hw() will get orphaned
if any subsequent initializations fail.

Also don't pci_set_drvdata(pdev, NULL) until just before disabling
the PCI device. Functions called by rtl_deinit_core(hw) may eventually need
the context (when its actually implemented).

Cc: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Chaoming Li <chaoming_li@realsil.com.cn>
Cc: John W. Linville <linville@tuxdriver.com>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agomac80211: support hw scan while idle
Eliad Peller [Thu, 2 Feb 2012 15:44:55 +0000 (17:44 +0200)]
mac80211: support hw scan while idle

Currently, mac80211 goes to idle-off before starting a scan.
However, some devices that implement hw scan might not
need going idle-off in order to perform a hw scan, and
thus saving some energy and simplifying their state machine.

(Note that this is also the case for sched scan - it
currently doesn't make mac80211 go idle-off)

Add a new flag to indicate support for hw scan while idle.

Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agomwifiex: enable HT operating mode
Amitkumar Karwar [Thu, 2 Feb 2012 04:41:45 +0000 (20:41 -0800)]
mwifiex: enable HT operating mode

This patch sets default adapter channel_type as HT. Hence the device
will opearate in HT mode.

Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agomwifiex: fix NULL pointer dereference in set_channel()
Amitkumar Karwar [Thu, 2 Feb 2012 04:41:44 +0000 (20:41 -0800)]
mwifiex: fix NULL pointer dereference in set_channel()

In set_channel() callback handler, "priv" pointer is derived from
net_device. Sometimes net_device pointer coming from the stack
is NULL which causes kernel crash.
This patch fixes the problem by deriving "priv" from wiphy
when net_device pointer is NULL.

Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agomwl8k: Remove BSSID from the firmware when the BSS is stopped
Yogesh Ashok Powar [Wed, 1 Feb 2012 10:49:54 +0000 (16:19 +0530)]
mwl8k: Remove BSSID from the firmware when the BSS is stopped

Using command DEL_MAC_ADDR, remove the mac address of the BSS
when it is stopped i.e the corresponding vif is removed. Without
this, the stale bss entry will still be maintained in the firmware
which causes issues when the BSS's are recreated.

Signed-off-by: Nishant Sarmukadam <nishants@marvell.com>
Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agoath9k: cleanup a min_t() cast
Dan Carpenter [Wed, 1 Feb 2012 07:43:31 +0000 (10:43 +0300)]
ath9k: cleanup a min_t() cast

If the firmware was over 2G, it would cause memory corruption and the
system would die here.  Obviously we all know the firmware isn't going
to be that large but static checkers get upset.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agomac80211: off by one in mcs mask handling
Dan Carpenter [Wed, 1 Feb 2012 07:42:11 +0000 (10:42 +0300)]
mac80211: off by one in mcs mask handling

"ridx" is used as an index into the mcs_mask[] array which has
IEEE80211_HT_MCS_MASK_LEN elements.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agossb: add support for bcm5354
Hauke Mehrtens [Tue, 31 Jan 2012 23:13:56 +0000 (00:13 +0100)]
ssb: add support for bcm5354

This patch adds support the the BCM5354 SoC.
It has a PMU and a constant not configurable clock.

Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agossb: log the id, rev and pkg of the chip found
Hauke Mehrtens [Tue, 31 Jan 2012 23:13:55 +0000 (00:13 +0100)]
ssb: log the id, rev and pkg of the chip found

This makes us see what type of hardware someone uses by the dmesg
output.

Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agobcma: log the id, rev and pkg of the chip found
Hauke Mehrtens [Tue, 31 Jan 2012 23:13:54 +0000 (00:13 +0100)]
bcma: log the id, rev and pkg of the chip found

This makes us see what type of hardware someone uses by the dmesg
output.

Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agocfg80211/mac80211: userspace peer authorization in IBSS
Antonio Quartulli [Tue, 31 Jan 2012 19:25:47 +0000 (20:25 +0100)]
cfg80211/mac80211: userspace peer authorization in IBSS

If the IBSS network is RSN-protected, let userspace authorize the stations
instead of adding them as AUTHORIZED by default.

Signed-off-by: Antonio Quartulli <ordex@autistici.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agortlwifi: Remove extra debugging message accidentally left in
Larry Finger [Tue, 31 Jan 2012 16:29:22 +0000 (10:29 -0600)]
rtlwifi: Remove extra debugging message accidentally left in

In commit b0302aba812bcc39291cdab9ad7e37008f352a91, an extra debugging
message that is spamming the logs was not deleted before submission.

Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agortlwifi: Fix typo in dm.c
Masanari Iida [Tue, 31 Jan 2012 15:42:58 +0000 (09:42 -0600)]
rtlwifi: Fix typo in dm.c

Correct a spelling "disconnet" to "disconnect" in
drivers/net/wireless/rtlwifi/rtl8192de/dm.c

Signed-off-by: Masanari Iida <standby24x7@gmail.com>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agoiwmc3200wifi: Fix typo in trace.h
Masanari Iida [Tue, 31 Jan 2012 14:23:45 +0000 (23:23 +0900)]
iwmc3200wifi: Fix typo in trace.h

Correct spelling "embeded" to "embedded" in
drivers/net/wireless/iwmc3200wifi/trace.h

Signed-off-by: Masanari Iida <standby24x7@gmail.com>
Acked-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agortlwifi: remove return in _rtl_pci_switch_clk_req
Devendra.Naga [Tue, 31 Jan 2012 06:28:15 +0000 (01:28 -0500)]
rtlwifi: remove return in _rtl_pci_switch_clk_req

the return value from _rtl_pci_switch_clk_req is not used by any of its callers.

Signed-off-by: Devendra.Naga <devendra.aaru@gmail.com>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agobcma: add extra sprom check
Hauke Mehrtens [Mon, 30 Jan 2012 23:03:37 +0000 (00:03 +0100)]
bcma: add extra sprom check

This check is needed on the BCM43224 device as it says in the
capabilities it has an sprom but is extra check says it has not.

Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agobcma: add bus num counter
Hauke Mehrtens [Mon, 30 Jan 2012 23:03:36 +0000 (00:03 +0100)]
bcma: add bus num counter

If we have two bcma buses on one computer the second will not work
without this patch. Now each bus gets an own number.

Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agobcma: add PCIe host controller
Hauke Mehrtens [Mon, 30 Jan 2012 23:03:35 +0000 (00:03 +0100)]
bcma: add PCIe host controller

Some SoCs have a PCIe host controller to make it possible to attach
some other devices to it, like an other Wifi card.
This code was tested with an Netgear WNDR3400 (bcm4716 based), but
should work with all bcma based SoCs.

Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agobcma: make some functions __devinit
Hauke Mehrtens [Mon, 30 Jan 2012 23:03:34 +0000 (00:03 +0100)]
bcma: make some functions __devinit

bcma_core_pci_hostmode_init() has to be in __devinit as it will call a
function in that section and so all functions calling it also have to
be in __devinit.

Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agobcma: export bcma_pcie_read()
Hauke Mehrtens [Mon, 30 Jan 2012 23:03:33 +0000 (00:03 +0100)]
bcma: export bcma_pcie_read()

This will be needed by the host controller.

Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agobcma: add constants for PCI and use them
Hauke Mehrtens [Mon, 30 Jan 2012 23:03:32 +0000 (00:03 +0100)]
bcma: add constants for PCI and use them

There are many magic numbers used in the PCIe code. Replace them with
some constants from the Broadcom SDK and also use them in the pcie host
controller.

Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
12 years agobcma: add the core unit number
Hauke Mehrtens [Mon, 30 Jan 2012 23:03:31 +0000 (00:03 +0100)]
bcma: add the core unit number

Some SoCs have two pcie or gmac cores and we need to know the number of
the specific core on the bus. This is the case for the BCM4706.

Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>