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

The lockdep report is pasted below.

cfg80211: Calling CRDA to update world regulatory domain

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

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

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

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

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

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

other info that might help us debug this:

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

 Possible unsafe locking scenario:

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

 *** DEADLOCK ***

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

stack backtrace:
Call Trace:
[<80290fd4>] dump_stack+0x8/0x34
[<80291bc4>] print_circular_bug+0x2ac/0x2d8
[<800a77b8>] __lock_acquire+0x10d4/0x17bc
[<800a8384>] lock_acquire+0x60/0x88
[<802950a8>] mutex_lock_nested+0x54/0x31c
[<816468a4>] set_regdom+0x78c/0x808 [cfg80211]
Reported-by: NFelix Fietkau <nbd@openwrt.org>
Tested-by: NFelix Fietkau <nbd@openwrt.org>
Cc: stable@vger.kernel.org
Signed-off-by: NLuis R. Rodriguez <mcgrof@do-not-panic.com>
Reviewed-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

For example, when a usb reset is received (I could reproduce it
running something very similar to this[1] in a loop) it could be
that the device is unregistered while the power_off delayed work
is still scheduled to run.

Backtrace:

WARNING: at lib/debugobjects.c:261 debug_print_object+0x7c/0x8d()
Hardware name: To Be Filled By O.E.M.
ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x26
Modules linked in: nouveau mxm_wmi btusb wmi bluetooth ttm coretemp drm_kms_helper
Pid: 2114, comm: usb-reset Not tainted 3.5.0bt-next #2
Call Trace:
 [<ffffffff8124cc00>] ? free_obj_work+0x57/0x91
 [<ffffffff81058f88>] warn_slowpath_common+0x7e/0x97
 [<ffffffff81059035>] warn_slowpath_fmt+0x41/0x43
 [<ffffffff8124ccb6>] debug_print_object+0x7c/0x8d
 [<ffffffff8106e3ec>] ? __queue_work+0x259/0x259
 [<ffffffff8124d63e>] ? debug_check_no_obj_freed+0x6f/0x1b5
 [<ffffffff8124d667>] debug_check_no_obj_freed+0x98/0x1b5
 [<ffffffffa00aa031>] ? bt_host_release+0x10/0x1e [bluetooth]
 [<ffffffff810fc035>] kfree+0x90/0xe6
 [<ffffffffa00aa031>] bt_host_release+0x10/0x1e [bluetooth]
 [<ffffffff812ec2f9>] device_release+0x4a/0x7e
 [<ffffffff8123ef57>] kobject_release+0x11d/0x154
 [<ffffffff8123ed98>] kobject_put+0x4a/0x4f
 [<ffffffff812ec0d9>] put_device+0x12/0x14
 [<ffffffffa009472b>] hci_free_dev+0x22/0x26 [bluetooth]
 [<ffffffffa0280dd0>] btusb_disconnect+0x96/0x9f [btusb]
 [<ffffffff813581b4>] usb_unbind_interface+0x57/0x106
 [<ffffffff812ef988>] __device_release_driver+0x83/0xd6
 [<ffffffff812ef9fb>] device_release_driver+0x20/0x2d
 [<ffffffff813582a7>] usb_driver_release_interface+0x44/0x7b
 [<ffffffff81358795>] usb_forced_unbind_intf+0x45/0x4e
 [<ffffffff8134f959>] usb_reset_device+0xa6/0x12e
 [<ffffffff8135df86>] usbdev_do_ioctl+0x319/0xe20
 [<ffffffff81203244>] ? avc_has_perm_flags+0xc9/0x12e
 [<ffffffff812031a0>] ? avc_has_perm_flags+0x25/0x12e
 [<ffffffff81050101>] ? do_page_fault+0x31e/0x3a1
 [<ffffffff8135eaa6>] usbdev_ioctl+0x9/0xd
 [<ffffffff811126b1>] vfs_ioctl+0x21/0x34
 [<ffffffff81112f7b>] do_vfs_ioctl+0x408/0x44b
 [<ffffffff81208d45>] ? file_has_perm+0x76/0x81
 [<ffffffff8111300f>] sys_ioctl+0x51/0x76
 [<ffffffff8158db22>] system_call_fastpath+0x16/0x1b

