- 01 5月, 2012 1 次提交
-
-
由 Felix Fietkau 提交于
EAP frames for stations in an AP VLAN are sent on the main AP interface to avoid race conditions wrt. moving stations. For that to work properly, sta_info_get_bss must be used instead of sta_info_get when sending EAP packets. Previously this was only done for cooked monitor injected packets, so this patch adds a check for tx->skb->protocol to the same place. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Cc: stable@vger.kernel.org Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 28 4月, 2012 8 次提交
-
-
由 Grazvydas Ignotas 提交于
This driver currently leaves elp_work behind when stopping, which occasionally results in data corruption because work function ends up accessing freed memory, typical symptoms of this are various worker_thread crashes. Fix it by cancelling elp_work. Cc: stable@vger.kernel.org # v2.6.37+ Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Grazvydas Ignotas 提交于
Currently SDIO glue frees it's own structure before calling wl1251_free_hw(), which in turn calls ieee80211_unregister_hw(). The later call may result in a need to communicate with the chip to stop it (as it happens now if the interface is still up before rmmod), which means calls are made back to the glue, resulting in freed memory access. Fix this by freeing glue data last. Cc: stable@vger.kernel.org # v2.6.37+ Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Seth Forshee 提交于
Commit 2a190322 (b43: reload phy and bss settings after core restarts) introduced an unconditional call to b43_op_config() at the end of b43_op_start(). When firmware fails to load this can wedge the system. There's no need to reload the configuration after a failed initialization anyway, so only make the call if initialization was successful. BugLink: http://bugs.launchpad.net/bugs/950295 Cc: Felix Fietkau <nbd@openwrt.org> Cc: <stable@vger.kernel.org> Signed-off-by: NSeth Forshee <seth.forshee@canonical.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Wey-Yi Guy 提交于
"iwlwifi: use correct released ucode version" change the ucode api ok from 6000G2 to 6000G2B, but it shall belong to 6030 device series, not the 6005 device series. Fix it Cc: stable@vger.kernel.org #3.3+ Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Jonathan Bither 提交于
When our driver device is removed on the AHB bus, our IO memory is never unmapped. Signed-off-by: NJonathan Bither <jonbither@gmail.com> Reviewed-by: NPavel Roskin <proski@gnu.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Franky Lin 提交于
dpc takes care of all data packets transmissions for sdio function 2. It is possible that it misses some completion events when the traffic is heavy or it's running on a slow cpu. A linked list is introduced to make sure dpc is invoked whenever needed. Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com> Reviewed-by: NArend van Spriel <arend@broadcom.com> Signed-off-by: NFranky Lin <frankyl@broadcom.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Franky Lin 提交于
SDIO stack doesn't have a structure for function 0. The structure pointer stored in card->sdio_func[0] is actually for function 1. With current implementation the register read/write is applied to function 1. This pathch fixes the issue. Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com> Reviewed-by: NArend van Spriel <arend@broadcom.com> Reviewed-by: NFlorian Fainelli <florian@openwrt.org> Reviewed-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NFranky Lin <frankyl@broadcom.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 25 4月, 2012 3 次提交
-
-
由 Eliad Peller 提交于
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: NEliad Peller <eliad@wizery.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Meenakshi Venkataraman 提交于
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: NMeenakshi Venkataraman <meenakshi.venkataraman@intel.com> Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
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: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 24 4月, 2012 8 次提交
-
-
由 Steven Harms 提交于
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: NSteven Harms <sjharms@gmail.com> Signed-off-by: NGustavo Padovan <gustavo@padovan.org>
-
由 Szymon Janc 提交于
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: NSzymon Janc <szymon.janc@tieto.com> Signed-off-by: NGustavo Padovan <gustavo@padovan.org>
-
由 Eldad Zack 提交于
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: NEldad Zack <eldad@fogrefinery.com> Acked-by: Franky Lin<frankyl@broadcom.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Larry Finger 提交于
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: NDave Airlie <airlied@gmail.com> Tested-by: NDave Airlie <airlied@gmail.com> Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net> Cc: Stable <stable@vger.kernel.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Stanislav Yakovlev 提交于
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: NStanislav Yakovlev <stas.yakovlev@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Stanislaw Gruszka 提交于
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: NStanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Gabor Juhos 提交于
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: NGabor Juhos <juhosg@openwrt.org> Acked-by: NSujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Gabor Juhos 提交于
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: NGabor Juhos <juhosg@openwrt.org> Acked-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 19 4月, 2012 1 次提交
-
-
由 AceLan Kao 提交于
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: NAceLan Kao <acelan.kao@canonical.com> Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
-
- 18 4月, 2012 4 次提交
-
-
由 Sujith Manoharan 提交于
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: NSujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Felix Fietkau 提交于
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: NFelix Fietkau <nbd@openwrt.org> Cc: stable@vger.kernel.org Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Wey-Yi Guy 提交于
Add Johannes Berg as the primary maintainer for iwlwifi driver Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Felix Fietkau 提交于
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: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 17 4月, 2012 1 次提交
-
-
由 Hauke Mehrtens 提交于
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: NNick Bowler <nbowler@elliptictech.com> Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de> Acked-by: NArend van Spriel <arend@broadcom.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 16 4月, 2012 2 次提交
-
-
由 Vishal Agarwal 提交于
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: NVishal Agarwal <vishal.agarwal@stericsson.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
-
由 Vishal Agarwal 提交于
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: NVishal Agarwal <vishal.agarwal@stericsson.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
-
- 14 4月, 2012 7 次提交
-
-
由 Bing Zhao 提交于
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: NBing Zhao <bzhao@marvell.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Felix Fietkau 提交于
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: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Jonathan Bither 提交于
Signed-off-by: NJonathan Bither <jonbither@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Jonathan Bither 提交于
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: NJonathan Bither <jonbither@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Lukasz Kucharczyk 提交于
Signed-off-by: NLukasz Kucharczyk <lukasz.kucharczyk@tieto.com> Cc: stable@vger.kernel.org Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Arend van Spriel 提交于
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: NFrancesco Saverio Schiavarelli <fschiava@libero.it> Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com> Reviewed-by: NBrett Rudley <brudley@broadcom.com> Signed-off-by: NArend van Spriel <arend@broadcom.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Amitkumar Karwar 提交于
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: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com> Signed-off-by: NKiran Divekar <dkiran@marvell.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 13 4月, 2012 2 次提交
-
-
由 AceLan Kao 提交于
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: NAceLan Kao <acelan.kao@canonical.com> Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
-
由 Manoj Iyer 提交于
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: NDennis Chua <dennis.chua@canonical.com> Signed-off-by: NManoj Iyer <manoj.iyer@canonical.com> Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
-
- 12 4月, 2012 3 次提交
-
-
由 Samuel Ortiz 提交于
Reported-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Larry Finger 提交于
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: NDa Xue <da@lessconfused.com> Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net> Cc: Stable <stable@vger.kernel.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Larry Finger 提交于
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: NLarry Finger <Larry.Finger@lwfinger.net> Cc: Stable <stable@vger.kernel.org> [This version good for 3.3+ - different patch for 3.2 - 2.6.39] Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-