| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The length check is invalid since the length varies with type of
info response.
This was introduced by the commit cb3b3152b2f5939d67005cff841a1ca748b19888
Because of this, l2cap info rsp is not handled and command reject is sent.
> ACL data: handle 11 flags 0x02 dlen 16
L2CAP(s): Info rsp: type 2 result 0
Extended feature mask 0x00b8
Enhanced Retransmission mode
Streaming mode
FCS Option
Fixed Channels
< ACL data: handle 11 flags 0x00 dlen 10
L2CAP(s): Command rej: reason 0
Command not understood
Cc: stable@vger.kernel.org
Signed-off-by: Jaganath Kanakkassery <jaganath.k@samsung.com>
Signed-off-by: Chan-Yeol Park <chanyeol.park@samsung.com>
Acked-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
|
|
|
|
|
|
|
|
|
| |
Make sure that a chip reset is done when IDLE is turned
off - this fixes authentication timeouts.
Cc: stable@vger.kernel.org
Reported-by: Ignacy Gawedzki <i@lri.fr>
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
|
|
|
|
|
|
| |
ath_txq_schedule is called outside of the drv_tx call, so it needs RCU
protection.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|\
| |
| |
| | |
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Since my commit 3713b4e364 ("nl80211: allow splitting wiphy
information in dumps"), nl80211_dump_wiphy() uses the global
nl80211_fam.attrbuf for parsing the incoming data. This wouldn't
be a problem if it only did so on the first dump iteration which
is locked against other commands in generic netlink, but due to
space constraints in cb->args (the needed state doesn't fit) I
decided to always parse the original message. That's racy though
since nl80211_fam.attrbuf could be used by some other parsing in
generic netlink concurrently.
For now, fix this by allocating a separate parse buffer (it's a
bit too big for the stack, currently 1448 bytes on 64-bit). For
-next, I'll change the code to parse into the global buffer in
the first round only and then allocate a smaller buffer to keep
the data in cb->args.
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Acked-by: David S. Miller <davem@davemloft.net>
Acked-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When initialization within brcmf_bus_start() fails on steps
before the brcmf_net_attach() the net_device for the primary
interface needs to be freed.
This patch resolves a panic during kernel boot as reported
by Stephen Warren.
ref.: http://mid.gmane.org/51AD1F22.2080004@wwwdotorg.org
Tested-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Hante Meuleman <meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There is currently a race condition in the btmrvl_remove_card() which
is causing hangs on suspend for OLPC. When the race occurs,
kthread_stop() never returns.
The problem is that btmrvl_service_main_thread() calls kthread_should_stop()
and then does a fair number of things before restarting the loop and
sleeping.
If the thread gets stopped after kthread_should_stop() is checked, but
before the sleep happens, the thread will go to sleep and won't necessarily
be woken up.
Move the kthread_should_stop() check into a race-free place.
Signed-off-by: Daniel Drake <dsd@laptop.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Even though the HCI_Delete_Stored_Link_Key command is mandatory for 1.1
and later controllers some controllers do not seem to support it
properly as was witnessed by one Broadcom based controller:
< HCI Command: Delete Stored Link Key (0x03|0x0012) plen 7
bdaddr 00:00:00:00:00:00 all 1
> HCI Event: Command Complete (0x0e) plen 4
Delete Stored Link Key (0x03|0x0012) ncmd 1
status 0x11 deleted 0
Error: Unsupported Feature or Parameter Value
Luckily this same controller also doesn't list the command in its
supported commands bit mask (counting from 0 bit 7 of octet 6):
< HCI Command: Read Local Supported Commands (0x04|0x0002) plen 0
> HCI Event: Command Complete (0x0e) plen 68
Read Local Supported Commands (0x04|0x0002) ncmd 1
status 0x00
Commands: ffffffffffff1ffffffffffff30fffff3f
Therefore, it makes sense to move sending of HCI_Delete_Stored_Link_Key
to after receiving the supported commands response and to only send it
if its respective bit in the mask is set. The downside of this is that
we no longer send the HCI_Delete_Stored_Link_Key command for Bluetooth
1.1 controllers since HCI_Read_Local_Supported_Command was introduced in
version 1.2, but this is an acceptable penalty as the command in
question shouldn't affect critical behavior.
Reported-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Tested-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If a too small MTU value is set with ioctl(HCISETACLMTU) or by a bogus
controller, memory corruption happens due to a memcpy() call with
negative length.
Fix this crash on either incoming or outgoing connections with a MTU
smaller than L2CAP_HDR_SIZE + L2CAP_CMD_HDR_SIZE:
[ 46.885433] BUG: unable to handle kernel paging request at f56ad000
[ 46.888037] IP: [<c03d94cd>] memcpy+0x1d/0x40
[ 46.888037] *pdpt = 0000000000ac3001 *pde = 00000000373f8067 *pte = 80000000356ad060
[ 46.888037] Oops: 0002 [#1] SMP DEBUG_PAGEALLOC
[ 46.888037] Modules linked in: hci_vhci bluetooth virtio_balloon i2c_piix4 uhci_hcd usbcore usb_common
[ 46.888037] CPU: 0 PID: 1044 Comm: kworker/u3:0 Not tainted 3.10.0-rc1+ #12
[ 46.888037] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
[ 46.888037] Workqueue: hci0 hci_rx_work [bluetooth]
[ 46.888037] task: f59b15b0 ti: f55c4000 task.ti: f55c4000
[ 46.888037] EIP: 0060:[<c03d94cd>] EFLAGS: 00010212 CPU: 0
[ 46.888037] EIP is at memcpy+0x1d/0x40
[ 46.888037] EAX: f56ac1c0 EBX: fffffff8 ECX: 3ffffc6e EDX: f55c5cf2
[ 46.888037] ESI: f55c6b32 EDI: f56ad000 EBP: f55c5c68 ESP: f55c5c5c
[ 46.888037] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[ 46.888037] CR0: 8005003b CR2: f56ad000 CR3: 3557d000 CR4: 000006f0
[ 46.888037] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
[ 46.888037] DR6: ffff0ff0 DR7: 00000400
[ 46.888037] Stack:
[ 46.888037] fffffff8 00000010 00000003 f55c5cac f8c6a54c ffffffff f8c69eb2 00000000
[ 46.888037] f4783cdc f57f0070 f759c590 1001c580 00000003 0200000a 00000000 f5a88560
[ 46.888037] f5ba2600 f5a88560 00000041 00000000 f55c5d90 f8c6f4c7 00000008 f55c5cf2
[ 46.888037] Call Trace:
[ 46.888037] [<f8c6a54c>] l2cap_send_cmd+0x1cc/0x230 [bluetooth]
[ 46.888037] [<f8c69eb2>] ? l2cap_global_chan_by_psm+0x152/0x1a0 [bluetooth]
[ 46.888037] [<f8c6f4c7>] l2cap_connect+0x3f7/0x540 [bluetooth]
[ 46.888037] [<c019b37b>] ? trace_hardirqs_off+0xb/0x10
[ 46.888037] [<c01a0ff8>] ? mark_held_locks+0x68/0x110
[ 46.888037] [<c064ad20>] ? mutex_lock_nested+0x280/0x360
[ 46.888037] [<c064b9d9>] ? __mutex_unlock_slowpath+0xa9/0x150
[ 46.888037] [<c01a118c>] ? trace_hardirqs_on_caller+0xec/0x1b0
[ 46.888037] [<c064ad08>] ? mutex_lock_nested+0x268/0x360
[ 46.888037] [<c01a125b>] ? trace_hardirqs_on+0xb/0x10
[ 46.888037] [<f8c72f8d>] l2cap_recv_frame+0xb2d/0x1d30 [bluetooth]
[ 46.888037] [<c01a0ff8>] ? mark_held_locks+0x68/0x110
[ 46.888037] [<c064b9d9>] ? __mutex_unlock_slowpath+0xa9/0x150
[ 46.888037] [<c01a118c>] ? trace_hardirqs_on_caller+0xec/0x1b0
[ 46.888037] [<f8c754f1>] l2cap_recv_acldata+0x2a1/0x320 [bluetooth]
[ 46.888037] [<f8c491d8>] hci_rx_work+0x518/0x810 [bluetooth]
[ 46.888037] [<f8c48df2>] ? hci_rx_work+0x132/0x810 [bluetooth]
[ 46.888037] [<c0158979>] process_one_work+0x1a9/0x600
[ 46.888037] [<c01588fb>] ? process_one_work+0x12b/0x600
[ 46.888037] [<c015922e>] ? worker_thread+0x19e/0x320
[ 46.888037] [<c015922e>] ? worker_thread+0x19e/0x320
[ 46.888037] [<c0159187>] worker_thread+0xf7/0x320
[ 46.888037] [<c0159090>] ? rescuer_thread+0x290/0x290
[ 46.888037] [<c01602f8>] kthread+0xa8/0xb0
[ 46.888037] [<c0656777>] ret_from_kernel_thread+0x1b/0x28
[ 46.888037] [<c0160250>] ? flush_kthread_worker+0x120/0x120
[ 46.888037] Code: c3 90 8d 74 26 00 e8 63 fc ff ff eb e8 90 55 89 e5 83 ec 0c 89 5d f4 89 75 f8 89 7d fc 3e 8d 74 26 00 89 cb 89 c7 c1 e9 02 89 d6 <f3> a5 89 d9 83 e1 03 74 02 f3 a4 8b 5d f4 8b 75 f8 8b 7d fc 89
[ 46.888037] EIP: [<c03d94cd>] memcpy+0x1d/0x40 SS:ESP 0068:f55c5c5c
[ 46.888037] CR2: 00000000f56ad000
[ 46.888037] ---[ end trace 0217c1f4d78714a9 ]---
Signed-off-by: Anderson Lizardo <anderson.lizardo@openbossa.org>
Cc: stable@vger.kernel.org
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|\ \
| | |
| | |
| | | |
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Since driver does not use control.rates[0].count, we have never set that
variable. But currently, after rate control API rewrite, this is required
by mac80211. Otherwise legacy rates control does not work and we transmit
always at 1Mbit/s on pre 11n networks.
[same fix as for iwlegacy, thanks Stanislaw!]
Signed-off-by: Moshe Benji <Moshe.Benji@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Somehow, the Tx flags for BAR were completely wrong.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
First step of chain noise calibration process had disable flag
check inverted. Chain noise calibration never started because
of this.
Tested on intel 5300 with two antennas attached. The driver
correctly disabled one chain.
Cc: stable@vger.kernel.org
Signed-off-by: Nikolay Martynov <mar.kolya@gmail.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
If the opmode modules aren't modular, there's no point in
printing an error message that request_module() failed.
This will happen because the probe runs during iwlwifi's
init and the opmode is only added during its init.
Reported-by: Jörg Otte <jrg.otte@gmail.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|\ \ \
| | |/
| |/|
| | | |
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The order of parameters was mixed up, introduced in commit
"mac80211: improve the rate control API"
Cc: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When a CAC is running and stop_ap is called (e.g. when hostapd is killed
while performing CAC), the CAC must be aborted immediately.
Otherwise ieee80211_stop_ap() will try to stop it when it's too late -
wdev->channel is already NULL and the abort event can not be generated.
Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
There are some APs, notably 2G/3G/4G Wifi routers, specifically the
"Onda PN51T", "Vodafone PocketWiFi 2", "ZTE MF60" and a similar
T-Mobile branded device [1] that erroneously don't include all the
needed information in (re)association response frames. Work around
this by assuming the information is the same as it was in the
beacon or probe response and using the data from there instead.
This fixes https://bugzilla.kernel.org/show_bug.cgi?id=58881.
[1] https://bbs.archlinux.org/viewtopic.php?pid=1277305
Note that this requires marking the first ieee802_11_parse_elems()
argument const, otherwise we'd get a compiler warning.
Cc: stable@vger.kernel.org
Reported-and-tested-by: Michal Zajac <manwe@manwe.pl>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
My change:
commit cee2c7315f60beeff6137ee59e99acc77d636eeb
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date: Fri Oct 5 13:44:09 2012 +0200
rt2800: use BBP_R1 for setting tx power
unfortunately does not work well with RT5390 and RT3290 chips as they
require different temperature compensation TX power settings (TSSI
tuning). Since that commit make wireless connection very unstable on
those chips, restore previous behavior to fix regression. Once we
implement proper TSSI tuning on 5390/3290 we can restore back setting
TX power by BBP_R1 register for those chips.
Reported-and-tested-by: Mike Romberg <mike-romberg@comcast.net>
Cc: stable@vger.kernel.org
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>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This patch fixes a regression introduced by:
commit 6da3b6c48d79da96a36c2632053cf4f53bf48fb2
Author: Hauke Mehrtens <hauke@hauke-m.de>
Date: Sun Mar 24 01:45:52 2013 +0100
brcmsmac: remove brcms_bss_cfg->associated
The regression behaviour was described on mailing list.
http://mid.gmane.org/5197DC4F.7030503@broadcom.com:
"On laptop I installed kernel with brcmsmac compiled as
module. It comes up and associates during boot, but after
logging in there is no connectivity. Triggering reassoc
gives connectivity for some time, but after a while (1-2 min)
it stops."
Before the mentioned commit the return value of
the function brcms_c_ps_allowed() was always false,
which is desired behaviour as power-save is not
supported at the moment. Therefor, the function is
changed to just return false instead of simply
reverting the mentioned commit.
Bug: 58471 <https://bugzilla.kernel.org/show_bug.cgi?id=58471>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Since driver does not use control.rates[0].count, we have never set that
variable. But currently, after rate control API rewrite, this is required
by mac80211. Otherwise legacy rates control does not work and we transmit
always at 1Mbit/s on pre 11n networks.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The module parameter "fwpostfix" is userspace controllable, unfiltered,
and is used to define the firmware filename. b43_do_request_fw() populates
ctx->errors[] on error, containing the firmware filename. b43err()
parses its arguments as a format string. For systems with b43 hardware,
this could lead to a uid-0 to ring-0 escalation.
CVE-2013-2852
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: stable@vger.kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The ath9k rate control algorithm has various architectural
issues that make it a poor fit in scenarios like congested
environments etc.
An example: https://bugzilla.redhat.com/show_bug.cgi?id=927191
Change the default to minstrel which is more robust in such cases.
The ath9k RC code is left in the driver for now, maybe it can
be removed altogether later on.
Cc: stable@vger.kernel.org
Cc: Jouni Malinen <jouni@qca.qualcomm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This reverts commit 68d9e1fa24d9c7c2e527f49df8d18fb8cf0ec943
This change reduces rx sensitivity with no apparent extra benefit.
It looks like it was meant for testing in a specific scenario,
but it was never properly validated.
Cc: rmanohar@qca.qualcomm.com
Cc: stable@vger.kernel.org
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Almost all the DMA issues which have plagued ath9k (in station mode)
for years are related to PS. Disabling PS usually "fixes" the user's
connection stablility. Reports of DMA problems are still trickling in
and are sitting in the kernel bugzilla. Until the PS code in ath9k is
given a thorough review, disbale it by default. The slight increase
in chip power consumption is a small price to pay for improved link
stability.
Cc: stable@vger.kernel.org
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Fix build error for il_pm_ops if CONFIG_PM is set
but CONFIG_PM_SLEEP is not set.
ERROR: "il_pm_ops" [drivers/net/wireless/iwlegacy/iwl4965.ko] undefined!
ERROR: "il_pm_ops" [drivers/net/wireless/iwlegacy/iwl3945.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Cc: Stanislaw Gruszka <sgruszka@redhat.com>
Cc: "John W. Linville" <linville@tuxdriver.com>
Cc: netdev@vger.kernel.org
Cc: linux-wireless@vger.kernel.org
Cc: Jingoo Han <jg1.han@samsung.com>
Acked-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This false leak indication is avoided with a no-leak annotation to kmemleak.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Due to a typo, the current code copies only sizeof(cmd->channels_2)
bytes, which is smaller than the correct sizeof(cmd->channels_5)
size, resulting in a partial scan (some channels are skipped).
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The minimum firmware version required for singlerole after recent
driver changes is 6/7.3.10.0.133.
Reported-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
There was a typo in commit 8675f9 (wlcore/wl12xx/wl18xx: verify
multi-role and single-role fw versions), which was causing the
multirole firmware for wl127x (WiLink6) to be rejected. The actual
minimum version needed for wl127x multirole is 6.5.7.0.42.
Reported-by: Levi Pearson <levipearson@gmail.com>
Reported-by: Michael Scott <hashcode0f@gmail.com>
Cc: stable@kernel.org # 3.9+
Signed-off-by: Luciano Coelho <coelho@ti.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Driver rtl8192cu can connect to WPA2 networks, but fails for any other
encryption method. The cause is a failure to set the rate control data
blocks. These changes fix https://bugzilla.redhat.com/show_bug.cgi?id=952793
and https://bugzilla.redhat.com/show_bug.cgi?id=761525.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When reading the contents of '/sys/kernel/debug/mwifiex/p2p0/info',
the following panic occurs:
$ cat /sys/kernel/debug/mwifiex/p2p0/info
Unable to handle kernel paging request at virtual address 74706164
pgd = de530000
[74706164] *pgd=00000000
Internal error: Oops: 5 [#1] SMP ARM
Modules linked in: phy_twl4030_usb omap2430 musb_hdrc mwifiex_sdio mwifiex
CPU: 0 PID: 1635 Comm: cat Not tainted 3.10.0-rc1-00010-g1268390 #1
task: de16b6c0 ti: de048000 task.ti: de048000
PC is at strnlen+0xc/0x4c
LR is at string+0x3c/0xf8
pc : [<c02c123c>] lr : [<c02c2d1c>] psr: a0000013
sp : de049e10 ip : c06efba0 fp : de6d2092
r10: bf01a260 r9 : ffffffff r8 : 74706164
r7 : 0000ffff r6 : ffffffff r5 : de6d209c r4 : 00000000
r3 : ff0a0004 r2 : 74706164 r1 : ffffffff r0 : 74706164
Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Control: 10c5387d Table: 9e530019 DAC: 00000015
Process cat (pid: 1635, stack limit = 0xde048240)
Stack: (0xde049e10 to 0xde04a000)
9e00: de6d2092 00000002 bf01a25e de6d209c
9e20: de049e80 c02c438c 0000000a ff0a0004 ffffffff 00000000 00000000 de049e48
9e40: 00000000 2192df6d ff0a0004 ffffffff 00000000 de6d2092 de049ef8 bef3cc00
9e60: de6b0000 dc358000 de6d2000 00000000 00000003 c02c45a4 bf01790c bf01a254
9e80: 74706164 bf018698 00000000 de59c3c0 de048000 de049f80 00001000 bef3cc00
9ea0: 00000008 00000000 00000000 00000000 00000000 00000000 00000000 00000000
9ec0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
9ee0: 00000000 00000000 00000000 00000001 00000000 00000000 6669776d 20786569
9f00: 20302e31 2e343128 392e3636 3231702e 00202933 00000000 00000003 c0294898
9f20: 00000000 00000000 00000000 00000000 de59c3c0 c0107c04 de554000 de59c3c0
9f40: 00001000 bef3cc00 de049f80 bef3cc00 de049f80 00000000 00000003 c0108a00
9f60: de048000 de59c3c0 00000000 00000000 de59c3c0 00001000 bef3cc00 c0108b60
9f80: 00000000 00000000 00001000 bef3cc00 00000003 00000003 c0014128 de048000
9fa0: 00000000 c0013f80 00001000 bef3cc00 00000003 bef3cc00 00001000 00000000
9fc0: 00001000 bef3cc00 00000003 00000003 00000001 00000001 00000001 00000003
9fe0: 00000000 bef3cbdc 00011984 b6f1127c 60000010 00000003 18dbdd2c 7f7bfffd
[<c02c123c>] (strnlen+0xc/0x4c) from [<c02c2d1c>] (string+0x3c/0xf8)
[<c02c2d1c>] (string+0x3c/0xf8) from [<c02c438c>] (vsnprintf+0x1e8/0x3e8)
[<c02c438c>] (vsnprintf+0x1e8/0x3e8) from [<c02c45a4>] (sprintf+0x18/0x24)
[<c02c45a4>] (sprintf+0x18/0x24) from [<bf01790c>] (mwifiex_info_read+0xfc/0x3e8 [mwifiex])
[<bf01790c>] (mwifiex_info_read+0xfc/0x3e8 [mwifiex]) from [<c0108a00>] (vfs_read+0xb0/0x144)
[<c0108a00>] (vfs_read+0xb0/0x144) from [<c0108b60>] (SyS_read+0x44/0x70)
[<c0108b60>] (SyS_read+0x44/0x70) from [<c0013f80>] (ret_fast_syscall+0x0/0x30)
Code: e12fff1e e3510000 e1a02000 0a00000d (e5d03000)
---[ end trace ca98273dc605a04f ]---
The panic is caused by the mwifiex_info_read() routine assuming that
there can only be four modes (0-3) which is an invalid assumption.
For example, when testing P2P, the mode is '8' (P2P_CLIENT) so the
code accesses data beyond the bounds of the bss_modes[] array which
causes the panic. Fix this by updating bss_modes[] to support the
current list of modes and adding a check to prevent the out-of-bounds
access from occuring in the future when more modes are added.
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
Acked-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
If hci_dev_open fails we need to ensure that the corresponding
mgmt_set_powered command gets an appropriate response. This patch fixes
the missing response by adding a new mgmt_set_powered_failed function
that's used to indicate a power on failure to mgmt. Since a situation
with the device being rfkilled may require special handling in user
space the patch uses a new dedicated mgmt status code for this.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Cc: stable@vger.kernel.org
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
There has been code in place to check that the L2CAP length header
matches the amount of data received, but many PDU handlers have not been
checking that the data received actually matches that expected by the
specific PDU. This patch adds passing the length header to the specific
handler functions and ensures that those functions fail cleanly in the
case of an incorrect amount of data.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The register offsets have been changed in SD8897 and newer chips.
Define a new btmrvl_sdio_card_reg map for SD88xx.
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: Frank Huang <frankh@marvell.com>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
LE-only controllers do not support extended features so any kind of host
feature bit checks do not make sense for them. This patch fixes code
used for both single-mode (LE-only) and dual-mode (BR/EDR/LE) to use the
HCI_LE_ENABLED flag instead of the "Host LE supported" feature bit for
LE support tests.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Accessing the OTP memory on AR9950 causes a data bus
like this:
Data bus error, epc == 801f7774, ra == 801f7774
Oops[#1]:
CPU: 0 PID: 1 Comm: swapper Not tainted 3.10.0-rc3 #592
task: 87c28000 ti: 87c22000 task.ti: 87c22000
$ 0 : 00000000 00000061 deadc0de 00000000
$ 4 : b8115f18 00015f18 00000007 00000004
$ 8 : 00000001 7c7c3c7c 7c7c7c7c 7c7c7c7c
$12 : 7c7c3c7c 80320a68 00000000 7c7c7c3c
$16 : 87cd8010 00015f18 00000007 00000000
$20 : 00000064 00000004 87c23c7c 8035210c
$24 : 00000000 801f3674
$28 : 87c22000 87c23b48 00000001 801f7774
Hi : 00000000
Lo : 00000064
epc : 801f7774 ath9k_hw_wait+0x58/0xb0
Not tainted
ra : 801f7774 ath9k_hw_wait+0x58/0xb0
Status: 1000cc03 KERNEL EXL IE
Cause : 4080801c
PrId : 00019750 (MIPS 74Kc)
Modules linked in:
Process swapper (pid: 1, threadinfo=87c22000, task=87c28000, ts=00000000)
Stack : 0000000f 00000061 00002710 8006240c 00000001 87cd8010 87c23bb0 87cd8010
00000000 00000004 00000003 80210c7c 000000b3 67fa8000 0000032a 000006fe
000003e8 00000002 00000028 87c23bf0 000003ff 80210d24 803e5630 80210e28
00000000 00000007 87cd8010 00007044 00000004 00000061 000003ff 000001ff
87c26000 87cd8010 00000220 87cd8bb8 80210000 8020fcf4 87c22000 87c23c08
...
Call Trace:
[<801f7774>] ath9k_hw_wait+0x58/0xb0
[<80210c7c>] ar9300_otp_read_word+0x80/0xd4
[<80210d24>] ar9300_read_otp+0x54/0xb0
[<8020fcf4>] ar9300_check_eeprom_header+0x1c/0x40
[<80210fe4>] ath9k_hw_ar9300_fill_eeprom+0x118/0x39c
[<80206650>] ath9k_hw_eeprom_init+0x74/0xb4
[<801f96d0>] ath9k_hw_init+0x7ec/0x96c
[<801e65ec>] ath9k_init_device+0x340/0x758
[<801f35d0>] ath_ahb_probe+0x21c/0x2c0
[<801c041c>] driver_probe_device+0xc0/0x1e4
[<801c05ac>] __driver_attach+0x6c/0xa4
[<801bea08>] bus_for_each_dev+0x64/0xa8
[<801bfa40>] bus_add_driver+0xcc/0x24c
[<801c0954>] driver_register+0xbc/0x17c
[<803f8fc0>] ath9k_init+0x5c/0x88
[<800608fc>] do_one_initcall+0xec/0x1a0
[<803e6a68>] kernel_init_freeable+0x13c/0x200
[<80309cdc>] kernel_init+0x1c/0xe4
[<80062450>] ret_from_kernel_thread+0x10/0x18
On the AR9550, the OTP registers are located at
the same address as on the AR9340. Use the correct
values to avoid the error.
Cc: stable@vger.kernel.org # 3.6+
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
For p2p client mode powersave mode should be kept disabled. It is
working but inefficient. In general p2p links do no benefit from this
mode, because these links are setup temporarily to transfer data.
Reviewed-by: Arend Van Spriel <arend@broadcom.com>
Signed-off-by: Hante Meuleman <meuleman@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Multi channel support was disabled. This patch will enable it and
configure the P2P GO on the correct frequency when multi channel
is used.
Reviewed-by: Arend Van Spriel <arend@broadcom.com>
Signed-off-by: Hante Meuleman <meuleman@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Upon deleting a P2P_CLIENT/GO interface the vif and consequently
the wdev is freed before the net_device is actually being unregistered
but cfg80211 still needs to access the wdev. Using destructor field
to free the net_device and vif.
Reviewed-by: Hante Meuleman <meuleman@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When registration fails the net device is no longer needed. Free
the net device and remove reference to private data from the
driver.
Reviewed-by: Hante Meuleman <meuleman@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Pass the struct brcmf_cfg80211_info instance instead of obtaining
through vif itself using vif->wdev. This is needed as the netdev
associated with this vif is already unregistered.
Reviewed-by: Hante Meuleman <meuleman@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The firmware requires that on p2p setup when net interfaces
are created or updated that they start initially with the same
channel as the channel in use for the current connection
(if any). If none exists take default channel 11.
Reviewed-by: Arend Van Spriel <arend@broadcom.com>
Reviewed-by: Franky (Zhenhui) Lin <frankyl@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: Hante Meuleman <meuleman@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
ARP offloading should only be used in STA or P2P client mode. It
is currently configured once at init. When being configured for AP
ARP offloading should be turned off and when AP mode is left it can
be turned back on.
Cc: stable@vger.kernel.org
Reviewed-by: Arend Van Spriel <arend@broadcom.com>
Signed-off-by: Hante Meuleman <meuleman@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|\ \ \
| | |/
| |/|
| | | |
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In 63b77bf489881747c5118476918cc8c29378ee63
iwlwifi: dvm: don't send zeroed LQ cmd
I tried to avoid to send zeroed LQ cmd, but I made a (very)
stupid mistake in the memcmp.
Since this patch has been ported to stable, the fix should
go to stable too.
This fixes https://bugzilla.kernel.org/show_bug.cgi?id=58341
Cc: stable@vger.kernel.org
Reported-by: Hinnerk van Bruinehsen <h.v.bruinehsen@fu-berlin.de>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|\ \ \
| | |/
| |/|
| | | |
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When changing the MAC address of a single vif mac80211 will check if
the new address fits into the address mask specified by the driver.
This only needs to be done when using multiple BSSIDs. Hence, check
the new address only against all other vifs.
Also fix the MAC address assignment on new interfaces if the user
changed the address of a vif such that perm_addr is not covered by
addr_mask anymore.
Resolves:
https://bugzilla.kernel.org/show_bug.cgi?id=57371
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: Jakub Kicinski <kubakici@wp.pl>
Reported-by: Alessandro Lannocca <alessandro.lannocca@gmail.com>
Cc: Alessandro Lannocca <alessandro.lannocca@gmail.com>
Cc: Bruno Randolf <br1@thinktube.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Since Eric's commit efe117ab8 ("Speedup ieee80211_remove_interfaces")
there's a bug in mac80211 when it unregisters with AP_VLAN interfaces
up. If the AP_VLAN interface was registered after the AP it belongs
to (which is the typical case) and then we get into this code path,
unregister_netdevice_many() will crash because it isn't prepared to
deal with interfaces being closed in the middle of it. Exactly this
happens though, because we iterate the list, find the AP master this
AP_VLAN belongs to and dev_close() the dependent VLANs. After this,
unregister_netdevice_many() won't pick up the fact that the AP_VLAN
is already down and will do it again, causing a crash.
Cc: stable@vger.kernel.org [2.6.33+]
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
A lot of code in mac80211 assumes that the hw queues are
set up correctly for all interfaces (except for monitor)
but this isn't true for AP_VLAN interfaces. Fix this by
copying the AP master configuration when an AP VLAN is
brought up, after this the AP interface can't change its
configuration any more and needs to be brought down to
change it, which also forces AP_VLAN interfaces down, so
just copying in open() is sufficient.
Reported-by: Jouni Malinen <j@w1.fi>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|