1. 03 Dec, 2014 3 commits
  2. 02 Dec, 2014 1 commit
    • Johan Hedberg's avatar
      Bluetooth: Track both local and remote L2CAP fixed channel mask · 0bd49fc7
      Johan Hedberg authored
      To pave the way for future fixed channels to be added easily we should
      track both the local and remote mask on a per-L2CAP connection (struct
      l2cap_conn) basis. So far the code has used a global variable in a racy
      way which anyway needs fixing.
      
      This patch renames the existing conn->fixed_chan_mask that tracked
      the remote mask to conn->remote_fixed_chan and adds a new variable
      conn->local_fixed_chan to track the local mask. Since the HS support
      info is now available in the local mask we can remove the
      conn->hs_enabled variable.
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      0bd49fc7
  3. 27 Nov, 2014 1 commit
  4. 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
  5. 19 Nov, 2014 6 commits
  6. 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
  7. 17 Nov, 2014 13 commits
  8. 15 Nov, 2014 9 commits