- 08 5月, 2014 2 次提交
-
-
由 Emmanuel Grumbach 提交于
In case RFKILL is in KILL position, the NIC will issue an interrupt straight away. This interrupt won't be sent because it is masked in the hardware. But if our interrupt service routine is called for another reason (SHARED_IRQ), then we'll look at the interrupt cause and service it. This can cause bad things if we are not ready yet. Explicitly clean the interrupt cause register to make sure we won't service anything before we are ready to. Cc: <stable@vger.kernel.org> [3.14] Reported-and-tested-by: NAlexander Monakov <amonakov@gmail.com> Reviewed-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
- 07 5月, 2014 4 次提交
-
-
由 David Spinadel 提交于
Currently the FW doesn't support sched scan while associated, Prevent it. Signed-off-by: NDavid Spinadel <david.spinadel@intel.com> Reviewed-by: NJohannes Berg <johannes.berg@intel.com> Reviewed-by: NLuciano Coelho <luciano.coelho@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Emmanuel Grumbach 提交于
My bad - I forgot to update this when sending the patch upstream. Fixes: 87d5e415 ("iwlwifi: mvm: rs: reinit rs if no tx for a long time") Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Emmanuel Grumbach 提交于
The commit below introduced a bug in the validity bits in init. Due to that, all the Coex mechanism stopped sending kills to the BT side. Fix that. Fixes: b9fae2d5 ("iwlwifi: mvm: BT Coex add support for Co-running block") Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
- 05 5月, 2014 4 次提交
-
-
由 Eliad Peller 提交于
ieee80211_reconfig already holds rtnl, so calling cfg80211_sched_scan_stopped results in deadlock. Use the rtnl-version of this function instead. Fixes: d43c6b6e ("mac80211: reschedule sched scan after HW restart") Cc: stable@vger.kernel.org (3.14+) Signed-off-by: NEliad Peller <eliadx.peller@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Eliad Peller 提交于
Add locked-version for cfg80211_sched_scan_stopped. This is used for some users that might want to call it when rtnl is already locked. Fixes: d43c6b6e ("mac80211: reschedule sched scan after HW restart") Cc: stable@vger.kernel.org (3.14+) Signed-off-by: NEliad Peller <eliadx.peller@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Eliad Peller 提交于
cfg80211 is notified about connection failures by __cfg80211_connect_result() call. However, this function currently does not free cfg80211 sme. This results in hanging connection attempts in some cases e.g. when mac80211 authentication attempt is denied, we have this function call: ieee80211_rx_mgmt_auth() -> cfg80211_rx_mlme_mgmt() -> cfg80211_process_auth() -> cfg80211_sme_rx_auth() -> __cfg80211_connect_result() but cfg80211_sme_free() is never get called. Fixes: ceca7b71 ("cfg80211: separate internal SME implementation") Cc: stable@vger.kernel.org (3.10+) Signed-off-by: NEliad Peller <eliadx.peller@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Henning Rogge 提交于
Filter out incoming multicast packages before applying their bitrate to the rx bitrate station info field to prevent them from setting the rx bitrate to the basic multicast rate. Signed-off-by: NHenning Rogge <hrogge@gmail.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 01 5月, 2014 2 次提交
-
-
由 Ben Hutchings 提交于
Fixes: a53268be ('rtlwifi: rtl8192cu: Fix too long disable of IRQs') Cc: stable@vger.kernel.org Signed-off-by: NBen Hutchings <ben@decadent.org.uk> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Larry Finger 提交于
Beginning with kernel 3.13, this driver fails on some systems. The problem was bisected to: Commit 1bf4bbb4 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=74541Reported-by: NAlex Miller <almiller_1@yahoo.co.uk> Tested-by: NAlex Miller <almiller_1@yahoo.co.uk> Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net> Cc: Stable <stable@vger.kernel.org> [3.13+] Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 30 4月, 2014 2 次提交
-
-
由 Felix Fietkau 提交于
There are some corner cases where the driver could get stuck with a full tid queue that is paused, leading to a software tx queue hang. Since the tx queueing rework, pausing per-tid queues on aggregation session setup is no longer necessary. The driver will assign sequence numbers to buffered frames when a new session is established, in order to get the correct starting sequence number. mac80211 prevents new frames from entering the queue during setup. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Felix Fietkau 提交于
When the amount of noise fluctuates strongly, low immunity settings can sometimes disrupt signal detection on AR913x chips. When that happens, no OFDM/CCK errors are reported anymore, and ANI tunes the radio to the lowest immunity settings. Usually rx/tx fails as well in that case. To fix this, keep noise immunity settings at or above ANI default level, which will keep radio parameters at or above INI values. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 25 4月, 2014 7 次提交
-
-
由 Mohammed Habibulla 提交于
Add support for the AR9462 chip T: Bus=01 Lev=01 Prnt=01 Port=03 Cnt=03 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=04ca ProdID=3007 Rev= 0.01 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms Signed-off-by: NMohammed Habibulla <moch@chromium.org> Cc: stable@vger.kernel.org Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Johan Hedberg 提交于
When we're performing reauthentication (in order to elevate the security level from an unauthenticated key to an authenticated one) we do not need to issue any encryption command once authentication completes. Since the trigger for the encryption HCI command is the ENCRYPT_PEND flag this flag should not be set in this scenario. Instead, the REAUTH_PEND flag takes care of all necessary steps for reauthentication. Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com> Signed-off-by: NMarcel Holtmann <marcel@holtmann.org> Cc: stable@vger.kernel.org
-
由 Johan Hedberg 提交于
Commit 1c2e0041 introduced an event handler for the encryption key refresh complete event with the intent of fixing some LE/SMP cases. However, this event is shared with BR/EDR and there we actually want to act only on the auth_complete event (which comes after the key refresh). If we do not do this we may trigger an L2CAP Connect Request too early and cause the remote side to return a security block error. Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com> Signed-off-by: NMarcel Holtmann <marcel@holtmann.org> Cc: stable@vger.kernel.org
-
由 Marcel Holtmann 提交于
This reverts commit d2bee8fb. Enabling autosuspend for Intel Bluetooth devices has been shown to not work reliable. It does work for some people with certain combinations of USB host controllers, but for others it puts the device to sleep and it will not wake up for any event. These events can be important ones like HCI Inquiry Complete or HCI Connection Request. The events will arrive as soon as you poke the device with a new command, but that is not something we can do in these cases. Initially there were patches to the xHCI USB controller that fixed this for some people, but not for all. This could be well a problem somewhere in the USB subsystem or in the USB host controllers or just plain a hardware issue somewhere. At this moment we just do not know and the only safe action is to revert this patch. Signed-off-by: NMarcel Holtmann <marcel@holtmann.org> Cc: Tedd Ho-Jeong An <tedd.an@intel.com> Cc: stable@vger.kernel.org Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Hans de Goede 提交于
brcmfmac has been broken on my cubietruck with a BCM43362: brcmfmac: brcmf_chip_recognition: found AXI chip: BCM43362, rev=1 brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Apr 22 2013 14:50:00 version 5.90.195.89.6 FWID 01-b30a427d since commit 53036261: "brcmfmac: update core reset and disable routines". The problem is that since this commit brcmf_chip_ai_resetcore no longer sets BCMA_IOCTL itself before bringing the core out of reset, instead relying on brcmf_chip_ai_coredisable to do so. But brcmf_chip_ai_coredisable is a nop of the chip is already in reset. This patch modifies brcmf_chip_ai_coredisable to always set BCMA_IOCTL even if the core is already in reset. This fixes brcmfmac hanging in firmware loading on my board. Cc: stable@vger.kernel.org # v3.14 Signed-off-by: NHans de Goede <hdegoede@redhat.com> Acked-by: NArend van Spriel <arend@broadcom.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Rajkumar Manoharan 提交于
The commit "ath9k: move sc_flags to ath_common" moved setting ATH_OP_INVALID flag below ieee80211_register_hw. This is causing the flag never being cleared randomly as the drv_start is called prior to setting flag. Fix this by setting the flag prior to register_hw. Signed-off-by: NRajkumar Manoharan <rmanohar@qti.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
- 23 4月, 2014 5 次提交
-
-
由 Tim Harvey 提交于
Implement a recv budget so that in cases of high traffic we still allow other taskets to get processed. Without this, we can encounter a host of issues during high wireless traffic reception depending on system load including rcu stall's detected (ARM), soft lockups, failure to service critical tasks such as watchdog resets, and triggering of the tx stuck tasklet. The same thing was proposed previously by Ben: http://www.spinics.net/lists/linux-wireless/msg112891.html The only difference here is that I make sure only processed packets are counted in the budget by checking at the end of the rx loop. Signed-off-by: NTim Harvey <tharvey@gateworks.com> Acked-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Tim Harvey 提交于
If a flush is requested, make sure to clear the descriptor once we've processed it. This resolves a hang that will occur if all RX descriptors are full when a flush is requested. Signed-off-by: NTim Harvey <tharvey@gateworks.com> Acked-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Colin Ian King 提交于
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: NColin Ian King <colin.king@canonical.com> Cc: Stable <stable@vger.kernel.org> [3.10+] Acked-by: NLarry Finger <Larry.Finger@lwfinger.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Gertjan van Wingerde 提交于
Let's formalize what must have been blatantly clear from my level of activity is the past year(s). I simply do not have time for this anymore. Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com> Acked-by: NHelmut Schaa <helmut.schaa@googlemail.com> Acked-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Stanislaw Gruszka 提交于
When disable beaconing we clear register with beacon and newer set it back, what make we stop send beacons infinitely. Cc: stable@vger.kernel.org Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 22 4月, 2014 2 次提交
-
-
由 Bob Copeland 提交于
When using RTS/CTS, the CTS-to-Self bit in radiotap TX flags is getting set instead of the RTS bit. Set the correct one. Reported-by: NLarry Maxwell <larrymaxwell@agilemesh.com> Signed-off-by: NBob Copeland <bob@cozybit.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Chun-Yeow Yeoh 提交于
The patch "mac80211: implement SMPS for AP" has caused kernel oops at mesh STA if the peer mesh STA operates in sleep mode and then becomes active mode. It can be easily reproduced by setting the following commands at peer mesh STA: iw mesh0 station set aa:bb:cc:dd:ee:ff mesh_power_mode deep iw mesh0 station set aa:bb:cc:dd:ee:ff mesh_power_mode active Kernel oops will happen at mesh STA aa:bb:cc:dd:ee:ff. Fix this by avoiding SMPS for mesh mode. Signed-off-by: NChun-Yeow Yeoh <yeohchunyeow@gmail.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 16 4月, 2014 2 次提交
-
-
由 Amitkumar Karwar 提交于
Sometimes when command timeout occurs due to a firmware or hardware bug, there may be some synchronous commands in command queue. These commands are never downloaded to firmware causing hung task warnings. This patch replaces wait_event_interruptible call with wait_event_interruptible_timeout to fix the issue. Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com> Signed-off-by: NAvinash Patil <patila@marvell.com> Signed-off-by: NBing Zhao <bzhao@marvell.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Amitkumar Karwar 提交于
During extended scan, SCAN report event is always followed by command response. Sometimes It is observed that command response is processed before SCAN report which leads to a crash, because current command node is cleared while handling the response. This patch makes sure that driver's main thread gives priority to events over command responses. Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com> Signed-off-by: NMaithili Hinge <maithili@marvell.com> Signed-off-by: NBing Zhao <bzhao@marvell.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 15 4月, 2014 8 次提交
-
-
由 Eliad Peller 提交于
Some fields are missing from the event mailbox struct definitions, which cause issues when trying to handle some events. Add the missing fields in order to align the struct size (without adding actual support for the new fields). Reported-and-tested-by: NImre Kaloz <kaloz@openwrt.org> Cc: stable@vger.kernel.org # 3.14+ Fixes: 028e7243 ("wl18xx: move to new firmware (wl18xx-fw-3.bin)") Signed-off-by: NEliad Peller <eliad@wizery.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Christian Engelmayer 提交于
Fix a potential memory leak in the error path of function rsi_send_auto_rate_request(). In case memory allocation for array 'selected_rates' fails, the error path exits and leaves the previously allocated skb in place. Detected by Coverity: CID 1195575. Signed-off-by: NChristian Engelmayer <cengelma@gmx.at> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Frederic Danis 提交于
This array is used in debug string to display cw1200_link_status defined in drivers/net/wireless/cw1200/cw1200.h. Add missing strings for CW1200_LINK_RESET and CW1200_LINK_RESET_REMAP. Signed-off-by: NFrederic Danis <frederic.danis@linux.intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luciano Coelho 提交于
Sometimes the firmware sends a dummy packet event while we are in PLT mode. This doesn't make sense, it's a firmware bug. Fix this by ignoring dummy packet events when we're PLT mode. Reported-by: NYegor Yefremov <yegorslists@googlemail.com> Reported-by: NArik Nemtsov <arik@wizery.com> Signed-off-by: NLuciano Coelho <luca@coelho.fi> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Christian Engelmayer 提交于
Fix a potential memory leak in function rsi_set_channel() that is used to program channel changes. The channel check block for the frequency bands directly exits the function in case of an error, thus leaving an already allocated skb unreferenced. Move the checks above allocating the skb. Detected by Coverity: CID 1195576. Signed-off-by: NChristian Engelmayer <cengelma@gmx.at> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Geert Uytterhoeven 提交于
drivers/net/wireless/rsi/rsi_91x_core.c: In function ‘rsi_core_determine_hal_queue’: drivers/net/wireless/rsi/rsi_91x_core.c:91: warning: ‘ii’ may be used uninitialized in this function Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 14 4月, 2014 1 次提交
-
-
由 Alexander Bondar 提交于
The firmware doesn't handle properly the fragmented scan. Stop using it. While at it change max_out_time and suspend_time units from usec to TUs as expected by firmware API. Signed-off-by: NAlexander Bondar <alexander.bondar@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
- 13 4月, 2014 1 次提交
-
-
由 Emmanuel Grumbach 提交于
A few entries were wrong and this caused throughput issues. Cc: <stable@vger.kernel.org> [3.13+] Fixes: dac94da8 ("iwlwifi: mvm: new BT Coex API") Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-