Merge branch 'master' of git://git./linux/kernel/git/linville/wireless

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

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

iwlegacy: move ops out of config

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

iwlegacy: get rid of ctx structure

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

iwlegacy: remove il_setup_interface()

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

iwlegacy: get rid of ctx->is_active

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

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>

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>

iwlegacy: move ht out of ctx structure

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

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>

iwlegacy: remove ctx interface_modes

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

iwlegacy: get rid of ctx->station_flags

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

iwlegacy: move wep_keys out of context

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

iwlegacy: get rid of mcast_queue

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

iwlegacy: get rid of ctxid

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

iwlegacy: get rid of *_devtype

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

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>

iwlegacy: get rid of ap_sta_id

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

iwlegacy: get rid of wep_key_cmd

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

iwlegacy: get rid of qos_cmd

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

iwlegacy: get rid of rxon_assoc_cmd

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

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>

iwlegacy: get rid of ctx->rxon_cmd

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

rt2800: document RF_R03 register bits [7:4]

Taken from:
2011_0719_RT3070_RT3370_RT5370_RT5372_Linux_STA_V2.5.0.3_DPO
(based on function RT33xx_ChipSwitchChannel)

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

rt2800: radio 3xxxx: channel switch RX/TX calibration fixes

Synchronize code with Ralink driver:
2011_0719_RT3070_RT3370_RT5370_RT5372_Linux_STA_V2.5.0.3_DPO
Based on functions:
RT30xx_ChipSwitchChannel
RT33xx_ChipSwitchChannel
NICInitRT3370RFRegisters
and defines from:
include/chip/rt33xx.h

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

rt2800: radio 3xxx: add channel switch calibration routines

Synchronize code with Ralink driver:
2011_0719_RT3070_RT3370_RT5370_RT5372_Linux_STA_V2.5.0.3_DPO
Based on functions:
RT33xx_ChipSwitchChannel
RT30xx_ChipSwitchChannel

Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

rt2800: radio 3xxx: program RF_R1 during channel switch

Synchronize code with Ralink driver:
2011_0719_RT3070_RT3370_RT5370_RT5372_Linux_STA_V2.5.0.3_DPO
Based on functions:
RT33xx_ChipSwitchChannel
RT30xx_ChipSwitchChannel
RT33xx_Init

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

rt2800: radio 3xxx: reprogram only lower bits of RF_R3

Synchronize code with Ralink driver:
2011_0719_RT3070_RT3370_RT5370_RT5372_Linux_STA_V2.5.0.3_DPO
(functions: RT33xx_ChipSwitchChannel() and RT30xx_ChipSwitchChannel())

Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

net: Fix typo in ipw2x00/libipw_rx.c

Correct spelling in "suppported" to "supported" in
drivers/net/wireless/ipw2x00/libipw_rx.c

Signed-off-by: Masanari Iida <standby24x7@gmail.com>
Reviewed-by: Jesper Juhl <jj@chaosbits.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

mac80211: redesign auth/assoc

This is the second part of the auth/assoc redesign,
the mac80211 part. This moves the auth/assoc code
out of the work abstraction and into the MLME, so
that we don't flip channels all the time etc.

The only downside is that when we are associated,
we need to drop the association in order to create
a connection to another AP, but for most drivers
this is actually desirable and the ability to do
was never used by any applications. If we want to
implement resource reservation with FT-OTA, we'd
probably best do it with explicit R-O-C in wpa_s.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

cfg80211: export cfg80211_ref_bss

This is needed by mac80211 to keep a reference
to a BSS alive for the auth process. Remove the
old version of cfg80211_ref_bss() since it's
not actually used.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

cfg80211: stop tracking authenticated state

To track authenticated state seems to have been
a design mistake in cfg80211. It is possible to
have out of band authentication (FT), tracking
multiple authentications caused more problems
than it ever helped, and the implementation in
mac80211 is too complex.

Remove all this complexity, and let userspace
do whatever it wants to, mac80211 can deal with
that just fine. Association is still tracked of
course, but authentication no longer is. Local
auth state changes are thus no longer of value,
so ignore them completely.

This will also help implement SAE -- asking the
driver to do an authentication is now almost
equivalent to sending an authentication frame,
with the exception of shared key authentication
which is still handled completely.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

mac80211: remove dummy STA support

The dummy STA support was added because I didn't
want to change the driver API at the time. Now
that we have state transitions triggering station
add/remove in the driver, we only call add once a
station reaches ASSOCIATED, so we can remove the
dummy station stuff again.

While at it, tighten the RX check and accept only
port control (EAP) frames from the AP station if
it's not associated yet -- in other cases there's
no race.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

mac80211: implement sta_add/sta_remove in sta_state

Instead of maintaining separate sta_add/sta_remove
callsites, implement it in sta_state when the driver
has no sta_state implementation.

The only behavioural change this should cause is in
secure mesh mode: with this the station entries will
only be created after the stations are set to AUTH.
Given which drivers support mesh, this seems to not
be a problem.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

mac80211: add sta_state callback

(based on Eliad's patch)

Add a callback to notify the low-level driver whenever
the state of a station changes. The driver is only
notified when the station is actually in the mac80211
hash table, not for pre-insert state transitions.

To allow the driver to replace sta_add/remove calls
with this, call extra transitions with the NOTEXIST
state.

This callback can fail, so we need to be careful in
handling it when a station is inserted, particularly
in the IBSS case where we still keep the station entry
around for mac80211 purposes.

Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

mac80211: add NOTEXIST station state

This will be used by drivers later if they
need to have stations inserted all the time,
in mac80211 has no purpose, is never used
and sta_state starts out in NONE.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

mac80211: dont program keys for stations not uploaded

If a station couldn't be uploaded to the driver but
is still kept (only in IBSS mode) we still shouldn't
try to program the keys for it into hardware; fix
this bug by skipping the key upload in this case.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>