[1] http://cpansearch.perl.org/src/DPAVLIN/Biblio-RFID-0.03/examples/usbreset.cSigned-off-by: NVinicius Costa Gomes <vinicius.gomes@openbossa.org>
Cc: stable@vger.kernel.org
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

When releasing L2CAP socket which is in BT_CONFIG state l2cap_chan_close
invokes l2cap_send_disconn_req which cancel delayed works which are only
set in BT_CONNECTED state with l2cap_ertm_init. Add state check before
cancelling those works.

...
[ 9668.574372] [21085] l2cap_sock_release: sock cd065200, sk f073e800
[ 9668.574399] [21085] l2cap_sock_shutdown: sock cd065200, sk f073e800
[ 9668.574411] [21085] l2cap_chan_close: chan f073ec00 state BT_CONFIG sk f073e800
[ 9668.574421] [21085] l2cap_send_disconn_req: chan f073ec00 conn ecc16600
[ 9668.574441] INFO: trying to register non-static key.
[ 9668.574443] the code is fine but needs lockdep annotation.
[ 9668.574446] turning off the locking correctness validator.
[ 9668.574450] Pid: 21085, comm: obex-client Tainted: G           O 3.5.0+ #57
[ 9668.574452] Call Trace:
[ 9668.574463]  [<c10a64b3>] __lock_acquire+0x12e3/0x1700
[ 9668.574468]  [<c10a44fb>] ? trace_hardirqs_on+0xb/0x10
[ 9668.574476]  [<c15e4f60>] ? printk+0x4d/0x4f
[ 9668.574479]  [<c10a6e38>] lock_acquire+0x88/0x130
[ 9668.574487]  [<c1059740>] ? try_to_del_timer_sync+0x60/0x60
[ 9668.574491]  [<c1059790>] del_timer_sync+0x50/0xc0
[ 9668.574495]  [<c1059740>] ? try_to_del_timer_sync+0x60/0x60
[ 9668.574515]  [<f8aa1c23>] l2cap_send_disconn_req+0xe3/0x160 [bluetooth]
...
Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

When new BT USB adapter is plugged in it's configured while still being powered
off (HCI_AUTO_OFF flag is set), thus Set LE will only set dev_flags but won't
write changes to controller. As a result it's not possible to start device
discovery session on LE controller as it uses interleaved discovery which
requires LE Supported Host flag in extended features.

This patch ensures HCI Write LE Host Supported is sent when Set Powered is
called to power on controller and clear HCI_AUTO_OFF flag.
Signed-off-by: NAndrzej Kaczmarek <andrzej.kaczmarek@tieto.com>
Cc: stable@vger.kernel.org
Acked-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

When new BT USB adapter is plugged in it's configured while still being powered
off (HCI_AUTO_OFF flag is set), thus Set SSP will only set dev_flags but won't
write changes to controller. As a result remote devices won't use Secure Simple
Pairing with our device due to SSP Host Support flag disabled in extended
features and may also reject SSP attempt from our side (with possible fallback
to legacy pairing).

This patch ensures HCI Write Simple Pairing Mode is sent when Set Powered is
called to power on controller and clear HCI_AUTO_OFF flag.
Signed-off-by: NAndrzej Kaczmarek <andrzej.kaczmarek@tieto.com>
Cc: stable@vger.kernel.org
Acked-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

Fixes big endian host configuration parameters.

Cc: stable <stable@vger.kernel.org>
Reviewed-by: NArend Van Spriel <arend@broadcom.com>
Signed-off-by: NHante Meuleman <meuleman@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

ssid len is 32 bit and needs endian conversion for big endian systems.

Cc: stable <stable@vger.kernel.org>
Signed-off-by: NHante Meuleman <meuleman@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

There are a number of problems that occur for the latest version
of the Realtek RTL8188CE device with the in-kernel driver. These
include selection of the wrong firmware, and system lockup. A full
fix is known, but is too invasive for inclusion in stable. This patch
fixes the problem with loading the wrong firmware, and logs a message
that the device may not work for kernels 3.6 and older.
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org>
Cc: Anisse Astier <anisse@astier.eu>
Cc: Li Chaoming <chaoming_li@realsil.com.cn>
Tested-by: NAnisse Astier <anisse@astier.eu>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Check for oobirq_entry allocation failure to avoid
NULL pointer dereferencing.
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Acked-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Some checks for PA linearization support checked ATH9K_HW_CAP_PAPRD and some
used the EEPROM ops, leading to issues in tx power handling, since those
two can be out of sync.

