summaryrefslogtreecommitdiff
path: root/drivers/net/wireless
AgeCommit message (Collapse)AuthorFilesLines
2014-11-18upstream: treewide: Fix typos in printkMasanari Iida1-1/+1
Correct spelling typo in various part of kernel Signed-off-by: Masanari Iida <standby24x7@gmail.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Conflicts: arch/arm64/kvm/handle_exit.c arch/mips/ralink/cevt-rt3352.c arch/mips/ralink/timer.c drivers/gpu/drm/exynos/exynos_drm_fimc.c drivers/i2c/busses/i2c-exynos5.c drivers/iio/adc/twl6030-gpadc.c fs/btrfs/tests/free-space-tests.c net/nfc/digital_dep.c
2014-11-18upstream: drivers: avoid parsing names as kthread_run() format stringsKees Cook1-1/+2
Calling kthread_run with a single name parameter causes it to be handled as a format string. Many callers are passing potentially dynamic string content, so use "%s" in those cases to avoid any potential accidents. Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-11-18upstream: drivers: avoid format strings in names passed to alloc_workqueue()Kees Cook2-2/+2
For the workqueue creation interfaces that do not expect format strings, make sure they cannot accidently be parsed that way. Additionally, clean up calls made with a single parameter that would be handled as a format string. Many callers are passing potentially dynamic string content, so use "%s" in those cases to avoid any potential accidents. Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-11-18brcmfmac: Add generic platform supportTomasz Figa1-0/+78
This patch adds basic support for generic platforms that do not require special platform data. Signed-off-by: Tomasz Figa <t.figa@samsung.com>
2014-11-14wireless: rt2x00: add new rt2800usb deviceCyril Brulebois1-0/+1
commit 664d6a792785cc677c2091038ce10322c8d04ae1 upstream. 0x1b75 0xa200 AirLive WN-200USB wireless 11b/g/n dongle References: https://bugs.debian.org/766802 Reported-by: Martin Mokrejs <mmokrejs@fold.natur.cuni.cz> Signed-off-by: Cyril Brulebois <kibi@debian.org> Acked-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-30rt2800: correct BBP1_TX_POWER_CTRL maskStanislaw Gruszka1-1/+1
commit 01f7feeaf4528bec83798316b3c811701bac5d3e upstream. Two bits control TX power on BBP_R1 register. Correct the mask, otherwise we clear additional bit on BBP_R1 register, what can have unknown, possible negative effect. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-30iwlwifi: Add missing PCI IDs for the 7260 seriesOren Givon1-0/+4
commit 4f08970f5284dce486f0e2290834aefb2a262189 upstream. Add 4 missing PCI IDs for the 7260 series. Signed-off-by: Oren Givon <oren.givon@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-05rtlwifi: rtl8192cu: Add new IDLarry Finger1-0/+1
commit c66517165610b911e4c6d268f28d8c640832dbd1 upstream. The Sitecom WLA-2102 adapter uses this driver. Reported-by: Nico Baggus <nico-linux@noci.xs4all.nl> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Cc: Nico Baggus <nico-linux@noci.xs4all.nl> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-05Revert "iwlwifi: dvm: don't enable CTS to self"Emmanuel Grumbach1-0/+12
commit f47f46d7b09cf1d09e4b44b6cc4dd7d68a08028c upstream. This reverts commit 43d826ca5979927131685cc2092c7ce862cb91cd. This commit caused packet loss. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-05carl9170: fix sending URBs with wrong type when using full-speedRonald Wahl2-4/+28
commit 671796dd96b6cd85b75fba9d3007bcf7e5f7c309 upstream. The driver assumes that endpoint 4 is always an interrupt endpoint. Unfortunately the type differs between high-speed and full-speed configurations while in the former case it is indeed an interrupt endpoint this is not true for the latter case - here it is a bulk endpoint. When sending URBs with the wrong type the kernel will generate a warning message including backtrace. In this specific case there will be a huge amount of warnings which can bring the system to freeze. To fix this we are now sending URBs to endpoint 4 using the type found in the endpoint descriptor. A side note: The carl9170 firmware currently specifies endpoint 4 as interrupt endpoint even in the full-speed configuration but this has no relevance because before this firmware is loaded the endpoint type is as described above and after the firmware is running the stick is not reenumerated and so the old descriptor is used. Signed-off-by: Ronald Wahl <ronald.wahl@raritan.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-07-28mwifiex: fix Tx timeout issueAmitkumar Karwar1-0/+1
commit d76744a93246eccdca1106037e8ee29debf48277 upstream. https://bugzilla.kernel.org/show_bug.cgi?id=70191 https://bugzilla.kernel.org/show_bug.cgi?id=77581 It is observed that sometimes Tx packet is downloaded without adding driver's txpd header. This results in firmware parsing garbage data as packet length. Sometimes firmware is unable to read the packet if length comes out as invalid. This stops further traffic and timeout occurs. The root cause is uninitialized fields in tx_info(skb->cb) of packet used to get garbage values. In this case if MWIFIEX_BUF_FLAG_REQUEUED_PKT flag is mistakenly set, txpd header was skipped. This patch makes sure that tx_info is correctly initialized to fix the problem. Reported-by: Andrew Wiley <wiley.andrew.j@gmail.com> Reported-by: Linus Gasser <list@markas-al-nour.org> Reported-by: Michael Hirsch <hirsch@teufel.de> Tested-by: Xinming Hu <huxm@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Maithili Hinge <maithili@marvell.com> Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-07-28iwlwifi: dvm: don't enable CTS to selfEmmanuel Grumbach1-12/+0
commit 43d826ca5979927131685cc2092c7ce862cb91cd upstream. We should always prefer to use full RTS protection. Using CTS to self gives a meaningless improvement, but this flow is much harder for the firmware which is likely to have issues with it. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-07-09b43: fix frequency reported on G-PHY with /new/ firmwareRafał Miłecki1-3/+7
commit 2fc68eb122c7ea6cd5be1fe7d6650c0beb2f4f40 upstream. Support for firmware rev 508+ was added years ago, but we never noticed it reports channel in a different way for G-PHY devices. Instead of offset from 2400 MHz it simply passes channel id (AKA hw_value). So far it was (most probably) affecting monitor mode users only, but the following recent commit made it noticeable for quite everybody: commit 3afc2167f60a327a2c1e1e2600ef209a3c2b75b7 Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Date: Tue Mar 4 16:50:13 2014 +0200 cfg80211/mac80211: ignore signal if the frame was heard on wrong channel Reported-by: Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-07-09iwlwifi: pcie: try to get ownership several timesEmmanuel Grumbach1-10/+16
commit 501fd9895c1d7d8161ed56698ae2fccb10ef14f5 upstream. Some races with the hardware can happen when we take ownership of the device. Don't give up after the first try. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-07-09rt2x00: fix rfkill regression on rt2500pciStanislaw Gruszka3-4/+28
commit 616a8394b5df8c88f4dd416f4527439a4e365034 upstream. As reported by Niels, starting rfkill polling during device probe (commit e2bc7c5, generally sane change) broke rfkill on rt2500pci device. I considered that bug as some initalization issue, which should be fixed on rt2500pci specific code. But after several attempts (see bug report for details) we fail to find working solution. Hence I decided to revert to old behaviour on rt2500pci to fix regression. Additionally patch also unregister rfkill on device remove instead of ifconfig down, what was another issue introduced by bad commit. Bug report: https://bugzilla.kernel.org/show_bug.cgi?id=73821 Fixes: e2bc7c5f3cb8 ("rt2x00: Fix rfkill_polling register function.") Bisected-by: Niels <nille0386@googlemail.com> Reported-and-tested-by: Niels <nille0386@googlemail.com> Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-07-09rt2x00: disable TKIP on USBStanislaw Gruszka1-0/+2
commit 8edcb0ba0d56f5914eef11eda6db8bfe74eb9ca8 upstream. On USB we can not get atomically TKIP key. We have to disable support for TKIP acceleration on USB hardware to avoid bug as showed bellow. [ 860.827243] BUG: scheduling while atomic: hostapd/3397/0x00000002 <snip> [ 860.827280] Call Trace: [ 860.827282] [<ffffffff81682ea6>] dump_stack+0x4d/0x66 [ 860.827284] [<ffffffff8167eb9b>] __schedule_bug+0x47/0x55 [ 860.827285] [<ffffffff81685bb3>] __schedule+0x733/0x7b0 [ 860.827287] [<ffffffff81685c59>] schedule+0x29/0x70 [ 860.827289] [<ffffffff81684f8a>] schedule_timeout+0x15a/0x2b0 [ 860.827291] [<ffffffff8105ac50>] ? ftrace_raw_event_tick_stop+0xc0/0xc0 [ 860.827294] [<ffffffff810c13c2>] ? __module_text_address+0x12/0x70 [ 860.827296] [<ffffffff81686823>] wait_for_completion_timeout+0xb3/0x140 [ 860.827298] [<ffffffff81080fc0>] ? wake_up_state+0x20/0x20 [ 860.827301] [<ffffffff814d5b3d>] usb_start_wait_urb+0x7d/0x150 [ 860.827303] [<ffffffff814d5cd5>] usb_control_msg+0xc5/0x110 [ 860.827305] [<ffffffffa02fb0c6>] rt2x00usb_vendor_request+0xc6/0x160 [rt2x00usb] [ 860.827307] [<ffffffffa02fb215>] rt2x00usb_vendor_req_buff_lock+0x75/0x150 [rt2x00usb] [ 860.827309] [<ffffffffa02fb393>] rt2x00usb_vendor_request_buff+0xa3/0xe0 [rt2x00usb] [ 860.827311] [<ffffffffa023d1a3>] rt2x00usb_register_multiread+0x33/0x40 [rt2800usb] [ 860.827314] [<ffffffffa05805f9>] rt2800_get_tkip_seq+0x39/0x50 [rt2800lib] [ 860.827321] [<ffffffffa0480f88>] ieee80211_get_key+0x218/0x2a0 [mac80211] [ 860.827322] [<ffffffff815cc68c>] ? __nlmsg_put+0x6c/0x80 [ 860.827329] [<ffffffffa051b02e>] nl80211_get_key+0x22e/0x360 [cfg80211] Reported-and-tested-by: Peter Wu <lekensteyn@gmail.com> Reported-and-tested-by: Pontus Fuchs <pontus.fuchs@gmail.com> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-07ath9k: protect tid->sched checkStanislaw Gruszka1-3/+5
[ Upstream commit 21f8aaee0c62708654988ce092838aa7df4d25d8 ] We check tid->sched without a lock taken on ath_tx_aggr_sleep(). That is race condition which can result of doing list_del(&tid->list) twice (second time with poisoned list node) and cause crash like shown below: [424271.637220] BUG: unable to handle kernel paging request at 00100104 [424271.637328] IP: [<f90fc072>] ath_tx_aggr_sleep+0x62/0xe0 [ath9k] ... [424271.639953] Call Trace: [424271.639998] [<f90f6900>] ? ath9k_get_survey+0x110/0x110 [ath9k] [424271.640083] [<f90f6942>] ath9k_sta_notify+0x42/0x50 [ath9k] [424271.640177] [<f809cfef>] sta_ps_start+0x8f/0x1c0 [mac80211] [424271.640258] [<c10f730e>] ? free_compound_page+0x2e/0x40 [424271.640346] [<f809e915>] ieee80211_rx_handlers+0x9d5/0x2340 [mac80211] [424271.640437] [<c112f048>] ? kmem_cache_free+0x1d8/0x1f0 [424271.640510] [<c1345a84>] ? kfree_skbmem+0x34/0x90 [424271.640578] [<c10fc23c>] ? put_page+0x2c/0x40 [424271.640640] [<c1345a84>] ? kfree_skbmem+0x34/0x90 [424271.640706] [<c1345a84>] ? kfree_skbmem+0x34/0x90 [424271.640787] [<f809dde3>] ? ieee80211_rx_handlers_result+0x73/0x1d0 [mac80211] [424271.640897] [<f80a07a0>] ieee80211_prepare_and_rx_handle+0x520/0xad0 [mac80211] [424271.641009] [<f809e22d>] ? ieee80211_rx_handlers+0x2ed/0x2340 [mac80211] [424271.641104] [<c13846ce>] ? ip_output+0x7e/0xd0 [424271.641182] [<f80a1057>] ieee80211_rx+0x307/0x7c0 [mac80211] [424271.641266] [<f90fa6ee>] ath_rx_tasklet+0x88e/0xf70 [ath9k] [424271.641358] [<f80a0f2c>] ? ieee80211_rx+0x1dc/0x7c0 [mac80211] [424271.641445] [<f90f82db>] ath9k_tasklet+0xcb/0x130 [ath9k] Bug report: https://bugzilla.kernel.org/show_bug.cgi?id=70551 Reported-and-tested-by: Max Sydorenko <maxim.stargazer@gmail.com> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> [ xl: backported to 3.10: adjusted context ] Signed-off-by: Xiangyu Lu <luxiangyu@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-07brcmsmac: fix deadlock on missing firmwareEmil Goode1-8/+6
commit 8fc1e8c240aab968db658b2d8d079b4391207a36 upstream. When brcm80211 firmware is not installed networking hangs. A deadlock happens because we call ieee80211_unregister_hw() from the .start callback of struct ieee80211_ops. When .start is called we are under rtnl lock and ieee80211_unregister_hw() tries to take it again. Function call stack: dev_change_flags() __dev_change_flags() __dev_open() ASSERT_RTNL() <-- Assert rtnl lock ops->ndo_open() .ndo_open = ieee80211_open, ieee80211_open() ieee80211_do_open() drv_start() local->ops->start() .start = brcms_ops_start, brcms_ops_start() brcms_remove() ieee80211_unregister_hw() rtnl_lock() <-- Here we deadlock Introduced by: commit 25b5632fb35ca61b8ae3eee235edcdc2883f7a5e ("brcmsmac: request firmware in .start() callback") This patch fixes the bug by removing the call to brcms_remove() and moves the brcms_request_fw() call to the top of the .start callback to not initiate anything unless firmware is installed. Signed-off-by: Emil Goode <emilgoode@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-07rtl8192cu: Fix unbalanced irq enable in error path of rtl92cu_hw_init()Ben Hutchings1-1/+1
commit 3234f5b06fc3094176a86772cc64baf3decc98fc upstream. Fixes: a53268be0cb9 ('rtlwifi: rtl8192cu: Fix too long disable of IRQs') Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-07rt2x00: fix beaconing on USBStanislaw Gruszka1-10/+12
commit 8834d3608cc516f13e2e510f4057c263f3d2ce42 upstream. When disable beaconing we clear register with beacon and newer set it back, what make we stop send beacons infinitely. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-13rtlwifi: rtl8188ee: initialize packet_beaconColin Ian King1-1/+1
commit 328e203fc35f0b4f6df1c4943f74cf553bcc04f8 upstream. static code analysis from cppcheck reports: [drivers/net/wireless/rtlwifi/rtl8188ee/trx.c:322]: (error) Uninitialized variable: packet_beacon packet_beacon is not initialized and hence packet_beacon contains garbage from the stack, so set it to false. Signed-off-by: Colin Ian King <colin.king@canonical.com> Acked-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-13rtlwifi: rtl8192se: Fix regression due to commit 1bf4bbbLarry Finger1-0/+6
commit 5f9186990ec4579ee5b7a99b3254c29eda479f36 upstream. Beginning with kernel 3.13, this driver fails on some systems. The problem was bisected to: Commit 1bf4bbb4024dcdab5e57634dd8ae1072d42a53ac Author: Felix Fietkau <nbd@openwrt.org> Title: mac80211: send control port protocol frames to the VO queue There is noting wrong with the above commit. The regression occurs because V0 queue on RTL8192SE cards uses priority 6, not the usual 7. The fix is to modify the rtl8192se routine that sets the correct transmit queue. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=74541 Reported-by: Alex Miller <almiller_1@yahoo.co.uk> Tested-by: Alex Miller <almiller_1@yahoo.co.uk> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-13rtlwifi: rtl8192se: Fix too long disable of IRQsLarry Finger1-6/+21
commit 2610decdd0b3808ba20471a999835cfee5275f98 upstream. In commit f78bccd79ba3cd9d9664981b501d57bdb81ab8a4 entitled "rtlwifi: rtl8192ce: Fix too long disable of IRQs", Olivier Langlois <olivier@trillion01.com> fixed a problem caused by an extra long disabling of interrupts. This patch makes the same fix for rtl8192se. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-13rtlwifi: rtl8192cu: Fix too long disable of IRQsLarry Finger1-1/+14
commit a53268be0cb9763f11da4f6fe3fb924cbe3a7d4a upstream. In commit f78bccd79ba3cd9d9664981b501d57bdb81ab8a4 entitled "rtlwifi: rtl8192ce: Fix too long disable of IRQs", Olivier Langlois <olivier@trillion01.com> fixed a problem caused by an extra long disabling of interrupts. This patch makes the same fix for rtl8192cu. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-13rtlwifi: rtl8188ee: Fix too long disable of IRQsLarry Finger1-4/+16
commit 6b6392715856d563719991e9ce95e773491a8983 upstream. In commit f78bccd79ba3cd9d9664981b501d57bdb81ab8a4 entitled "rtlwifi: rtl8192ce: Fix too long disable of IRQs", Olivier Langlois <olivier@trillion01.com> fixed a problem caused by an extra long disabling of interrupts. This patch makes the same fix for rtl8188ee. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-13rtlwifi: rtl8723ae: Fix too long disable of IRQsLarry Finger1-3/+15
commit bfc1010c418a22cbebd8b1bd1e75dad6a527a609 upstream. In commit f78bccd79ba3cd9d9664981b501d57bdb81ab8a4 entitled "rtlwifi: rtl8192ce: Fix too long disable of IRQs", Olivier Langlois <olivier@trillion01.com> fixed a problem caused by an extra long disabling of interrupts. This patch makes the same fix for rtl8723ae. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-13iwlwifi: dvm: take mutex when sending SYNC BT config commandEmmanuel Grumbach1-2/+6
commit 82e5a649453a3cf23516277abb84273768a1592b upstream. There is a flow in which we send the host command in SYNC mode, but we don't take priv->mutex. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1046495 Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-13b43: Fix machine check error due to improper access of B43_MMIO_PSM_PHY_HDRRafał Miłecki1-7/+7
commit 12cd43c6ed6da7bf7c5afbd74da6959cda6d056b upstream. Register B43_MMIO_PSM_PHY_HDR is 16 bit one, so accessing it with 32b functions isn't safe. On my machine it causes delayed (!) CPU exception: Disabling lock debugging due to kernel taint mce: [Hardware Error]: CPU 0: Machine Check Exception: 4 Bank 4: b200000000070f0f mce: [Hardware Error]: TSC 164083803dc mce: [Hardware Error]: PROCESSOR 2:20fc2 TIME 1396650505 SOCKET 0 APIC 0 microcode 0 mce: [Hardware Error]: Run the above through 'mcelog --ascii' mce: [Hardware Error]: Machine check: Processor context corrupt Kernel panic - not syncing: Fatal machine check on current CPU Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffff9fffffff) Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Acked-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-03-31p54: clamp properly instead of just truncatingDan Carpenter1-1/+1
commit 608cfbe4abaf76e9d732efd7ed1cfa3998163d91 upstream. The call to clamp_t() first truncates the variable signed 8 bit and as a result, the actual clamp is a no-op. Fixes: 0d78156eef1d ('p54: improve site survey') Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-03-23iwlwifi: mvm: don't WARN when statistics are handled lateEmmanuel Grumbach1-2/+5
commit 1e9291996c4eedf79883f47ec635235e39d3d6cd upstream. Since the statistics handler is asynchrous, it can very well be that we will handle the statistics (hence the RSSI fluctuation) when we already disassociated. Don't WARN on this case. This solves: https://bugzilla.redhat.com/show_bug.cgi?id=1071998 Fixes: 2b76ef13086f ("iwlwifi: mvm: implement reduced Tx power") Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-03-23mwifiex: save and copy AP's VHT capability info correctlyAmitkumar Karwar2-6/+5
commit d51246481c7f28bbfa1f814ded2da65e531cd4b2 upstream. While preparing association request, intersection of device's VHT capability information and corresponding field advertised by AP is used. This patch fixes a couple errors while saving and copying vht_cap and vht_oper fields from AP's beacon. 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> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-03-23mwifiex: copy AP's HT capability info correctlyAmitkumar Karwar1-2/+1
commit c99b1861c232e1f641f13b8645e0febb3712cc71 upstream. While preparing association request, intersection of device's HT capability information and corresponding fields advertised by AP is used. This patch fixes an error while copying this field from AP's beacon. 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> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-03-23mwifiex: do not advertise usb autosuspend supportBing Zhao1-8/+0
commit adb07df1e039e9fe43e66aeea8b4771f83659dbb upstream. As many Surface Pro I & II users have found out, the mwifiex_usb doesn't support usb autosuspend, and it has caused some system stability issues. Bug 69661 - mwifiex_usb on MS Surface Pro 1 is unstable Bug 60815 - Interface hangs in mwifiex_usb Bug 64111 - mwifiex_usb USB8797 crash failed to get signal information USB autosuspend get triggered when Surface Pro's AC power is removed or powertop enables power saving on USB8797 device. Driver's suspend handler is called here, but resume handler won't be called until the AC power is put back on or powertop disables power saving for USB8797. We need to refactor the suspend/resume handlers to support usb autosuspend properly. For now let's just remove it. Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-03-23mwifiex: fix cmd and Tx data timeout issue for PCIe cardsAmitkumar Karwar1-17/+11
commit 1c97560f6d751a620978504a4a888c631192b71a upstream. We are sending sleep confirm done interrupt in the middle of sleep handshake. There is a corner case when Tx done interrupt is received from firmware during sleep handshake due to which host and firmware power states go out of sync causing cmd and Tx data timeout problem. Hence sleep confirm done interrupt is sent at the end of sleep handshake to fix the problem. 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> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-03-23mwifiex: add NULL check for PCIe Rx skbAmitkumar Karwar1-0/+6
commit bb8e6a1ee881d131e404f0f1f5e8dc9281002771 upstream. We may get a NULL pointer here if skb allocation for Rx packet was failed earlier. 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> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-03-23mwifiex: clean pcie ring only when device is presentAvinash Patil1-1/+2
commit 4f7ba432202c8330cc03ab959c6228d0de5dc4a3 upstream. Write io memory to clean PCIe buffer only when PCIe device is present else this results into crash because of invalid memory access. Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-03-23iwlwifi: disable TX AMPDU by default for iwldvmEmmanuel Grumbach4-9/+48
commit 205e2210daa975d92ace485a65a31ccc4077fe1a upstream. NICs supported by iwldvm don't handle well TX AMPDU. Disable it by default, still leave the possibility to the user to force enable it with a debug parameter. NICs supported by iwlmvm don't suffer from the same issue, leave TX AMPDU enabled by default for these. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-03-23iwlwifi: fix TX status for aggregated packetsJohannes Berg2-14/+18
commit 143582c6847cb285b361804c613127c25de60ca4 upstream. Only the first packet is currently handled correctly, but then all others are assumed to have failed which is problematic. Fix this, marking them all successful instead (since if they're not then the firmware will have transmitted them as single frames.) This fixes the lost packet reporting. Also do a tiny variable scoping cleanup. Signed-off-by: Johannes Berg <johannes.berg@intel.com> [Add the dvm part] Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-03-23iwlwifi: dvm: clear IWL_STA_UCODE_INPROGRESS when assoc failsEmmanuel Grumbach1-0/+1
commit ec6f678c74dbdb06a6a775bbb00f1d26c17c404b upstream. We set IWL_STA_UCODE_INPROGRESS flag when we add a station and clear it when we send the LQ command for it. But the LQ command is sent only when the association succeeds. If the association doesn't succeed, we would leave this flag set and that wouldn't indicate the station entry as vacant. This probably fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1065663 Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-03-23ath9k: Fix ETSI compliance for AR9462 2.0Sujith Manoharan1-2/+2
commit b3050248c167871ca52cfdb2ce78aa2460249346 upstream. The minimum CCA power threshold values have to be adjusted for existing cards to be in compliance with new regulations. Newer cards will make use of the values obtained from EEPROM, support for this was added earlier. To make sure that cards that are already in use and don't have proper values in EEPROM, do not violate regulations, use the initvals instead. Reported-by: Jeang Daniel <dyjeong@qca.qualcomm.com> Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-03-06rtlwifi: rtl8192ce: Fix too long disable of IRQsOlivier Langlois1-2/+16
commit f78bccd79ba3cd9d9664981b501d57bdb81ab8a4 upstream. rtl8192ce is disabling for too long the local interrupts during hw initiatialisation when performing scans The observable symptoms in dmesg can be: - underruns from ALSA playback - clock freezes (tstamps do not change for several dmesg entries until irqs are finaly reenabled): [ 250.817669] rtlwifi:rtl_op_config():<0-0-0> 0x100 [ 250.817685] rtl8192ce:_rtl92ce_phy_set_rf_power_state():<0-1-0> IPS Set eRf nic enable [ 250.817732] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11 [ 250.817796] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11 [ 250.817910] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11 [ 250.818024] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11 [ 250.818139] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11 [ 250.818253] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11 [ 250.818367] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11 [ 250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11 [ 250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11 [ 250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11 [ 250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11 [ 250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:98053f15:10 [ 250.818472] rtl8192ce:rtl92ce_sw_led_on():<0-1-0> LedAddr:4E ledpin=1 [ 250.818472] rtl8192c_common:rtl92c_download_fw():<0-1-0> Firmware Version(49), Signature(0x88c1),Size(32) [ 250.818472] rtl8192ce:rtl92ce_enable_hw_security_config():<0-1-0> PairwiseEncAlgorithm = 0 GroupEncAlgorithm = 0 [ 250.818472] rtl8192ce:rtl92ce_enable_hw_security_config():<0-1-0> The SECR-value cc [ 250.818472] rtl8192c_common:rtl92c_dm_check_txpower_tracking_thermal_meter():<0-1-0> Schedule TxPowerTracking direct call!! [ 250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> rtl92c_dm_txpower_tracking_callback_thermalmeter [ 250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> Readback Thermal Meter = 0xe pre thermal meter 0xf eeprom_thermalmeter 0xf [ 250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> Initial pathA ele_d reg0xc80 = 0x40000000, ofdm_index=0xc [ 250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> Initial reg0xa24 = 0x90e1317, cck_index=0xc, ch14 0 [ 250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> Readback Thermal Meter = 0xe pre thermal meter 0xf eeprom_thermalmeter 0xf delta 0x1 delta_lck 0x0 delta_iqk 0x0 [ 250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> <=== [ 250.818472] rtl8192c_common:rtl92c_dm_initialize_txpower_tracking_thermalmeter():<0-1-0> pMgntInfo->txpower_tracking = 1 [ 250.818472] rtl8192ce:rtl92ce_led_control():<0-1-0> ledaction 3 [ 250.818472] rtl8192ce:rtl92ce_sw_led_on():<0-1-0> LedAddr:4E ledpin=1 [ 250.818472] rtlwifi:rtl_ips_nic_on():<0-1-0> before spin_unlock_irqrestore [ 251.154656] PCM: Lost interrupts? [Q]-0 (stream=0, delta=15903, new_hw_ptr=293408, old_hw_ptr=277505) The exact code flow that causes that is: 1. wpa_supplicant send a start_scan request to the nl80211 driver 2. mac80211 module call rtl_op_config with IEEE80211_CONF_CHANGE_IDLE 3. rtl_ips_nic_on is called which disable local irqs 4. rtl92c_phy_set_rf_power_state() is called 5. rtl_ps_enable_nic() is called and hw_init()is executed and then the interrupts on the device are enabled A good solution could be to refactor the code to avoid calling rtl92ce_hw_init() with the irqs disabled but a quick and dirty solution that has proven to work is to reenable the irqs during the function rtl92ce_hw_init(). I think that it is safe doing so since the device interrupt will only be enabled after the init function succeed. Signed-off-by: Olivier Langlois <olivier@trillion01.com> Acked-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-03-06rtlwifi: Fix incorrect return from rtl_ps_enable_nic()Olivier Langlois1-1/+1
commit 2e8c5e56b307271c2dab6f8bfd1d8a3822ca2390 upstream. rtl_ps_enable_nic() is called from loops that will loop until this function returns true or a maximum number of retries is performed. hw_init() returns non-zero on error. In that situation return false to restore the original design intent to retry hw init when it fails. Signed-off-by: Olivier Langlois <olivier@trillion01.com> Acked-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-03-06rtl8187: fix regression on MIPS without coherent DMAStanislaw Gruszka1-2/+8
commit b6213e413a4e0c66548153516b074df14f9d08e0 upstream. This patch fixes regression caused by commit a16dad77634 "MIPS: Fix potencial corruption". That commit fixes one corruption scenario in cost of adding another one, which actually start to cause crashes on Yeeloong laptop when rtl8187 driver is used. For correct DMA read operation on machines without DMA coherence, kernel have to invalidate cache, such it will refill later with new data that device wrote to memory, when that data is needed to process. We can only invalidate full cache line. Hence when cache line includes both dma buffer and some other data (written in cache, but not yet in main memory), the other data can not hit memory due to invalidation. That happen on rtl8187 where struct rtl8187_priv fields are located just before and after small buffers that are passed to USB layer and DMA is performed on them. To fix the problem we align buffers and reserve space after them to make them match cache line. This patch does not resolve all possible MIPS problems entirely, for that we have to assure that we always map cache aligned buffers for DMA, what can be complex or even not possible. But patch fixes visible and reproducible regression and seems other possible corruptions do not happen in practice, since Yeeloong laptop works stable without rtl8187 driver. Bug report: https://bugzilla.kernel.org/show_bug.cgi?id=54391 Reported-by: Petr Pisar <petr.pisar@atlas.cz> Bisected-by: Tom Li <biergaizi2009@gmail.com> Reported-and-tested-by: Tom Li <biergaizi2009@gmail.com> Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl> Acked-by: Larry Finger <Larry.Finger@lwfinger.next> Acked-by: Hin-Tak Leung <htl10@users.sourceforge.net> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-22iwlwifi: mvm: BT Coex - disable BT when TXing probe request in scanEmmanuel Grumbach1-1/+2
commit 8e2a866ef214af4e104ec8d593e3269d8fe66d19 upstream. Not doing so will let BT kill our probe requests leading to failures in scan. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-22iwlwifi: mvm: print the version of the firmware when it assertsEmmanuel Grumbach1-0/+2
commit b900a87b2eb90c0b9586496c82a323a1b8832d73 upstream. This can be useful to be able to spot the firmware version from the error reports without needing to fetch it from another place. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-22iwlwifi: mvm: don't allow A band if SKU forbids itEmmanuel Grumbach1-0/+5
commit c512865446e6dd5b6e91e81187e75b734ad7cfc7 upstream. The driver wasn't reading the NVM properly. While this didn't lead to any issue until now, it seems that there is an old version of the NVM in the wild. In this version, the A band channels appear to be valid but the SKU capabilities (another field of the NVM) says that A band isn't supported at all. With this specific version of the NVM, the driver would think that A band is supported while the HW / firmware don't. This leads to asserts. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-22ar5523: fix usb id for Gigaset.Oleksij Rempel1-1/+1
commit 4fcfc7443d072582b5047b8b391d711590e5645c upstream. Raw id and FW id should be switched. Tested-by: Oleksij Rempel <linux@rempel-privat.de> Signed-off-by: Oleksij Rempel <linux@rempel-privat.de> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-22ath9k_htc: make ->sta_rc_update atomic for most callsStanislaw Gruszka1-12/+13
commit 2fa4cb905605c863bf570027233af7afd8149ae4 upstream. sta_rc_update() callback must be atomic, hence we can not take mutexes or do other operations, which can sleep in ath9k_htc_sta_rc_update(). I think we can just return from ath9k_htc_sta_rc_update(), if it is called without IEEE80211_RC_SUPP_RATES_CHANGED bit. That will help with scheduling while atomic bug for most cases (except mesh and IBSS modes). For mesh and IBSS I do not see other solution like creating additional workqueue, because sending firmware command require us to sleep, but this can be done in additional patch. Patch partially fixes bug: https://bugzilla.redhat.com/show_bug.cgi?id=990955 Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06iwlwifi: pcie: fix interrupt coalescing for 7260 / 3160Emmanuel Grumbach5-7/+14
commit 6960a059b2c618f32fe549f13287b3d2278c09e9 upstream. We changed the timeout for the interrupt coealescing for calibration, but that wasn't effective since we changed that value back before loading the firmware. Since calibrations are notification from firmware and not Rx packets, this doesn't change anyway - the firmware will fire an interrupt straight away regardless of the interrupt coalescing value. Also, a HW issue has been discovered in 7000 devices series. The work around is to disable the new interrupt coalescing timeout feature - do this by setting bit 31 in CSR_INT_COALESCING. This has been fixed in 7265 which means that we can't rely on the device family and must have a hint in the iwl_cfg structure. Fixes: 99cd47142399 ("iwlwifi: add 7000 series device configuration") Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-06iwlwifi: pcie: enable oscillator for L1 exitEmmanuel Grumbach2-0/+20
commit 2d93aee152b1758a94a18fe15d72153ba73b5679 upstream. Enabling the oscillator consumes slightly more power (100uA) but allows to make sure that we exit from L1 on time. Not doing so might lead to a PCIe specification violation since we might wake up from L1 at the wrong time. This issue has been identified on 3160 and 7260 only. On older NICs L1 off is not enabled, on newer NICs (7265), the issue is fixed. When the bug occurs the user sees that the NIC has disappeared from the PCI bridge, any access to the device returns 0xff. This fixes: https://bugzilla.kernel.org/show_bug.cgi?id=64541 and has been extensively discussed here: http://markmail.org/thread/mfmpzqt3r333n4bo Fixes: 99cd47142399 ("iwlwifi: add 7000 series device configuration") Reported-and-tested-by: wzyboy <wzyboy@wzyboy.org> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-17 15:45:28 +0000