1. 27 Nov, 2014 1 commit
  2. 26 Nov, 2014 3 commits
    • Dmitry Tunin's avatar
      Bluetooth: ath3k: Add support of MCI 13d3:3408 bt device · 3bb30a7c
      Dmitry Tunin authored
      Add support for Bluetooth MCI WB335 (AR9565) Wi-Fi+bt module. This
      Bluetooth module requires loading patch and sysconfig by ath3k driver.
      
      T:  Bus=01 Lev=02 Prnt=03 Port=00 Cnt=01 Dev#= 20 Spd=12   MxCh= 0
      D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
      P:  Vendor=13d3 ProdID=3408 Rev= 0.02
      C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
      A:  FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01
      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: default avatarDmitry Tunin <hanipouspilot@gmail.com>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Cc: stable@vger.kernel.org
      3bb30a7c
    • Varka Bhadram's avatar
      mac802154: remove unnecessary if statement · 473f3766
      Varka Bhadram authored
      Removes unnecessary if statement check for net device. Error check performed
      after alloc_netdev().
      
      	ndev = alloc_netdev(sizeof(*sdata) + local->hw.vif_data_size, name,
      			    NET_NAME_UNKNOWN, ieee802154_if_setup);
              if (!ndev)
                      return ERR_PTR(-ENOMEM);
      	..
      Signed-off-by: default avatarVarka Bhadram <varkab@cdac.in>
      Acked-by: default avatarAlexander Aring <alex.aring@gmail.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      473f3766
    • Varka Bhadram's avatar
      69bb631e
  3. 19 Nov, 2014 6 commits
  4. 18 Nov, 2014 4 commits
    • Fabio K's avatar
      Bluetooth: Add support for Broadcom BCM20702A1 variant · a86c02ea
      Fabio K authored
      This variant requires the flag BTUSB_BCM_PATCHRAM to work.
      
      Relevant details from /sys/kernel/debug/usb/devices:
      
      T:  Bus=01 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=13d3 ProdID=3404 Rev= 1.12
      S:  Manufacturer=Broadcom Corp
      S:  Product=BCM20702A0
      S:  SerialNumber=240A646F1XXX
      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=ff(vend.) 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=ff(vend.) 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=ff(vend.) 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=ff(vend.) 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
      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)
      
      The firmware was extracted from a Windows 8.1 64-bit installation
      and converted from 'hex' to 'hcd' for use in Linux.
      
      Under Windows it also identifies itself as BCM20702A0,
      but the firmware is named "BCM20702A1_001.002.014.1315.1356.hex"
      and is located in "%SYSTEMROOT%\system32\drivers\"
      (md5 67cf6bfdae61c4bb819a66da984f7913)
      (sha1 5f74cc6a9a3bf19ee0f8c3d01e4be34c609b188f)
      
      The same firmware file is also available as a download at
      http://www.asrock.com/mb/Intel/Z87E-ITX/?cat=Download&os=All
      marked as "Bluetooth driver ver:12.0.0.7820"
      
      'hcd' file should be placed at "brcm/BCM20702A0-13d3-3404.hcd"
      inside the firmware directory (e.g. "/lib/firmware")
      Signed-off-by: default avatarFabio K <healthkit@gmail.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      a86c02ea
    • Johan Hedberg's avatar
      Bluetooth: Call drain_workqueue() before resetting state · 76727c02
      Johan Hedberg authored
      Doing things like hci_conn_hash_flush() while holding the hdev lock is
      risky since its synchronous pending work cancellation could cause the
      L2CAP layer to try to reacquire the hdev lock. Right now there doesn't
      seem to be any obvious places where this would for certain happen but
      it's already enough to cause lockdep to start warning against the hdev
      and the work struct locks being taken in the "wrong" order:
      
      [  +0.000373] mgmt-tester/1603 is trying to acquire lock:
      [  +0.000292]  ((&conn->pending_rx_work)){+.+.+.}, at: [<c104266d>] flush_work+0x0/0x181
      [  +0.000270]
      but task is already holding lock:
      [  +0.000000]  (&hdev->lock){+.+.+.}, at: [<c13b9a80>] hci_dev_do_close+0x166/0x359
      [  +0.000000]
      which lock already depends on the new lock.
      
      [  +0.000000]
      the existing dependency chain (in reverse order) is:
      [  +0.000000]
      -> #1 (&hdev->lock){+.+.+.}:
      [  +0.000000]        [<c105ea8f>] lock_acquire+0xe3/0x156
      [  +0.000000]        [<c140c663>] mutex_lock_nested+0x54/0x375
      [  +0.000000]        [<c13d644b>] l2cap_recv_frame+0x293/0x1a9c
      [  +0.000000]        [<c13d7ca4>] process_pending_rx+0x50/0x5e
      [  +0.000000]        [<c1041a3f>] process_one_work+0x21c/0x436
      [  +0.000000]        [<c1041e3d>] worker_thread+0x1be/0x251
      [  +0.000000]        [<c1045a22>] kthread+0x94/0x99
      [  +0.000000]        [<c140f801>] ret_from_kernel_thread+0x21/0x30
      [  +0.000000]
      -> #0 ((&conn->pending_rx_work)){+.+.+.}:
      [  +0.000000]        [<c105e158>] __lock_acquire+0xa07/0xc89
      [  +0.000000]        [<c105ea8f>] lock_acquire+0xe3/0x156
      [  +0.000000]        [<c1042696>] flush_work+0x29/0x181
      [  +0.000000]        [<c1042864>] __cancel_work_timer+0x76/0x8f
      [  +0.000000]        [<c104288c>] cancel_work_sync+0xf/0x11
      [  +0.000000]        [<c13d4c18>] l2cap_conn_del+0x72/0x183
      [  +0.000000]        [<c13d8953>] l2cap_disconn_cfm+0x49/0x55
      [  +0.000000]        [<c13be37a>] hci_conn_hash_flush+0x7a/0xc3
      [  +0.000000]        [<c13b9af6>] hci_dev_do_close+0x1dc/0x359
      [  +0.012038]        [<c13bbe38>] hci_unregister_dev+0x6e/0x1a3
      [  +0.000000]        [<c12d33c1>] vhci_release+0x28/0x47
      [  +0.000000]        [<c10dd6a9>] __fput+0xd6/0x154
      [  +0.000000]        [<c10dd757>] ____fput+0xd/0xf
      [  +0.000000]        [<c1044bb2>] task_work_run+0x6b/0x8d
      [  +0.000000]        [<c1001bd2>] do_notify_resume+0x3c/0x3f
      [  +0.000000]        [<c140fa70>] work_notifysig+0x29/0x31
      [  +0.000000]
      other info that might help us debug this:
      
      [  +0.000000]  Possible unsafe locking scenario:
      
      [  +0.000000]        CPU0                    CPU1
      [  +0.000000]        ----                    ----
      [  +0.000000]   lock(&hdev->lock);
      [  +0.000000]                                lock((&conn->pending_rx_work));
      [  +0.000000]                                lock(&hdev->lock);
      [  +0.000000]   lock((&conn->pending_rx_work));
      [  +0.000000]
       *** DEADLOCK ***
      
      Fully fixing this would require some quite heavy refactoring to change
      how the hdev lock and hci_conn instances are handled together. A simpler
      solution for now which this patch takes is to try ensure that the hdev
      workqueue is empty before proceeding with the various cleanup calls,
      including hci_conn_hash_flush().
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      76727c02
    • Johan Hedberg's avatar
      Bluetooth: Use shorter "rand" name for "randomizer" · 38da1703
      Johan Hedberg authored
      The common short form of "randomizer" is "rand" in many places
      (including the Bluetooth specification). The shorter version also makes
      for easier to read code with less forced line breaks. This patch renames
      all occurences of "randomizer" to "rand" in the Bluetooth subsystem
      code.
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      38da1703
    • Johan Hedberg's avatar
      Bluetooth: Fix BR/EDR-only address checks for remote OOB data · c19a495c
      Johan Hedberg authored
      For now the mgmt commands dealing with remote OOB data are strictly
      BR/EDR-only. This patch fixes missing checks for the passed address type
      so that any non-BR/EDR value triggers the appropriate error response.
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      c19a495c
  5. 17 Nov, 2014 13 commits
  6. 15 Nov, 2014 9 commits
  7. 13 Nov, 2014 4 commits