Disable the feature by default, since it has been reported that it can
cause damage to the rx path under some circumstances. It can now be enabled
for testing via debugfs.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The driver provides the cfg80211 regulatory framework with a set of
custom rules. However, there was a mismatch in number of rules
and the actual rules provided. This resulted in setting an invalid
power level:

ieee80211 phy0: brcms_ops_config: change channel 13
ieee80211 phy0: brcms_ops_config: Error setting power_level (8758364)

Closer look in cfg80211 regulatory blurb showed following bogus rule:
cfg80211: 0 KHz - -60446948 KHz @ 875836468 KHz), (875836468 mBi, 875836468 mBm)

Cc: Seth Forshee <seth.forshee@canonical.com>
Reviewed-by: NPiotr Haber <phaber@broadcom.com>
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Reviewed-by: NSeth Forshee <seth.forshee@canonical.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When the interface is down, the hardware is powered off.
However, the suspend handler currently tries to send host sleep commands
(when wakeup params are set) in this configuration, causing a system hang
when going into suspend (the commands will never complete).

Avoid this by detecting this situation and simply returning from
the suspend handler without doing anything special.
Signed-off-by: NDaniel Drake <dsd@laptop.org>
Acked-by: NDan Williams <dcbw@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

On our system (ARM Cortex-M3 SOC running linux-2.6.33)
frequent crashes were observed in the rt2800usb module
because of the invalid length of the received packet (3392,
46920...). This patch adds the sanity check on the packet
legth. Also, changed WARNING to ERROR in rt2x00lib_rxdone()
so that the bad packet condition would be noticed.

The fix was tested on the latest compat-wireless-3.5.1-1-snpc.

Cc: stable@vger.kernel.org
Signed-off-by: NSergei Poselenov <sposelenov@emcraft.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We need to program the rfkill switch GPIO pin direction to input at
device initialization time, not only when the interface is brought up.
Doing this only when the interface is brought up could lead to rfkill
detecting the switch is turned on erroneously and inability to create
the interface and bringing it up.
Reported-and-tested-by: NAndreas Messer <andi@bastelmap.de>
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Cc: <stable@vger.kernel.org>
Acked-by: NIvo Van Doorn <ivdoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The register is 16 bits wide, not 32.
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Cc: <stable@vger.kernel.org>
Acked-by: NIvo Van Doorn <ivdoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This is an RT3572 based device.
Signed-off-by: NMaximilian Engelhardt <maxi@daemonizer.de>
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Cc: <stable@vger.kernel.org>
Acked-by: NIvo Van Doorn <ivdoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The function brcmf_cfg80211_get_station requests the RSSI from
the device. The complete structure used needs to be cleared
before sending the request to firmware. Otherwise the request
fails filling the logs with "Could not get rssi (-2)" messages.
Reviewed-by: NArend Van Spriel <arend@broadcom.com>
Reviewed-by: NFranky (Zhenhui) Lin <frankyl@broadcom.com>
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: NHante Meuleman <meuleman@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

On both rx and tx there is was a race condition on the queueing
of usb requests. When for example frame gets submitted it is
possible that complete function gets called even before
usb_submit_urb() returns. As a result it is possible that usb
requests get losts, which was noticed on OMAP4 pandaboard
platform. This patch fixes the race condition.
Reviewed-by: NArend Van Spriel <arend@broadcom.com>
Reviewed-by: NFranky (Zhenhui) Lin <frankyl@broadcom.com>
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: NHante Meuleman <meuleman@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

URB_ZERO_PACKET should only be set or bulk OUT and this condition
is checked with a WARN_ON in usb_submit_urb(). This patch fixes
brcmfmac to get rid of this warning filling the logs.
Reviewed-by: NFranky (Zhenhui) Lin <frankyl@broadcom.com>
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: NHante Meuleman <meuleman@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The USB part of the brcmfmac did a dev_kfree_skb() that resulted
in a warning in net/core/skbuff.c:

