1. 03 5月, 2012 3 次提交
  2. 01 5月, 2012 1 次提交
  3. 28 4月, 2012 8 次提交
  4. 25 4月, 2012 3 次提交
    • E
      mac80211: call ieee80211_mgd_stop() on interface stop · afa762f6
      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>
      afa762f6
    • M
      iwlwifi: use correct released ucode version · 78cbcf2b
      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>
      78cbcf2b
    • J
      iwlwifi: fix hardware queue programming · 5ef4acd5
      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>
      5ef4acd5
  5. 24 4月, 2012 8 次提交
    • S
      Add Foxconn / Hon Hai IDs for btusb module · 98514036
      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>
      98514036
    • S
      Bluetooth: Fix missing break in hci_cmd_complete_evt · 16cde993
      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>
      16cde993
    • E
      brcmsmac: "INTERMEDIATE but not AMPDU" only when tracing · 6ead629b
      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>
      6ead629b
    • L
      rtlwifi: Fix oops on unload · 44eb65cf
      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>
      44eb65cf
    • S
      ipw2200: Fix race condition in the command completion acknowledge · dd447319
      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>
      dd447319
    • S
      iwlwifi: do not nulify ctx->vif on reset · 8db4c7e2
      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>
      8db4c7e2
    • G
      ath9k: fix tx power settings for AR9287 · 83722bd4
      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>
      83722bd4
    • G
      ath9k: add an extra boolean parameter to ath9k_hw_apply_txpower · 64ea57d0
      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>
      64ea57d0
  6. 19 4月, 2012 1 次提交
  7. 18 4月, 2012 4 次提交
  8. 17 4月, 2012 1 次提交
  9. 16 4月, 2012 2 次提交
  10. 14 4月, 2012 7 次提交
  11. 13 4月, 2012 2 次提交
    • A
      Bluetooth: Add support for Atheros [13d3:3362] · 87522a43
      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>
      87522a43
    • M
      Bluetooth: btusb: Add vendor specific ID (0489 e042) for BCM20702A0 · 79cd7602
      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>
      79cd7602