10 Dec, 2015

3 commits

  • The Intel Version Read command is used to retrieve information
    about hardware and firmware version/revision of Intel Bluetooth
    controllers. This is an Intel generic command used in USB and
    UART drivers.

    Signed-off-by: Loic Poulain
    Signed-off-by: Marcel Holtmann

    Loic Poulain
     
  • Older Intel controllers need to enter manufacturing mode to perform
    some vendor specific operations (patching, configuration...).
    Add enter/exit manufaturing methods and refactor existing
    manufacturing code.
    Exit can be configured to perform a reset. Reset can be performed
    either with patches activated or deactivated.

    Signed-off-by: Loic Poulain
    Signed-off-by: Marcel Holtmann

    Loic Poulain
     
  • BugLink: https://bugs.launchpad.net/bugs/1522949

    T: Bus=03 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=0930 ProdID=0225 Rev=01.12
    S: Manufacturer=Broadcom Corp
    S: Product=BCM43142A0
    S: SerialNumber=4CBB58034671
    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)

    Signed-off-by: Dmitry Tunin
    Signed-off-by: Marcel Holtmann
    Cc: stable@vger.kernel.org

    Dmitry Tunin
     

20 Nov, 2015

1 commit


05 Nov, 2015

1 commit

  • commit 8f9d02f470f48416444ac3a1eacecdd0f743f1a7 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: [] btusb_work+0xa3/0x3fd [btusb]
    [ 466.460621] {IN-HARDIRQ-W} state was registered at:
    [ 466.460625] [] __lock_acquire+0xc45/0x1e80
    [ 466.460638] [] lock_acquire+0xe5/0x1f0
    [ 466.460646] [] _raw_spin_lock+0x38/0x50
    [ 466.460657] [] btusb_recv_intr+0x38/0x170 [btusb]
    [ 466.460668] [] btusb_intr_complete+0xa6/0x130 [btusb]
    [ 466.460679] [] __usb_hcd_giveback_urb+0x8e/0x160
    [ 466.460690] [] usb_hcd_giveback_urb+0x3f/0x120
    [ 466.460698] [] uhci_giveback_urb+0xad/0x280
    [ 466.460706] [] uhci_scan_schedule.part.33+0x6b4/0xbe0
    [ 466.460714] [] uhci_irq+0xd0/0x180
    [ 466.460722] [] usb_hcd_irq+0x26/0x40
    [ 466.460729] [] handle_irq_event_percpu+0x40/0x300
    [ 466.460739] [] handle_irq_event+0x40/0x60
    [ 466.460746] [] handle_fasteoi_irq+0x89/0x150
    [ 466.460754] [] handle_irq+0x73/0x120
    [ 466.460763] [] do_IRQ+0x61/0x120
    [ 466.460772] [] ret_from_intr+0x0/0x31
    [ 466.460780] [] cpuidle_enter+0x17/0x20
    [ 466.460790] [] call_cpuidle+0x32/0x60
    [ 466.460800] [] cpu_startup_entry+0x2b8/0x3f0
    [ 466.460807] [] rest_init+0x13a/0x140
    [ 466.460817] [] start_kernel+0x4a3/0x4c4
    [ 466.460827] [] x86_64_start_reservations+0x2a/0x2c
    [ 466.460837] [] x86_64_start_kernel+0x14a/0x16d
    [ 466.460846] irq event stamp: 754913
    [ 466.460851] hardirqs last enabled at (754913): [] _raw_spin_unlock_irq+0x2c/0x40
    [ 466.460861] hardirqs last disabled at (754912): [] _raw_spin_lock_irq+0x1d/0x60
    [ 466.460869] softirqs last enabled at (753024): [] __do_softirq+0x380/0x490
    [ 466.460880] softirqs last disabled at (753009): [] 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]
    [ 466.460918] lock(&(&data->rxlock)->rlock);
    [ 466.460926]
    *** DEADLOCK ***

    [ 466.460935] 2 locks held by kworker/0:2/94:
    [ 466.460939] #0: ("events"){.+.+.+}, at: [] process_one_work+0x16b/0x660
    [ 466.460958] #1: ((&data->work)){+.+...}, at: [] process_one_work+0x16b/0x660
    [ 466.460974]

    Signed-off-by: Kuba Pawlak
    Signed-off-by: Marcel Holtmann

    Kuba Pawlak
     

21 Oct, 2015

13 commits

  • 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: Marcel Holtmann
    Signed-off-by: Johan Hedberg

    Marcel Holtmann
     
  • For Intel bootloader devices, set the manufacturer information so that
    it becomes possible to decode the boot process.

    Signed-off-by: Marcel Holtmann
    Signed-off-by: Johan Hedberg

    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: Marcel Holtmann
    Signed-off-by: Johan Hedberg

    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: Marcel Holtmann
    Signed-off-by: Johan Hedberg

    Marcel Holtmann
     
  • 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/1506615

    Signed-off-by: Dmitry Tunin
    Signed-off-by: Marcel Holtmann
    Cc: stable@vger.kernel.org

    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/1502781

    Signed-off-by: Dmitry Tunin
    Signed-off-by: Marcel Holtmann
    Cc: stable@vger.kernel.org

    Dmitry Tunin
     
  • 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 88f9b65 and a similar BCM43142
    based device was added in commit 8f0c304.

    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: Santtu Rekilä
    Signed-off-by: Marcel Holtmann

    Santtu Rekilä
     
  • 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: Julio González Mejías
    Signed-off-by: Marcel Holtmann
    Signed-off-by: Johan Hedberg

    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: Marcel Holtmann
    Signed-off-by: Johan Hedberg

    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: Marcel Holtmann
    Signed-off-by: Johan Hedberg

    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: Marcel Holtmann
    Signed-off-by: Johan Hedberg

    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: Marcel Holtmann
    Signed-off-by: Johan Hedberg

    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: Marcel Holtmann
    Signed-off-by: Johan Hedberg

    Marcel Holtmann
     