Jul 11 04:53:33 lb-bun-10 kernel: [53282.667745] WARNING: at
net/core/skbuff.c:490 skb_release_head_state+0xcc/0xe0()

The brcmutil modules provides brcmu_pkt_buf_free_skb() which takes
the context into account. This patch makes use of this function
instead of dev_kfree_skb().
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Reviewed-by: NHante Meuleman <meuleman@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Generic timers for BTCOEX functionality is applicable
only for 3 WIRE BTCOEX (and MCI) chipsets.
Hence btcoex->no_stomp_timer is allocated only 3 WIRE
btcoex chipsets and in all the other cases its NULL.
Make sure we stop the generic timer only if
'btcoex->hw_timer_enabled' is true(only if its up and
running)

Fixes the following crash

	[68757.020454] BUG: unable to handle kernel NULL pointer dereference at 0000000c
	[68757.020916] IP: [<f9b055c3>] ath9k_hw_gen_timer_stop+0x13/0x80 [ath9k_hw]
	[68757.021251] *pde = 00000000
	[68757.024384] EIP: 0060:[<f9b055c3>] EFLAGS: 00010082 CPU: 0
	[68757.024384] EIP is at ath9k_hw_gen_timer_stop+0x13/0x80 [ath9k_hw]
	[68757.024384] EAX: d32d0000 EBX: d32d0000 ECX: 00000000 EDX: 00000000
	[68757.024384] ESI: e67c24c0 EDI: 00000296 EBP: e137be2c ESP: e137be20
	[68757.024384]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
	[68757.024384] CR0: 8005003b CR2: 0000000c CR3: 00b99000 CR4: 000407d0
	[68757.024384] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
	[68757.024384] DR6: ffff0ff0 DR7: 00000400
	[68757.024384] Process kworker/u:2 (pid: 8917, ti=e137a000 task=ea7a6860 task.ti=e137a000)
	[68757.024384] Stack:
	[68757.024384]  c06c4676 d32d0000 e67c24c0 e137be38 f81c9590 e67c1ca0 e137be40 f81c95d9
	[68757.024384]  e137be64 f81cd1c5 00000246 00000002 d32d0000 e67c05e0 e67c1ca0 e67c05e0
	[68757.024384]  00000000 e137beac f81cdfa0 e137be84 00000246 00000246 e67c1ca0 e67c1ca0
	[68757.024384] Call Trace:
	[68757.024384]  [<c06c4676>] ? _raw_spin_lock_irqsave+0x86/0xa0
	[68757.024384]  [<f81c9590>] ath9k_gen_timer_stop+0x10/0x40 [ath9k]
	[68757.024384]  [<f81c95d9>] ath9k_btcoex_stop_gen_timer+0x19/0x20 [ath9k]
	[68757.024384]  [<f81cd1c5>] ath9k_ps_restore+0x85/0x110 [ath9k]
	[68757.024384]  [<f81cdfa0>] ath9k_config+0x220/0x520 [ath9k]
	[68757.024384]  [<f81cd47d>] ? ath9k_flush+0x15d/0x1b0 [ath9k]
	[68757.024384]  [<f85c7ca5>] ieee80211_hw_config+0x135/0x2c0 [mac80211]
	[68757.024384]  [<f860e3c8>] ieee80211_dynamic_ps_enable_work+0x198/0x5f0 [mac80211]

Cc: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Cc: Bala Shanmugam <bkamatch@qca.qualcomm.com>
Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This feature had been disabled in ath9k because the code to support
it was incomplete, but now the code is in sync with the internal QCA
codebase, so it's time to enable it.

On many newer devices, the calibration is assumed to be done with PA
linearization enabled.

Tests with a particular AR933x device showed that the signal emitted
at full power was highly distorted and unreliable with PA linearization
disabled. With this patch, the signal becomes clear and stability
is improved.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Before PAPRD training can run, the card needs to have sent a packet for
thermal calibration. Sending a dummy packet with the PAPRD training flag
set causes a crash under some circumstance.
Fix the code by replacing the dummy tx with a delay that waits for a
real packet tx to have occurred.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Support for it is incomplete
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Re-train if the calibrated PA linearization curve is out of bounds
(affects AR933x and AR9485).
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

