1. 11 3月, 2016 1 次提交
  2. 29 2月, 2016 1 次提交
  3. 24 2月, 2016 2 次提交
  4. 10 12月, 2015 3 次提交
  5. 20 11月, 2015 1 次提交
  6. 05 11月, 2015 1 次提交
    • K
      Bluetooth: Fix possible deadlock in btusb · f6fc86f2
      Kuba Pawlak 提交于
      commit 8f9d02f4 introduced spinlocks
      in btusb_work. This is run in a context of a worqueue and can be interrupted
      by hardware irq. If it happens while spinlock is held, we have a deadlock.
      Solution is to use _irqsave/_resore version of locking
      
      [  466.460560] =================================
      [  466.460565] [ INFO: inconsistent lock state ]
      [  466.460572] 4.3.0-rc6+ #1 Tainted: G        W
      [  466.460576] ---------------------------------
      [  466.460582] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
      [  466.460589] kworker/0:2/94 [HC0[0]:SC0[0]:HE1:SE1] takes:
      [  466.460595]  (&(&data->rxlock)->rlock){?.-...}, at: [<ffffffffa0526923>] btusb_work+0xa3/0x3fd [btusb]
      [  466.460621] {IN-HARDIRQ-W} state was registered at:
      [  466.460625]   [<ffffffff811021b5>] __lock_acquire+0xc45/0x1e80
      [  466.460638]   [<ffffffff811040d5>] lock_acquire+0xe5/0x1f0
      [  466.460646]   [<ffffffff8182f108>] _raw_spin_lock+0x38/0x50
      [  466.460657]   [<ffffffffa0525448>] btusb_recv_intr+0x38/0x170 [btusb]
      [  466.460668]   [<ffffffffa0525626>] btusb_intr_complete+0xa6/0x130 [btusb]
      [  466.460679]   [<ffffffff815d8f1e>] __usb_hcd_giveback_urb+0x8e/0x160
      [  466.460690]   [<ffffffff815d911f>] usb_hcd_giveback_urb+0x3f/0x120
      [  466.460698]   [<ffffffff81606e4d>] uhci_giveback_urb+0xad/0x280
      [  466.460706]   [<ffffffff81608f64>] uhci_scan_schedule.part.33+0x6b4/0xbe0
      [  466.460714]   [<ffffffff81609b50>] uhci_irq+0xd0/0x180
      [  466.460722]   [<ffffffff815d8296>] usb_hcd_irq+0x26/0x40
      [  466.460729]   [<ffffffff81117d40>] handle_irq_event_percpu+0x40/0x300
      [  466.460739]   [<ffffffff81118040>] handle_irq_event+0x40/0x60
      [  466.460746]   [<ffffffff8111af39>] handle_fasteoi_irq+0x89/0x150
      [  466.460754]   [<ffffffff8101e0f3>] handle_irq+0x73/0x120
      [  466.460763]   [<ffffffff81832f11>] do_IRQ+0x61/0x120
      [  466.460772]   [<ffffffff8183084c>] ret_from_intr+0x0/0x31
      [  466.460780]   [<ffffffff81697a77>] cpuidle_enter+0x17/0x20
      [  466.460790]   [<ffffffff810f62c2>] call_cpuidle+0x32/0x60
      [  466.460800]   [<ffffffff810f65a8>] cpu_startup_entry+0x2b8/0x3f0
      [  466.460807]   [<ffffffff818214ca>] rest_init+0x13a/0x140
      [  466.460817]   [<ffffffff81f76029>] start_kernel+0x4a3/0x4c4
      [  466.460827]   [<ffffffff81f75339>] x86_64_start_reservations+0x2a/0x2c
      [  466.460837]   [<ffffffff81f75485>] x86_64_start_kernel+0x14a/0x16d
      [  466.460846] irq event stamp: 754913
      [  466.460851] hardirqs last  enabled at (754913): [<ffffffff8182f4cc>] _raw_spin_unlock_irq+0x2c/0x40
      [  466.460861] hardirqs last disabled at (754912): [<ffffffff8182f28d>] _raw_spin_lock_irq+0x1d/0x60
      [  466.460869] softirqs last  enabled at (753024): [<ffffffff810aeaa0>] __do_softirq+0x380/0x490
      [  466.460880] softirqs last disabled at (753009): [<ffffffff810aedef>] irq_exit+0x10f/0x120
      [  466.460888]
                     other info that might help us debug this:
      [  466.460894]  Possible unsafe locking scenario:
      
      [  466.460899]        CPU0
      [  466.460903]        ----
      [  466.460907]   lock(&(&data->rxlock)->rlock);
      [  466.460915]   <Interrupt>
      [  466.460918]     lock(&(&data->rxlock)->rlock);
      [  466.460926]
                      *** DEADLOCK ***
      
      [  466.460935] 2 locks held by kworker/0:2/94:
      [  466.460939]  #0:  ("events"){.+.+.+}, at: [<ffffffff810c69bb>] process_one_work+0x16b/0x660
      [  466.460958]  #1:  ((&data->work)){+.+...}, at: [<ffffffff810c69bb>] process_one_work+0x16b/0x660
      [  466.460974]
      Signed-off-by: NKuba Pawlak <kubax.t.pawlak@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      f6fc86f2
  7. 21 10月, 2015 13 次提交
    • M
      Bluetooth: btintel: Enable extra Intel vendor events · 213445b2
      Marcel Holtmann 提交于
      The Intel Bluetooth controllers can emit extra vendor specific events in
      error conditions or for debugging purposes. To make the life easier for
      engineers, enable them by default. When the vendor_diag options has been
      enabled, then additional debug events are also enabled.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      213445b2
    • M
      Bluetooth: btusb: Set manufacturer for Intel bootloader devices · e4c534bb
      Marcel Holtmann 提交于
      For Intel bootloader devices, set the manufacturer information so that
      it becomes possible to decode the boot process.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      e4c534bb
    • M
      Bluetooth: btusb: Add support for latest Apple controllers · 22f8e9db
      Marcel Holtmann 提交于
      The latest Apple Bluetooth controllers with Broadcom chip in it have
      a small design change. Instead of including a USB hub with mouse and
      keyboard devices, they are now HID interfaces on the same device.
      
      T:  Bus=04 Lev=02 Prnt=02 Port=04 Cnt=01 Dev#= 39 Spd=12   MxCh= 0
      D:  Ver= 2.01 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
      P:  Vendor=05ac ProdID=8290 Rev= 0.79
      S:  Manufacturer=Broadcom Corp.
      S:  Product=Bluetooth USB Host Controller
      C:* #Ifs= 6 Cfg#= 1 Atr=e0 MxPwr=  0mA
      A:  FirstIf#= 2 IfCount= 4 Cls=ff(vend.) Sub=01 Prot=01
      I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=01 Prot=01 Driver=usbhid
      E:  Ad=85(I) Atr=03(Int.) MxPS=   8 Ivl=10ms
      I:* If#= 1 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=01 Prot=02 Driver=usbhid
      E:  Ad=86(I) Atr=03(Int.) MxPS=   8 Ivl=10ms
      I:* If#= 2 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#= 3 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#= 3 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#= 3 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#= 3 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#= 3 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#= 3 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
      I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=btusb
      E:  Ad=84(I) Atr=02(Bulk) MxPS=  32 Ivl=0ms
      E:  Ad=04(O) Atr=02(Bulk) MxPS=  32 Ivl=0ms
      I:* If#= 5 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)
      
      The general layout of Bluetooth devices is that interface 0 is the main
      interface and interface 1 is for audio data. This design obviously moves
      it to main interface 2 and audio data on interface 3.
      
      Starting with the MacBookPro12,1 (early 2015 models) the new Broadcom
      BCM943602CS cards are used which show this interface layout.
      
      usb 4-1.5: New USB device found, idVendor=05ac, idProduct=8290
      usb 4-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=0
      usb 4-1.5: Product: Bluetooth USB Host Controller
      usb 4-1.5: Manufacturer: Broadcom Corp.
      Bluetooth: hci0: BCM: chip id 102 build 0243
      Bluetooth: hci0: BCM: product 05ac:8290
      Bluetooth: hci0: BCM20703A1 Generic USB UHE Apple 20Mhz fcbga_X87
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      22f8e9db
    • M
      Bluetooth: btusb: Set early vendor info for Intel and Broadcom · 49a5f782
      Marcel Holtmann 提交于
      For the controllers from Intel and Broadcom (including Apple), it is
      helpful to have the information about the manufacturer send out early.
      
      This patch sets the hdev->manufacturer information which will be send
      out before actually calling the vendor specific hdev->setup driver
      callback.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      49a5f782
    • D
      Bluetooth: ath3k: Add support of AR3012 0cf3:817b device · 18e0afab
      Dmitry Tunin 提交于
      T: Bus=04 Lev=02 Prnt=02 Port=04 Cnt=01 Dev#= 3 Spd=12 MxCh= 0
      D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
      P: Vendor=0cf3 ProdID=817b Rev=00.02
      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/1506615Signed-off-by: NDmitry Tunin <hanipouspilot@gmail.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Cc: stable@vger.kernel.org
      18e0afab
    • D
      Bluetooth: ath3k: Add new AR3012 0930:021c id · cd355ff0
      Dmitry Tunin 提交于
      This adapter works with the existing linux-firmware.
      
      T:  Bus=01 Lev=01 Prnt=01 Port=03 Cnt=02 Dev#=  3 Spd=12  MxCh= 0
      D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
      P:  Vendor=0930 ProdID=021c Rev=00.01
      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/1502781Signed-off-by: NDmitry Tunin <hanipouspilot@gmail.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Cc: stable@vger.kernel.org
      cd355ff0
    • S
      Bluetooth: btusb: Add support for Foxconn/Lenovo BCM43142A0 (105b:e065) · 2faf71ce
      Santtu Rekilä 提交于
      Recently salvaged this 'BCM43142A0' WiFi/Bluetooth module from a Lenovo laptop
      and noticed it doesn't work automatically, because the USB IDs are missing
      from btusb.c.
      
      Plugging in the adapter on Linux 4.1 (dmesg):
      usb 3-3.3.3: new full-speed USB device number 90 using xhci_hcd
      usb 3-3.3.3: New USB device found, idVendor=105b, idProduct=e065
      usb 3-3.3.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
      usb 3-3.3.3: Product: BCM43142A0
      usb 3-3.3.3: Manufacturer: Broadcom Corp
      usb 3-3.3.3: SerialNumber: 0090A286559E
      
      /sys/kernel/debug/usb/devices:
      T:  Bus=03 Lev=03 Prnt=22 Port=02 Cnt=02 Dev#= 90 Spd=12   MxCh= 0
      D:  Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
      P:  Vendor=105b ProdID=e065 Rev= 1.12
      S:  Manufacturer=Broadcom Corp
      S:  Product=BCM43142A0
      S:  SerialNumber=0090A286559E
      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)
      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=(none)
      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=(none)
      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=(none)
      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=(none)
      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=(none)
      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=(none)
      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)
      
      Support for the chipset was added in commit 88f9b65d and a similar BCM43142
      based device was added in commit 8f0c304c.
      
      To work around the issue, I got the firmware
      (BCM43142A0_001.001.011.0122.0153) off a Windows installation of Broadcom
      bluetooth driver and converted it to a .hcd -file via. hex2hcd and placed it
      in /lib/firmware/brcm/BCM.hcd. After that:
      
      $ echo "105b e065 0 19ff 0239" > /sys/bus/usb/drivers/btusb/new_id
      ...(plug in the adapter)
      usb 3-3.3.3: new full-speed USB device number 91 using xhci_hcd
      usb 3-3.3.3: New USB device found, idVendor=105b, idProduct=e065
      usb 3-3.3.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
      usb 3-3.3.3: Product: BCM43142A0
      usb 3-3.3.3: Manufacturer: Broadcom Corp
      usb 3-3.3.3: SerialNumber: 0090A286559E
      Bluetooth: hci0: BCM: chip id 70
      Bluetooth: hci0: BCM (001.001.011) build 0000
      bluetooth hci0: firmware: direct-loading firmware brcm/BCM.hcd
      Bluetooth: hci0: BCM (001.001.011) build 0154
      
      Bam, now it works for me!
      
      /sys/kernel/debug/usb/devices:
      T:  Bus=03 Lev=03 Prnt=22 Port=02 Cnt=02 Dev#= 92 Spd=12   MxCh= 0
      D:  Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
      P:  Vendor=105b ProdID=e065 Rev= 1.12
      S:  Manufacturer=Broadcom Corp
      S:  Product=BCM43142A0
      S:  SerialNumber=0090A286559E
      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)
      Signed-off-by: NSanttu Rekilä <sare@r00t3d.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      2faf71ce
    • M
      Bluetooth: btusb: Mark BCM2045 devices to have broken link key commands · 6c9d435d
      Marcel Holtmann 提交于
      The BCM2045 seems to have a problem with the stored link key commands
      and thus just mark them as broken.
      
        HCI Event: Command Complete (0x0e) plen 12
           Read Local Supported Features (0x04|0x0003) ncmd 1
           status 0x00
           Features: 0xff 0xff 0x8d 0xfe 0x8f 0xf9 0x00 0x80
        HCI Event: Command Complete (0x0e) plen 12
           Read Local Version Information (0x04|0x0001) ncmd 1
           status 0x00
           HCI Version: 2.0 (0x3) HCI Revision: 0x2000
           LMP Version: 2.0 (0x3) LMP Subversion: 0x410d
           Manufacturer: Broadcom Corporation (15)
        HCI Event: Command Complete (0x0e) plen 11
           Read Buffer Size (0x04|0x0005) ncmd 1
           status 0x00
           ACL MTU 1017:8 SCO MTU 64:0
        HCI Event: Command Complete (0x0e) plen 68
           Read Local Supported Commands (0x04|0x0002) ncmd 1
           status 0x00
           Commands: ffffff03feffcfffffffffff0300f8ff07
        HCI Event: Command Complete (0x0e) plen 4
           Delete Stored Link Key (0x03|0x0012) ncmd 1
           status 0x11 deleted 2048
           Error: Unsupported Feature or Parameter Value
      
      From the looks of it, this device seems genuine and not one of the
      devices that are neither Broadcom nor CSR devices in reality.
      
      T: Bus=04 Lev=02 Prnt=02 Port=02 Cnt=02 Dev#= 3 Spd=12 MxCh= 0
      D: Ver= 2.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
      P: Vendor=0a5c ProdID=2045 Rev= 1.12
      S: Manufacturer=Broadcom Corp
      S: Product=BCM2045A
      S: SerialNumber=000000000000
      C:* #Ifs= 4 Cfg#= 1 Atr=a0 MxPwr=100mA
      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
      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=00 Driver=(none)
      Reported-and-tested-by: NJulio González Mejías <juliolokooo@gmail.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      6c9d435d
    • M
      Bluetooth: btintel: Add diagnostic support for older controllers · 3e24767b
      Marcel Holtmann 提交于
      For the older controllers like Wilkens Peak and Stone Peak, enabling the
      traces requires to switch into manufacturer mode first. This patch does
      exactly that, but only for these older controllers.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      3e24767b
    • M
      Bluetooth: btintel: Set quirk for non-persistent diagnostic settings · d8270fbb
      Marcel Holtmann 提交于
      For Intel controllers the diagnostics settings are not persistent over
      HCI Reset. So set the quirk to programm them again on every power up.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      d8270fbb
    • M
      Bluetooth: btusb: Print information of Intel SfP lock states · 2220994e
      Marcel Holtmann 提交于
      The lock states from Intel SfP controllers can only be read once before
      loading the firmware. So for debugging purposes, print them out.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      2220994e
    • M
      Bluetooth: btintel: Add support for enabling tracing functionality · 6d2e50d2
      Marcel Holtmann 提交于
      For Intel controllers with firmware that allows tracing of baseband
      functionality this allows enabling it via set_diag driver callback.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      6d2e50d2
    • M
      Bluetooth: btusb: Add support for Broadcom LM_DIAG interface · 9d08f504
      Marcel Holtmann 提交于
      The Broadcom Bluetooth USB devices have a third interface that is
      dedicated for LM_DIAG messages. The If#= 2 describes this interface
      and it consists of one bulk in and one bulk endpoint.
      
      T:  Bus=01 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#= 38 Spd=12   MxCh= 0
      D:  Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
      P:  Vendor=19ff ProdID=0239 Rev= 1.12
      S:  Manufacturer=Broadcom Corp
      S:  Product=BCM20702A0
      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=btusb
      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)
      
      For all Broadcom based devices with this interface, the driver now
      claims it and schedules URBs for it. This allows to capture the
      LM_DIAG messages and allows forwarding them via hci_recv_diag into
      the diagnostic channel of the Bluetooth subsystem.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      9d08f504
  8. 05 10月, 2015 2 次提交
  9. 17 9月, 2015 3 次提交
    • K
      Bluetooth: Remove SCO fragments on connection close · 8f9d02f4
      Kuba Pawlak 提交于
      SCO packet reassembler may have a fragment of SCO packet, from
      previous connection, cached and not removed when SCO connection
      is ended. Packets from new SCO connection are then going to be
      attached to that fragment, creating an invalid SCO packets.
      
      Controllers like Intel's WilkinsPeak are always fragmenting
      SCO packet into 3 parts (#1, #2, #3). Packet #1 contains
      SCO header and audio data, others just audio data. if there is
      a fragment cached from previous connection, i.e. #1, first
      SCO packet from new connection is going to be attached to it
      creating packet consisting of fragments #1-#1-#2. This will
      be forwarded to upper layers. After that, fragment #3 is going
      to be used as a starting point for another SCO packet.
      It does not contain a SCO header, but the code expects it,
      casts a SCO header structure on it, and reads whatever audio
      data happens to be there as SCO packet length and handle.
      From that point on, we are assembling random data into SCO
      packets. Usually it recovers quickly as initial audio data
      contains mostly zeros (muted stream), but setups of over
      4 seconds were observed.
      Issue manifests itself by printing on the console:
      Bluetooth: hci0 SCO packet for unknown connection handle 48
      Bluetooth: hci0 SCO packet for unknown connection handle 2560
      Bluetooth: hci0 SCO packet for unknown connection handle 12288
      It may also show random handles if audio data was non-zeroed.
      Hcidump shows SCO packets with random length and handles.
      
      Few messages with handle 0 at connection creation are OK
      for some controllers (like WilkinsPeak), as there are SCO packets
      with zeroed handle at the beginning (possible controller bug).
      Few of such messages at connection end, with a handle looking
      sane (around 256, 512, 768 ...) is also OK, as these are last
      SCO packets that were assembled and sent up, before connection
      was ended, but were not handled in time.
      
      This issue may still manifest itself on WilkinsPeak as it sometimes,
      at SCO connection creation, does not send third fragment of first
      SCO packet (#1-#2-#1-#2-#3...). This is a firmware bug and this
      patch does not address it.
      Signed-off-by: NKuba Pawlak <kubax.t.pawlak@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      8f9d02f4
    • L
      Bluetooth: btusb: Use btintel_load_ddc_config for device config · e924d3d6
      Loic Poulain 提交于
      btintel_load_ddc_config is now part of btintel.
      Signed-off-by: NLoic Poulain <loic.poulain@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      e924d3d6
    • J
      Bluetooth: btusb: Detect new kind of counterfeit CSR controllers · 6cafcd95
      Johan Hedberg 提交于
      Controllers claiming to be CSR with LMP subversion 0x0c5c don't
      actually seem to be authentic CSR controllers. They also don't have
      their USB bcdDevice value matching the LMP subversion like all other
      CSR controllers:
      
      HCI:
      
      > HCI Event: Command Complete (0x0e) plen 12
            Read Local Version Information (0x04|0x0001) ncmd 1
              Status: Success (0x00)
              HCI version: Bluetooth 2.0 (0x03) - Revision 3164 (0x0c5c)
              LMP version: Bluetooth 2.0 (0x03) - Subversion 3164 (0x0c5c)
              Manufacturer: Cambridge Silicon Radio (10)
      
      USB:
      
      T: Bus=04 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 3 Spd=12 MxCh= 0
      D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=16 #Cfgs= 1
      P: Vendor=0a12 ProdID=0001 Rev= 1.34
      C:* #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=100mA
      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
      
      These controllers also have the HCI_Read_Stored_Link_Key command
      broken so it's important the right quirk is set for them.
      Reported-and-tested-by: NRhobison Alves Pereira <rhobison@hotmail.com>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      6cafcd95
  10. 29 8月, 2015 1 次提交
  11. 16 8月, 2015 1 次提交
    • P
      Bluetooth: btusb: mark 0c10:0000 devices with BTUSB_SWAVE · 4481c076
      Peter Poklop 提交于
      This patch enables quirk handling for Silicon Wave based devices and
      fixes kernel bug with id 42985.
      
      T:  Bus=01 Lev=01 Prnt=01 Port=07 Cnt=04 Dev#=  6 Spd=12   MxCh= 0
      D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
      P:  Vendor=0c10 ProdID=0000 Rev=15.00
      S:  Manufacturer=SiW
      S:  Product=SiW
      S:  SerialNumber=340A05F61100
      C:* #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr= 50mA
      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: NPeter Poklop <peter.poklop@gmail.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      4481c076
  12. 30 7月, 2015 1 次提交
    • D
      Bluetooth: btusb: match generic class code in interface descriptor · d63b2826
      Daniel Drake 提交于
      btusb currently has a generic match on USB device descriptors:
              { USB_DEVICE_INFO(0xe0, 0x01, 0x01) },
      
      However, http://www.usb.org/developers/defined_class states:
      
        Base Class E0h (Wireless Controller)
        This base class is defined for devices that are Wireless controllers.
        Values not shown in the table below are reserved. These class codes are
        to be used in Interface Descriptors, with the exception of the Bluetooth
        class code which can also be used in a Device Descriptor.
      
      Add a match on the interface descriptors accordingly.
      
      This fixes compatibility with the RTL8723AU device shown below.
      This device conforms to the USB Interface Association Descriptor
      specification, which requires the device to have class ef/02/01.
      The extra IAD descriptor then specifies that interfaces 0 and 1
      belong to the same function/driver, which is true. Provided that
      the Bluetooth device class spec accepts use of the IAD, I imagine that
      technically, all btusb devices should be configured like this.
      
      T:  Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#=  3 Spd=480  MxCh= 0
      D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
      P:  Vendor=0bda ProdID=0724 Rev= 2.00
      S:  Manufacturer=Realtek
      S:  Product=802.11n WLAN Adapter
      S:  SerialNumber=00e04c000001
      C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=500mA
      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=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      E:  Ad=83(I) 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=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      E:  Ad=83(I) 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=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      E:  Ad=83(I) 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=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      E:  Ad=83(I) 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=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      E:  Ad=83(I) 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=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      I:* If#= 2 Alt= 0 #EPs= 4 Cls=ff(vend.) Sub=ff Prot=ff Driver=rtl8723au
      E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=87(I) Atr=03(Int.) MxPS=  64 Ivl=500us
      Signed-off-by: NDaniel Drake <drake@endlessm.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      d63b2826
  13. 23 7月, 2015 3 次提交
  14. 19 6月, 2015 1 次提交
    • D
      Bluetooth: ath3k: Add support of 04ca:300d AR3012 device · 7e730c7f
      Dmitry Tunin 提交于
      BugLink: https://bugs.launchpad.net/bugs/1394368
      
      This device requires new firmware files
       AthrBT_0x11020100.dfu and ramps_0x11020100_40.dfu added to
      /lib/firmware/ar3k/ that are not included in linux-firmware yet.
      
      T: Bus=02 Lev=01 Prnt=01 Port=04 Cnt=03 Dev#= 5 Spd=12 MxCh= 0
      D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
      P: Vendor=04ca ProdID=300d Rev= 0.01
      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
      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: NDmitry Tunin <hanipouspilot@gmail.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Cc: stable@vger.kernel.org
      7e730c7f
  15. 17 6月, 2015 1 次提交
    • T
      Bluetooth: btusb: Add routine for applying Intel DDC parameters · 52cc9168
      Tedd Ho-Jeong An 提交于
      This patch adds the routine to apply the DDC parameter from device
      specific ddc file.
      
      Once the device is rest to operational mode, optionally, it can
      download the device specific configration (DDC) parameters before
      the BlueZ starts the stack initialization.
      
      It opens the DDC file based on HW_VARIANT and DEV_REVISION and
      send ID/Value with HCI_Intel_Write_DDC command.
      
      Format of DDC file
      DDC file contains one or more number of DDC structure.
      
      DDC Structure
      It has 'Length' field of one octet, DDC 'ID' field of
      two octets followed by the array of DDC 'Value' that gives
      the value of parameters itself.
      'Length' contains the length of DDC 'ID' and DDC 'Value'.
      
      +------------+----------+
      | Size(byte) |    Name  |
      +------------+----------+
      |      1     | Length   |
      +------------+----------+
      |      2     | ID       |
      +------------+----------+
      | Length - 2 | Value    |
      +------------+----------+
      Signed-off-by: NTedd Ho-Jeong An <tedd.an@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      52cc9168
  16. 09 6月, 2015 1 次提交
    • M
      Bluetooth: btusb: Fix secure send command length alignment on Intel 8260 · e66890a9
      Marcel Holtmann 提交于
      This patch fixes the command length alignment issue for Intel Bluetooth
      8260.
      
      The length of parameters in the firmware downloading command must be
      multiplication of 4. If not, the command must append Intel_NOP command
      with extra parameters, zeros, at the end, and the firmware file is
      already included Intel_NOP command for alignment.
      
      This patch checks the next command and if the next command is Intel_NOP
      command, it reads the Intel_NOP command and send them together.
      
      For example, if the data from the firmware file looks like this:
      8E FC 03 11 22 33 02 FC 03 00 00 00
      
      Previously, btusb sends two commands:
      09 FC 06 8E FC 03 11 22 33
      09 FC 06 02 FC 03 00 00 00
      
      This won't work because the length of parameters are 6 which violates
      the 4 byte alignment.
      
      This patch will append them together and send as one command:
      09 FC 0C 8E FC 03 11 22 33 02 FC 03 00 00 00
      
      Based on previous work from Tedd Ho-Jeong An <tedd.an@intel.com>
      Reported-by: NTedd Ho-Jeong An <tedd.an@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Tested-by: NTedd Ho-Jeong An <tedd.an@intel.com>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Cc: stable@vger.kernel.org
      e66890a9
  17. 08 6月, 2015 4 次提交