05 Oct, 2015

2 commits


17 Sep, 2015

3 commits

  • 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: Kuba Pawlak
    Signed-off-by: Marcel Holtmann

    Kuba Pawlak
     
  • btintel_load_ddc_config is now part of btintel.

    Signed-off-by: Loic Poulain
    Signed-off-by: Marcel Holtmann

    Loic Poulain
     
  • 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: Rhobison Alves Pereira
    Signed-off-by: Johan Hedberg
    Signed-off-by: Marcel Holtmann

    Johan Hedberg
     

29 Aug, 2015

1 commit


16 Aug, 2015

1 commit

  • 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: Peter Poklop
    Signed-off-by: Marcel Holtmann

    Peter Poklop
     

30 Jul, 2015

1 commit

  • 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: Daniel Drake
    Signed-off-by: Marcel Holtmann

    Daniel Drake
     

23 Jul, 2015

3 commits


19 Jun, 2015

1 commit

  • 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: Dmitry Tunin
    Signed-off-by: Marcel Holtmann
    Cc: stable@vger.kernel.org

    Dmitry Tunin
     

17 Jun, 2015

1 commit

  • 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: Tedd Ho-Jeong An
    Signed-off-by: Marcel Holtmann

    Tedd Ho-Jeong An
     

09 Jun, 2015

1 commit

  • 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

    Reported-by: Tedd Ho-Jeong An
    Signed-off-by: Marcel Holtmann
    Tested-by: Tedd Ho-Jeong An
    Signed-off-by: Johan Hedberg
    Cc: stable@vger.kernel.org

    Marcel Holtmann
     

08 Jun, 2015

4 commits

  • That patch corrects the typo in usb vendor id for Roper Class 1 Bluetooth
    Dongle. Problem with typo is present since 4.0 kernel.

    Content /sys/kernel/debug/usb/devices for these dongle:

    T: Bus=05 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0
    D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
    P: Vendor=1310 ProdID=0001 Rev=15.00
    S: Manufacturer=SiW
    S: Product=SiW
    S: SerialNumber=E7BB050D0B00
    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: Aleksei Volkov
    Signed-off-by: Marcel Holtmann
    Cc: stable@vger.kernel.org # 4.0.x

    Aleksei Volkov
     
  • The btusb_read_local_version function has only a single user and with
    that just move its functionality in place where it belongs.

    Signed-off-by: Marcel Holtmann
    Signed-off-by: Johan Hedberg

    Marcel Holtmann
     
  • The __hci_cmd_sync function already handles the command status and
    command complete errors. No need to check the status field again.

    Signed-off-by: Marcel Holtmann
    Signed-off-by: Johan Hedberg

    Marcel Holtmann
     
  • The SKB returned from the Intel specific version information command is
    missing a kfree_skb.

    Signed-off-by: Marcel Holtmann
    Signed-off-by: Johan Hedberg
    Cc: stable@vger.kernel.org

    Marcel Holtmann
     

07 Jun, 2015

2 commits

  • BugLink: https://bugs.launchpad.net/bugs/1427680

    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=01 Lev=01 Prnt=01 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=13d3 ProdID=3474 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

    Signed-off-by: Dmitry Tunin
    Signed-off-by: Marcel Holtmann
    Cc: stable@vger.kernel.org

    Dmitry Tunin
     
  • BugLink: https://bugs.launchpad.net/bugs/1462614

    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=03 Lev=01 Prnt=01 Port=09 Cnt=06 Dev#= 7 Spd=12 MxCh= 0
    D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
    P: Vendor=0489 ProdID=e076 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=(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=e0(wlcon) 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=e0(wlcon) 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=e0(wlcon) 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=e0(wlcon) 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=e0(wlcon) 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=e0(wlcon) 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

    Signed-off-by: Dmitry Tunin
    Signed-off-by: Marcel Holtmann
    Cc: stable@vger.kernel.org

    Dmitry Tunin
     

31 May, 2015

1 commit

  • …etooth/bluetooth-next

    Johan Hedberg says:

    ====================
    pull request: bluetooth-next 2015-05-28

    Here's a set of patches intended for 4.2. The majority of the changes
    are on the 802.15.4 side of things rather than Bluetooth related:

    - All sorts of cleanups & fixes to ieee802154 and related drivers
    - Rework of tx power support in ieee802154 and its drivers
    - Support for setting ieee802154 tx power through nl802154
    - New IDs for the btusb driver
    - Various cleanups & smaller fixes to btusb
    - New btrtl driver for Realtec devices
    - Fix suspend/resume for Realtek devices

    Please let me know if there are any issues pulling. Thanks.
    ====================

    Signed-off-by: David S. Miller <davem@davemloft.net>

    David S. Miller
     

26 May, 2015

1 commit

  • Realtek btusb devices don't currently work after suspend/resume because
    the updated firmware is quietly lost - the USB hub doesn't notice any
    status change upon resume, but some kind of reset has definitely
    happened as the LMP subversion has reverted to its original value.

    Set the reset_resume flag to trigger probe and upload the new firmware
    again.

    Like the vendor code, I assume this is not needed when the device is
    selected as a wakeup source and hence will retain power during suspend.
    On the 2 products I have to hand, when trying this configuration the
    hardware seems unable to keep the device powered up during suspend.
    The USB hub then detects a status change on resume and does a reset,
    so we do not end up in broken state.

    Signed-off-by: Daniel Drake
    Signed-off-by: Marcel Holtmann

    Daniel Drake