That predistortion type is not supported
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The interrupt is no longer handling it. While it shouldn't fire (wraparound
is highly unlikely), the consequences would be fatal (interrupt storm).
Disable the interrupt to prevent that from happening.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

According to the vendor driver v2.6.0.1, during the rf register init the SRAM
voltage should be increased to 1.35V and after 1ms decreased back to 1.2V. This
patch adds the field setting of LDO_CFG0_LDO_CORE_VLEVEL accordingly.

Cc: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NMarc Kleine-Budde <mkl@blackshift.org>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When we send a command to firmware, we assumed that cmd_size
will be always less than or equal to the structure size of
host_cmd_ds_command. However, this is no longer true after
we added AP support. There are some AP commands that Custom
IE TLVs are included in command buffer, hence the cmd_size
gets enlarged by the TLV data. We need to increase the skb
length for the extra data.
Signed-off-by: NStone Piao <piaoyun@marvell.com>
Signed-off-by: NAvinash Patil <patila@marvell.com>
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Various small fixes for net/mac80211/cfg.c:mpath_set_pinfo():
Initialize *pinfo before filling members in, handle MESH_PATH_RESOLVED
correctly, and remove bogus assignment; result in correct display
of FLAGS values and meaningful EXPTIME for expired paths in iw utility.
Signed-off-by: NYoichi Shinoda <shinoda@jaist.ac.jp>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

connkeys is malloced in nl80211_parse_connkeys() and should
be freed in the error handling case, otherwise it will cause
memory leak.

spatch with a semantic match is used to found this problem.
(http://coccinelle.lip6.fr/)
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

ifmgd->bssid wasn't cleared properly in some
auth/assoc failure cases, causing mac80211 and
the low-level driver to go out of sync.

Clear ifmgd->bssid on failure, and notify the driver.

Cc: stable@kernel.org # 3.4+
Signed-off-by: NEliad Peller <eliad@wizery.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

In the case that the link is already in the connected state and a
Pairing request arrives from the mgmt interface, hci_conn_security()
would be called but it was not considering LE links.
Reported-by: NJoão Paulo Rechi Vita <jprvita@openbossa.org>
Signed-off-by: NVinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

To make it clear that it may be called from contexts that may not have
any knowledge of L2CAP, we change the connection parameter, to receive
a hci_conn.

This also makes it clear that it is checking the security of the link.
Signed-off-by: NVinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

As pointed out by Gustavo and Marcel, all Apple-specific Broadcom
devices seen so far have the same interface class, subclass and
protocol numbers. This patch adds an entry which matches all of them,
using the new USB_VENDOR_AND_INTERFACE_INFO() macro.

In particular, this patch adds support for the MacBook Pro Retina
(05ac:8286), which is not in the present list.
Signed-off-by: NHenrik Rydberg <rydberg@euromail.se>
Tested-by: NShea Levy <shea@shealevy.com>
Acked-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

This change marks interface as down on reset, otherwise the driver can't
reinitialize itself properly.

Without the change a transient problem turns out to be critical and leads
to inavailability to reset the driver without brcmsmac module unload/load
cycle:

    ieee80211 phy0: wl0: PSM microcode watchdog fired at 5993 (seconds). Resetting.
    brcms_c_dpc : PSM Watchdog, chipid 0xa8d9, chiprev 0x1
    ieee80211 phy0: wl0: fatal error, reinitializing
    ieee80211 phy0: Hardware restart was requested
    ieee80211 phy0: brcms_ops_start: brcms_up() returned -19
Signed-off-by: NVladimir Zapolskiy <vz@mleia.com>
Cc: Arend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The destination address of unicast frames forwarded through a mesh gate
was being replaced with the broadcast address. Instead leave the
original destination address as the mesh DA. If the nexthop address is
not in the mpath table it will be resolved. If that fails, the frame
will be forwarded to known mesh gates.
Reported-by: NCedric Voncken <cedric.voncken@acksys.fr>
Signed-off-by: NThomas Pedersen <thomas@cozybit.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>