- 27 Apr, 2012 1 commit
-
-
- 24 Apr, 2012 5 commits
-
-
Eliad Peller authored
ieee80211_mgd_teardown() is called on netdev removal, which occurs after the vif was already removed from the low-level driver, resulting in the following warning: [ 4809.014734] ------------[ cut here ]------------ [ 4809.019861] WARNING: at net/mac80211/driver-ops.h:12 ieee80211_bss_info_change_notify+0x200/0x2c8 [mac80211]() [ 4809.030388] wlan0: Failed check-sdata-in-driver check, flags: 0x4 [ 4809.036862] Modules linked in: wlcore_sdio(-) wl12xx wlcore mac80211 cfg80211 [last unloaded: cfg80211] [ 4809.046849] [<c001bd4c>] (unwind_backtrace+0x0/0x12c) [ 4809.055937] [<c047cf1c>] (dump_stack+0x20/0x24) [ 4809.065385] [<c003e334>] (warn_slowpath_common+0x5c/0x74) [ 4809.075589] [<c003e408>] (warn_slowpath_fmt+0x40/0x48) [ 4809.088291] [<bf033630>] (ieee80211_bss_info_change_notify+0x200/0x2c8 [mac80211]) [ 4809.102844] [<bf067f84>] (ieee80211_destroy_auth_data+0x80/0xa4 [mac80211]) [ 4809.116276] [<bf068004>] (ieee80211_mgd_teardown+0x5c/0x74 [mac80211]) [ 4809.129331] [<bf043f18>] (ieee80211_teardown_sdata+0xb0/0xd8 [mac80211]) [ 4809.141595] [<c03b5e58>] (rollback_registered_many+0x228/0x2f0) [ 4809.153056] [<c03b5f48>] (unregister_netdevice_many+0x28/0x50) [ 4809.165696] [<bf041ea8>] (ieee80211_remove_interfaces+0xb4/0xdc [mac80211]) [ 4809.179151] [<bf032174>] (ieee80211_unregister_hw+0x50/0xf0 [mac80211]) [ 4809.191043] [<bf0bebb4>] (wlcore_remove+0x5c/0x7c [wlcore]) [ 4809.201491] [<c02c6918>] (platform_drv_remove+0x24/0x28) [ 4809.212029] [<c02c4d50>] (__device_release_driver+0x8c/0xcc) [ 4809.222738] [<c02c4e84>] (device_release_driver+0x30/0x3c) [ 4809.233099] [<c02c4258>] (bus_remove_device+0x10c/0x128) [ 4809.242620] [<c02c26f8>] (device_del+0x11c/0x17c) [ 4809.252150] [<c02c6de0>] (platform_device_del+0x28/0x68) [ 4809.263051] [<bf0df49c>] (wl1271_remove+0x3c/0x50 [wlcore_sdio]) [ 4809.273590] [<c03806b0>] (sdio_bus_remove+0x48/0xf8) [ 4809.283754] [<c02c4d50>] (__device_release_driver+0x8c/0xcc) [ 4809.293729] [<c02c4e2c>] (driver_detach+0x9c/0xc4) [ 4809.303163] [<c02c3d7c>] (bus_remove_driver+0xc4/0xf4) [ 4809.312973] [<c02c5a98>] (driver_unregister+0x70/0x7c) [ 4809.323220] [<c03809c4>] (sdio_unregister_driver+0x24/0x2c) [ 4809.334213] [<bf0df458>] (wl1271_exit+0x14/0x1c [wlcore_sdio]) [ 4809.344930] [<c009b1a4>] (sys_delete_module+0x228/0x2a8) [ 4809.354734] ---[ end trace 515290ccf5feb522 ]--- Rename ieee80211_mgd_teardown() to ieee80211_mgd_stop(), and call it on ieee80211_do_stop(). Signed-off-by:
Eliad Peller <eliad@wizery.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Meenakshi Venkataraman authored
Report correctly the latest released version of the iwlwifi firmware for all iwlwifi-supported devices. Cc: stable@vger.kernel.org #3.3+ Signed-off-by:
Meenakshi Venkataraman <meenakshi.venkataraman@intel.com> Signed-off-by:
Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by:
-
Johannes Berg authored
Newer devices have 20 (5000 series) or 30 (6000 series) hardware queues, rather than the 16 that 4965 had. This was added to the driver a long time ago, but improperly: the queue registers for the higher queues aren't just continuations of the registers for the first 16 queues, they are in other places. Therefore, the hardware would lock up when trying to activate queue 16 or above and the device would have to be restarted. Thanks goes to Emmanuel who identified this and told me how the queue programming should be done. Note that we don't use queues 20 and higher today and doing so needs more work than this. Cc: stable@vger.kernel.org Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Steven Harms authored
This change adds 0x0489:0xe033 to the btusb module. This bluetooth usb device is integrated in the Acer TimelineX AS4830TG-6808 notebook. Output from /sys/kernel/debug/usb/devices: T: Bus=01 Lev=02 Prnt=02 Port=05 Cnt=02 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0489 ProdID=e033 Rev= 2.29 S: Manufacturer=Broadcom Corp S: Product=Acer Module S: SerialNumber=60D819F74101 C:* #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) 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=ff(vend.) 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=ff(vend.) 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= 32 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 32 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= 64 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 64 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= 64 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 64 Ivl=1ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=84(I) Atr=02(Bulk) MxPS= 32 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 32 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none) Signed-off-by:
Steven Harms <sjharms@gmail.com> Signed-off-by:
Gustavo Padovan <gustavo@padovan.org>
-
Szymon Janc authored
Command complete event for HCI_OP_USER_PASSKEY_NEG_REPLY would result in calling handler function also for HCI_OP_LE_SET_SCAN_PARAM. This could result in undefined behaviour. Signed-off-by:
Szymon Janc <szymon.janc@tieto.com> Signed-off-by:
-
- 23 Apr, 2012 6 commits
-
-
Eldad Zack authored
I keep getting the following messages on the log buffer: [ 2167.097507] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not AMPDU [ 2281.331305] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not AMPDU [ 2281.332539] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not AMPDU [ 2329.876605] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not AMPDU [ 2329.877354] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not AMPDU [ 2462.280756] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not AMPDU [ 2615.651689] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not AMPDU From the code comment I understand that this something that can - and does, quite frequently - happen. Signed-off-by:
Eldad Zack <eldad@fogrefinery.com> Acked-by: Franky Lin<frankyl@broadcom.com> Signed-off-by:
-
Larry Finger authored
Under some circumstances, a PCI-based driver reports the following OOPs: Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Oops: 0000 [#1] SMP --snip-- Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Pid: 19627, comm: rmmod Not tainted 3.2.9-2.fc16.x86_64 #1 LENOVO 05962RU/05962RU Mar 19 08:14:35 kvothe kernel: [ 6584.626011] RIP: 0010:[<ffffffffa0418d39>] [<ffffffffa0418d39>] rtl92ce_get_desc+0x19/0xd0 [rtl8192ce] --snip-- Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Process rmmod (pid: 19627, threadinfo ffff880050262000, task ffff8801156d5cc0) Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Stack: Mar 19 08:14:35 kvothe kernel: [ 6584.626011] 0000000000000002 ffff8801176c2540 ffff880050263ca8 ffffffffa03348e7 Mar 19 08:14:35 kvothe kernel: [ 6584.626011] 0000000000000282 0000000180150014 ffff880050263fd8 ffff8801176c2810 Mar 19 08:14:35 kvothe kernel: [ 6584.626011] ffff880050263bc8 ffffffff810550e2 00000000000002c0 ffff8801176c0d40 Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Call Trace: Mar 19 08:14:35 kvothe kernel: [ 6584.626011] [<ffffffffa03348e7>] _rtl_pci_rx_interrupt+0x187/0x650 [rtlwifi] --snip-- Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Code: ff 09 d0 89 07 48 83 c4 08 5b 5d c3 66 0f 1f 44 00 00 55 48 89 e5 53 48 83 ec 08 66 66 66 66 90 40 84 f6 89 d3 74 13 84 d2 75 57 <8b> 07 48 83 c4 08 5b 5d c1 e8 1f c3 0f 1f 00 84 d2 74 ed 80 fa Mar 19 08:14:35 kvothe kernel: [ 6584.626011] RIP [<ffffffffa0418d39>] rtl92ce_get_desc+0x19/0xd0 [rtl8192ce] Mar 19 08:14:35 kvothe kernel: [ 6584.626011] RSP <ffff880050263b58> Mar 19 08:14:35 kvothe kernel: [ 6584.626011] CR2: 00000000000006e0 Mar 19 08:14:35 kvothe kernel: [ 6584.646491] ---[ end trace 8636c766dcfbe0e6 ]--- This oops is due to interrupts not being disabled in this particular path. Reported-by:
Dave Airlie <airlied@gmail.com> Tested-by:
Larry Finger <Larry.Finger@lwfinger.net> Cc: Stable <stable@vger.kernel.org> Signed-off-by:
-
Stanislav Yakovlev authored
Driver incorrectly validates command completion: instead of waiting for a command to be acknowledged it continues execution. Most of the time driver gets acknowledge of the command completion in a tasklet before it executes the next one. But sometimes it sends the next command before it gets acknowledge for the previous one. In such a case one of the following error messages appear in the log: Failed to send SYSTEM_CONFIG: Already sending a command. Failed to send ASSOCIATE: Already sending a command. Failed to send TX_POWER: Already sending a command. After that you need to reload the driver to get it working again. This bug occurs during roaming (reported by Sam Varshavchik) https://bugzilla.redhat.com/show_bug.cgi?id=738508 and machine booting (reported by Tom Gundersen and Mads Kiilerich) https://bugs.archlinux.org/task/28097 https://bugzilla.redhat.com/show_bug.cgi?id=802106 This patch doesn't fix the delay issue during firmware load. But at least device now works as usual after boot. Cc: stable@kernel.org Signed-off-by:
Stanislav Yakovlev <stas.yakovlev@gmail.com> Signed-off-by:
-
Stanislaw Gruszka authored
ctx->vif is dereferenced in different part of iwlwifi code, so do not nullify it. This should address at least one of the possible reasons of WARNING at iwlagn_mac_remove_interface, and perhaps some random crashes when firmware reset is performed. Cc: stable@vger.kernel.org Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
-
Gabor Juhos authored
The 'ath9k_hw_update_regulatory_maxpower' helper function has been introduced by commit a55f8588 (ath9k_hw: Cleanup TX power calculation for AR9287). Updating of the max_power_level value has been moved into the helper function in that change, however the removed code from 'ath9k_hw_ar9287_set_txpower' has not been replaced with a call of the new helper function. Due to that missing call, retrieving tx power for 2x2 and 3x3 chainmask is not handled properly. During the calculation of the tx power for 2x2 and 3x3 chainmasks the values are reduced. Those reductions must be compensated during retrieving. Fix this by adding the missing call of the helper function. Signed-off-by:
Gabor Juhos <juhosg@openwrt.org> Acked-by:
Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by:
-
Gabor Juhos authored
In order to unifying regulatory limit handling commit ca2c68cc (ath9k_hw: clean up tx power handling) introduced a new helper function 'ath9k_hw_apply_txpower', and the direct calls of 'ah->eep_ops->set_txpower' has been replaced by a call of the helper function. This caused a change in the behaviour of the 'ath9k_hw_set_txpowerlimit' function. The purpose of that function is to calculate and store the rate txpower table and the regulatory limit without touching the hardware registers. Before the commit, the 'test' parameter of the function was passed to the 'ah->eep_ops->set_txpower'. Now the calling of the 'set_txpower' function happens indirectly through 'ath9k_hw_apply_txpower', so the 'test' argument of the 'set_txpower' is always 'false'. This patch restores the original behaviour of 'ath9k_hw_set_txpowerlimit' by adding a new argument to 'ath9k_hw_apply_txpower.' Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
-
- 19 Apr, 2012 1 commit
-
-
AceLan Kao authored
Add another vendor specific ID for Atheros AR3012 output of usb-devices: T: Bus=02 Lev=02 Prnt=02 Port=04 Cnt=01 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0cf3 ProdID=e004 Rev=00.02 S: Manufacturer=Atheros Communications S: Product=Bluetooth USB Host Controller S: SerialNumber=Alaska Day 2006 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 I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb BugLink: https://bugs.launchpad.net/bugs/922715Signed-off-by:
AceLan Kao <acelan.kao@canonical.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
- 17 Apr, 2012 4 commits
-
-
Sujith Manoharan authored
Assigning sequence number for frames without taking care of the fragment field breaks transmission of fragmented frames. Fix this by assigning the fragment number properly. Signed-off-by:
-
Felix Fietkau authored
The broken check leads to rate control attempting to use HT40 while the driver is configured for HT20. This leads to interesting hardware issues. HT40 can only be used if the channel type is either HT40- or HT40+ and if the channel type of the cell matches the local type. Signed-off-by:
-
Wey-Yi Guy authored
Add Johannes Berg as the primary maintainer for iwlwifi driver Signed-off-by:
-
Felix Fietkau authored
Cooked monitor rx was recently changed to use ieee80211_add_rx_radiotap_header instead of generating only limited radiotap information. ieee80211_add_rx_radiotap_header assumes that FCS info is still present if the hardware supports receiving it, however when cooked monitor rx packets are processed, FCS info has already been stripped. Fix this by adding an extra flag indicating FCS presence. Signed-off-by:
-
- 16 Apr, 2012 3 commits
-
-
Hauke Mehrtens authored
bcma should check for a fallback sprom every time it can not find a sprom on the card itself or a normal external sprom mapped into the memory of the chip. When otp sprom support was introduced it tried to read out the sprom from the wireless chip also if no otp sprom was available. This caused a Data bus error in bcma_sprom_get() when reading out the sprom for the SoC. This fixes a regression introduced in commit: commit 10d8493c Author: Arend van Spriel <arend@broadcom.com> Date: Tue Mar 6 15:50:48 2012 +0100 bcma: add support for on-chip OTP memory used for SPROM storage This patch was tested on a Netgear WNDR3400 (Broadcom BCM4718 SoC). Reported-by:
Nick Bowler <nbowler@elliptictech.com> Signed-off-by:
Hauke Mehrtens <hauke@hauke-m.de> Acked-by:
Arend van Spriel <arend@broadcom.com> Signed-off-by:
-
Vishal Agarwal authored
If a key is non persistent then it should not be used in future connections but it should be kept for current connection. And it should be removed when connecion is removed. Signed-off-by:
Vishal Agarwal <vishal.agarwal@stericsson.com> Acked-by:
Johan Hedberg <johan.hedberg@intel.com>
-
Vishal Agarwal authored
This patch changes the return type of function hci_persistent_key from int to bool because it makes more sense to return information whether a key is persistent or not as a bool. Signed-off-by:
-
- 13 Apr, 2012 9 commits
-
-
Bing Zhao authored
The scratch register addresses have been changed for newer chips. Since the old chip was never shipped and it will not be supported any more, just update register addresses to support the new chips. Cc: <stable@vger.kernel.org> # 3.2.y, 3.3.y Signed-off-by:
Bing Zhao <bzhao@marvell.com> Signed-off-by:
-
Felix Fietkau authored
The hardware needs a reset to recover from full sleep. Issue this reset directly in the ath9k_config call that turns off idle, otherwise tx remains dead until the first channel change after the idle state change Signed-off-by:
-
Jonathan Bither authored
Signed-off-by:
Jonathan Bither <jonbither@gmail.com> Signed-off-by:
-
Jonathan Bither authored
When cross compiling ath5k for a Mips machine with kernel 3.2.14 the compilation fails with "/ath5k/ahb.c:231:12: error: 'THIS_MODULE' undeclared here (not in a function)" Fix the build by including <linux/export.h> Signed-off-by:
-
Lukasz Kucharczyk authored
Signed-off-by:
Lukasz Kucharczyk <lukasz.kucharczyk@tieto.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Arend van Spriel authored
There have been reports about not being able to use access-points on channel 12 and 13 or having connectivity issues when these channels were part of the selected regulatory domain. Upon switching to these channels the brcmsmac driver suspends the transmit dma fifos. This patch resumes them upon handing over the first received beacon to mac80211. This patch is to be applied to the stable tree for kernel versions 3.2 and 3.3. Cc: stable@vger.kernel.org Tested-by:
Francesco Saverio Schiavarelli <fschiava@libero.it> Reviewed-by:
Pieter-Paul Giesberts <pieterpg@broadcom.com> Reviewed-by:
Brett Rudley <brudley@broadcom.com> Signed-off-by:
-
Amitkumar Karwar authored
Return type for lbs_auth_to_authtype() is changed from "u8" to "int" to return negative error code correctly. Also an error check is added in connect handler for invalid auth type. Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Amitkumar Karwar <akarwar@marvell.com> Signed-off-by:
Kiran Divekar <dkiran@marvell.com> Signed-off-by:
-
AceLan Kao authored
Add another vendor specific ID for Atheros AR3012 device. This chip is wrapped by IMC Networks. output of usb-devices: T: Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 5 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3362 Rev=00.02 S: Manufacturer=Atheros Communications S: Product=Bluetooth USB Host Controller S: SerialNumber=Alaska Day 2006 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 I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb Signed-off-by:
-
Manoj Iyer authored
T: Bus=02 Lev=02 Prnt=02 Port=04 Cnt=01 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0489 ProdID=e042 Rev=01.12 S: Manufacturer=Broadcom Corp S: Product=BCM20702A0 S: SerialNumber=E4D53DCA61B5 C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none) I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none) I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none) Reported-by:
Dennis Chua <dennis.chua@canonical.com> Signed-off-by:
Manoj Iyer <manoj.iyer@canonical.com> Signed-off-by:
-
- 11 Apr, 2012 3 commits
-
-
Samuel Ortiz authored
Reported-by:
Samuel Ortiz <sameo@linux.intel.com> Signed-off-by:
-
Larry Finger authored
In https://bugzilla.kernel.org/show_bug.cgi?id=42976, a system with driver rtl8192se used as an AP suffers from "Out of SW-IOMMU space" errors. These are caused by the DMA buffers used for beacons never being unmapped. This bug was also reported at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/961618Reported-and-Tested-by:
Da Xue <da@lessconfused.com> Signed-off-by:
-
Larry Finger authored
The current version of rtlwifi for USB operations uses kmalloc to acquire a 32-bit buffer for each read of the device. When _usb_read_sync() is called with the rcu_lock held, the result is a "sleeping function called from invalid context" BUG. This is reported for two cases in https://bugzilla.kernel.org/show_bug.cgi?id=42775. The first case has the lock originating from within rtlwifi and could be fixed by rearranging the locking; however, the second originates from within mac80211. The kmalloc() call is removed from _usb_read_sync() by creating a ring buffer pointer in the private area and allocating the buffer data in the probe routine. Signed-off-by:
-
- 10 Apr, 2012 3 commits
-
-
Sujith Manoharan authored
This reverts commit c1afdaff. Users have reported connection failures in 3.3.1 and suspend/resume failures in 3.4-rcX. Revert this commit for now - PS IDLE can be fixed in a clean manner later on. Cc: stable@vger.kernel.org Signed-off-by:
-
Chen, Chien-Chia authored
Move rt2x00rfkill_register(rt2x00dev) to rt2x00lib_probe_dev function. It fixes of starting rfkill_poll function at the right time if sets hard rfkill block and reboot. rt2x00mac_rfkill_poll should be starting before bringing up the wireless interface. Signed-off-by:
Chen, Chien-Chia <machen@suse.com> Acked-by:
Helmut Schaa <helmut.schaa@googlemail.com> CC: Kevin Chou <kevin.chou@mediatek.com> Signed-off-by:
-
Paul Gortmaker authored
The following is seen during allmodconfig builds for MIPS: drivers/bcma/driver_pci_host.c:518:2: error: implicit declaration of function 'pcibios_enable_device' [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors make[3]: *** [drivers/bcma/driver_pci_host.o] Error 1 Most likey introduced by commit 49dc9577 "bcma: add PCIe host controller" Add the header instead of implicitly assuming it will be present. Sounds like a good idea, but that alone doesn't fix anything. The real problem is that the Kconfig has settings related to whether PCI is possible, i.e. config BCMA_HOST_PCI_POSSIBLE bool depends on BCMA && PCI = y default y config BCMA_HOST_PCI bool "Support for BCMA on PCI-host bus" depends on BCMA_HOST_PCI_POSSIBLE ...but what is missing is that BCMA_DRIVER_PCI_HOSTMODE doesn't have any dependencies on the above. Add one. CC: Hauke Mehrtens <hauke@hauke-m.de> CC: John W. Linville <linville@tuxdriver.com> Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com> Acked-by:
-
- 09 Apr, 2012 5 commits
-
-
Julia Lawall authored
Free extra as done in the error-handling code just above. Signed-off-by:
Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by:
-
Larry Finger authored
When the rate-control indexing is incorrectly set up, mac80211 issues a warning and returns NULL from the call to ieee80211_get_tx_rate(). When this happens, avoid a NULL pointer dereference. Signed-off-by:
-
Larry Finger authored
When the control-rate tables are not set up correctly, it makes little sense to spam the logs, thus change the WARN_ON to WARN_ON_ONCE. Signed-off-by:
-
Larry Finger authored
Before the switch to asynchronous firmware loading (mainline commit b0302aba), it was necessary to load firmware when initializing the first of the units in a dual-mac system. After the change, it is necessary to load firmware in both units. Signed-off-by:
-
Johannes Berg authored
The nl80211 handling code should ensure as much as it can that the interface is in a valid state, it can certainly ensure the interface is running. Not doing so can cause calls through mac80211 into the driver that result in warnings and unspecified behaviour in the driver. Cc: stable@vger.kernel.org Reported-by:
Ben Greear <greearb@candelatech.com> Signed-off-by:
-
