11 Feb, 2020

2 commits

  • commit 7ecacafc240638148567742cca41aa7144b4fe1e upstream.

    After commit 9e45524a0111 ("Bluetooth: btusb: Fix suspend issue for
    Realtek devices") both WiFi and Bluetooth stop working after reboot:
    [ 34.322617] usb 1-8: reset full-speed USB device number 3 using xhci_hcd
    [ 34.450401] usb 1-8: device descriptor read/64, error -71
    [ 34.694375] usb 1-8: device descriptor read/64, error -71
    ...
    [ 44.599111] rtw_pci 0000:02:00.0: failed to poll offset=0x5 mask=0x3 value=0x0
    [ 44.599113] rtw_pci 0000:02:00.0: mac power on failed
    [ 44.599114] rtw_pci 0000:02:00.0: failed to power on mac
    [ 44.599114] rtw_pci 0000:02:00.0: leave idle state failed
    [ 44.599492] rtw_pci 0000:02:00.0: failed to leave ips state
    [ 44.599493] rtw_pci 0000:02:00.0: failed to leave idle state

    That commit removed USB_QUIRK_RESET_RESUME, which not only resets the USB
    device after resume, it also prevents the device from being runtime
    suspended by USB core. My experiment shows if the Realtek btusb device
    ever runtime suspends once, the entire wireless module becomes useless
    after reboot.

    So let's explicitly disable runtime suspend on Realtek btusb device for
    now.

    Fixes: 9e45524a0111 ("Bluetooth: btusb: Fix suspend issue for Realtek devices")
    Signed-off-by: Kai-Heng Feng
    Signed-off-by: Marcel Holtmann
    Signed-off-by: Greg Kroah-Hartman

    Kai-Heng Feng
     
  • commit 3168c19d7eb17a0108a3b60ad8e8c1b18ea05c63 upstream.

    Currently the error return path when the call to btusb_mtk_hci_wmt_sync
    fails does not free fw. Fix this by returning via the error_release_fw
    label that performs the free'ing.

    Addresses-Coverity: ("Resource leak")
    Fixes: a1c49c434e15 ("Bluetooth: btusb: Add protocol support for MediaTek MT7668U USB devices")
    Signed-off-by: Colin Ian King
    Signed-off-by: Marcel Holtmann
    Signed-off-by: Greg Kroah-Hartman

    Colin Ian King
     

01 Feb, 2020

2 commits

  • [ Upstream commit a4f95f31a9f38d9bb1fd313fcc2d0c0d48116ee3 ]

    Some devices ship with the controller default address, like the
    Orange Pi 3 (BCM4345C5).

    Allow the bootloader to set a valid address through the device tree.

    Signed-off-by: Andre Heider
    Signed-off-by: Marcel Holtmann
    Signed-off-by: Sasha Levin

    Andre Heider
     
  • commit 22cc6b7a1dbb58da4afc539d9b7d470b23a25eea upstream.

    USB completion handlers are called in atomic context and must
    specifically not allocate memory using GFP_KERNEL.

    Fixes: a1c49c434e15 ("Bluetooth: btusb: Add protocol support for MediaTek MT7668U USB devices")
    Cc: stable # 5.3
    Cc: Sean Wang
    Signed-off-by: Johan Hovold
    Signed-off-by: Marcel Holtmann
    Signed-off-by: Greg Kroah-Hartman

    Johan Hovold
     

09 Jan, 2020

1 commit

  • commit 3d44a6fd0775e6215e836423e27f8eedf8c871ea upstream.

    If setup() fails a reference for runtime PM has already
    been taken. Proper use of the error handling in btusb_open()is needed.
    You cannot just return.

    Fixes: ace31982585a3 ("Bluetooth: btusb: Add setup callback for chip init on USB")
    Signed-off-by: Oliver Neukum
    Signed-off-by: Marcel Holtmann
    Signed-off-by: Greg Kroah-Hartman

    Oliver Neukum
     

31 Dec, 2019

1 commit

  • [ Upstream commit 42d22098127d6384f789107f59caae87d7520fc4 ]

    The btusb_rtl_cmd_timeout() function is used inside of an
    ifdef, leading to a warning when this part is hidden
    from the compiler:

    drivers/bluetooth/btusb.c:530:13: error: unused function 'btusb_rtl_cmd_timeout' [-Werror,-Wunused-function]

    Use an IS_ENABLED() check instead so the compiler can see
    the code and then discard it silently.

    Fixes: d7ef0d1e3968 ("Bluetooth: btusb: Use cmd_timeout to reset Realtek device")
    Signed-off-by: Arnd Bergmann
    Signed-off-by: Marcel Holtmann
    Signed-off-by: Sasha Levin

    Arnd Bergmann
     

29 Nov, 2019

2 commits

  • commit cef456cd354ef485f12d57000c455e83e416a2b6 upstream.

    As nice as it would be to update firmware faster, that patch broke
    at least two different boards, an OMAP4+WL1285 based Motorola Droid
    4, as reported by Sebasian Reichel and the Logic PD i.MX6Q +
    WL1837MOD.

    This reverts commit a2e02f38eff84f199c8e32359eb213f81f270047.

    Signed-off-by: Adam Ford
    Acked-by: Sebastian Reichel
    Cc: stable@vger.kernel.org
    Signed-off-by: Marcel Holtmann
    Signed-off-by: Greg Kroah-Hartman

    Adam Ford
     
  • commit cf94da6f502d8caecabd56b194541c873c8a7a3c upstream.

    Syzbot reported an invalid-free that I introduced fixing a memleak.

    bcsp_recv() also frees bcsp->rx_skb but never nullifies its value.
    Nullify bcsp->rx_skb every time it is freed.

    Signed-off-by: Tomas Bortoli
    Reported-by: syzbot+a0d209a4676664613e76@syzkaller.appspotmail.com
    Signed-off-by: Marcel Holtmann
    Cc: Alexander Potapenko
    Signed-off-by: Greg Kroah-Hartman

    Tomas Bortoli
     

15 Sep, 2019

1 commit


05 Sep, 2019

14 commits


04 Sep, 2019

3 commits

  • When returning from bpa10x_send_frame, it is necessary to propagate any
    potential errno returned from usb_submit_urb.

    Signed-off-by: Navid Emamdoost
    Signed-off-by: Marcel Holtmann

    Navid Emamdoost
     
  • Looks like Deadlock is observed in hci_qca while performing
    stress and stability tests. Since same lock is getting
    acquired from qca_wq_awake_rx and hci_ibs_tx_idle_timeout
    seeing spinlock recursion, irqs should be disable while
    acquiring the spinlock always.

    Signed-off-by: Harish Bandi
    Signed-off-by: Marcel Holtmann

    Harish Bandi
     
  • The ASUS X412FA laptop contains a Realtek RTL8822CE device with an
    associated BT chip using a USB ID of 04ca:4005. This ID is added to the
    driver.

    The /sys/kernel/debug/usb/devices portion for this device is:

    T: Bus=01 Lev=01 Prnt=01 Port=09 Cnt=04 Dev#= 4 Spd=12 MxCh= 0
    D: Ver= 1.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
    P: Vendor=04ca ProdID=4005 Rev= 0.00
    S: Manufacturer=Realtek
    S: Product=Bluetooth Radio
    S: SerialNumber=00e04c000001
    C:* #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr=500mA
    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= 64 Ivl=0ms
    E: Ad=82(I) 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=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

    Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=204707
    Signed-off-by: Jian-Hong Pan
    Signed-off-by: Marcel Holtmann

    Jian-Hong Pan
     

30 Aug, 2019

1 commit

  • This reverts commit a0085f2510e8976614ad8f766b209448b385492f.

    This commit has caused regressions in notebooks that support suspend
    to idle such as the XPS 9360, XPS 9370 and XPS 9380.

    These notebooks will wakeup from suspend to idle from an unsolicited
    advertising packet from an unpaired BLE device.

    In a bug report it was sugggested that this is caused by a generic
    lack of LE privacy support. Revert this commit until that behavior
    can be avoided by the kernel.

    Fixes: a0085f2510e8 ("Bluetooth: btusb: driver to enable the usb-wakeup feature")
    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=200039
    Link: https://marc.info/?l=linux-bluetooth&m=156441081612627&w=2
    Link: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/750073/
    CC: Bastien Nocera
    CC: Christian Kellner
    CC: Sukumar Ghorai
    Signed-off-by: Mario Limonciello
    Signed-off-by: Marcel Holtmann

    Mario Limonciello
     

14 Aug, 2019

1 commit


13 Aug, 2019

7 commits

  • This patch will reset the download flag to default value
    before retrieving the download mode type.

    Fixes: 32646db8cc28 ("Bluetooth: btqca: inject command complete event during fw download")
    Signed-off-by: Balakrishna Godavarthi
    Tested-by: Claire Chang
    Reviewed-by: Claire Chang
    Signed-off-by: Marcel Holtmann

    Balakrishna Godavarthi
     
  • commit 32646db8cc28 ("Bluetooth: btqca: inject command complete event
    during fw download") added qca_inject_cmd_complete_event() for certain
    qualcomm chips. However, qca_download_firmware() will return without
    calling release_firmware() in this case.

    This leads to a memory leak like the following found by kmemleak:

    unreferenced object 0xfffffff3868a5880 (size 128):
    comm "kworker/u17:5", pid 347, jiffies 4294676481 (age 312.157s)
    hex dump (first 32 bytes):
    ac fd 00 00 00 00 00 00 00 d0 7e 17 80 ff ff ff ..........~.....
    00 00 00 00 00 00 00 00 00 59 8a 86 f3 ff ff ff .........Y......
    backtrace:
    [] kmem_cache_alloc_trace+0x194/0x298
    [] _request_firmware+0x74/0x4e4
    [] request_firmware+0x44/0x64
    [] qca_download_firmware+0x74/0x6e4 [btqca]
    [] qca_uart_setup+0xc0/0x2b0 [btqca]
    [] qca_setup+0x204/0x570 [hci_uart]
    [] hci_uart_setup+0xa8/0x148 [hci_uart]
    [] hci_dev_do_open+0x144/0x530 [bluetooth]
    [] hci_power_on+0x84/0x288 [bluetooth]
    [] process_one_work+0x210/0x420
    [] worker_thread+0x2c4/0x3e4
    [] kthread+0x124/0x134
    [] ret_from_fork+0x10/0x18
    [] 0xffffffffffffffff
    unreferenced object 0xfffffff37b16de00 (size 128):
    comm "kworker/u17:5", pid 347, jiffies 4294676873 (age 311.766s)
    hex dump (first 32 bytes):
    da 07 00 00 00 00 00 00 00 50 ff 0b 80 ff ff ff .........P......
    00 00 00 00 00 00 00 00 00 dd 16 7b f3 ff ff ff ...........{....
    backtrace:
    [] kmem_cache_alloc_trace+0x194/0x298
    [] _request_firmware+0x74/0x4e4
    [] request_firmware+0x44/0x64
    [] qca_download_firmware+0x74/0x6e4 [btqca]
    [] qca_uart_setup+0x144/0x2b0 [btqca]
    [] qca_setup+0x204/0x570 [hci_uart]
    [] hci_uart_setup+0xa8/0x148 [hci_uart]
    [] hci_dev_do_open+0x144/0x530 [bluetooth]
    [] hci_power_on+0x84/0x288 [bluetooth]
    [] process_one_work+0x210/0x420
    [] worker_thread+0x2c4/0x3e4
    [] kthread+0x124/0x134
    [] ret_from_fork+0x10/0x18
    [] 0xffffffffffffffff

    Make sure release_firmware() is called aftre
    qca_inject_cmd_complete_event() to avoid the memory leak.

    Fixes: 32646db8cc28 ("Bluetooth: btqca: inject command complete event during fw download")
    Signed-off-by: Claire Chang
    Reviewed-by: Balakrishna Godavarthi
    Signed-off-by: Marcel Holtmann

    Claire Chang
     
  • WCN399x chips are coex chips, it needs a VS pre shutdown
    command while turning off the BT. So that chip can inform
    BT is OFF to other active clients.

    Signed-off-by: Harish Bandi
    Signed-off-by: Marcel Holtmann

    Harish Bandi
     
  • The opcode of the command injected by commit 32646db8cc28 ("Bluetooth:
    btqca: inject command complete event during fw download") uses the CPU
    byte format, however it should always be little endian. In practice it
    shouldn't really matter, since all we need is an opcode != 0, but still
    let's do things correctly and keep sparse happy.

    Fixes: 32646db8cc28 ("Bluetooth: btqca: inject command complete event during fw download")
    Reported-by: kbuild test robot
    Signed-off-by: Matthias Kaehlcke
    Signed-off-by: Marcel Holtmann

    Matthias Kaehlcke
     
  • Use kfree_skb() instead of kfree() to free sk_buff.

    Fixes: 2faa3f15fa2f ("Bluetooth: hci_qca: wcn3990: Drop baudrate change vendor event")
    Signed-off-by: Wei Yongjun
    Reviewed-by: Matthias Kaehlcke
    Signed-off-by: Marcel Holtmann

    Wei Yongjun
     
  • On WCN3990 downloading the NVM sometimes fails with a "TLV response
    size mismatch" error:

    [ 174.949955] Bluetooth: btqca.c:qca_download_firmware() hci0: QCA Downloading qca/crnv21.bin
    [ 174.958718] Bluetooth: btqca.c:qca_tlv_send_segment() hci0: QCA TLV response size mismatch

    It seems the controller needs a short time after downloading the
    firmware before it is ready for the NVM. A delay as short as 1 ms
    seems sufficient, make it 10 ms just in case. No event is received
    during the delay, hence we don't just silently drop an extra event.

    Signed-off-by: Matthias Kaehlcke
    Signed-off-by: Marcel Holtmann

    Matthias Kaehlcke
     
  • Fix to return error code -EINVAL from the error handling
    case instead of 0, as done elsewhere in this function.

    Fixes: a1c49c434e15 ("Bluetooth: btusb: Add protocol support for MediaTek MT7668U USB devices")
    Signed-off-by: Wei Yongjun
    Signed-off-by: Marcel Holtmann

    Wei Yongjun
     

01 Aug, 2019

1 commit

  • Certain ttys operations (pty_unix98_ops) lack tiocmget() and tiocmset()
    functions which are called by the certain HCI UART protocols (hci_ath,
    hci_bcm, hci_intel, hci_mrvl, hci_qca) via hci_uart_set_flow_control()
    or directly. This leads to an execution at NULL and can be triggered by
    an unprivileged user. Fix this by adding a helper function and a check
    for the missing tty operations in the protocols code.

    This fixes CVE-2019-10207. The Fixes: lines list commits where calls to
    tiocm[gs]et() or hci_uart_set_flow_control() were added to the HCI UART
    protocols.

    Link: https://syzkaller.appspot.com/bug?id=1b42faa2848963564a5b1b7f8c837ea7b55ffa50
    Reported-by: syzbot+79337b501d6aa974d0f6@syzkaller.appspotmail.com
    Cc: stable@vger.kernel.org # v2.6.36+
    Fixes: b3190df62861 ("Bluetooth: Support for Atheros AR300x serial chip")
    Fixes: 118612fb9165 ("Bluetooth: hci_bcm: Add suspend/resume PM functions")
    Fixes: ff2895592f0f ("Bluetooth: hci_intel: Add Intel baudrate configuration support")
    Fixes: 162f812f23ba ("Bluetooth: hci_uart: Add Marvell support")
    Fixes: fa9ad876b8e0 ("Bluetooth: hci_qca: Add support for Qualcomm Bluetooth chip wcn3990")
    Signed-off-by: Vladis Dronov
    Signed-off-by: Marcel Holtmann
    Reviewed-by: Yu-Chen, Cho
    Tested-by: Yu-Chen, Cho
    Signed-off-by: Linus Torvalds

    Vladis Dronov
     

07 Jul, 2019

2 commits

  • This adds the support of enabling MT7663U Bluetooth function running
    on the top of btusb driver.

    The information in /sys/kernel/debug/usb/devices about the Bluetooth
    device is listed as the below.

    T: Bus=04 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 5 Spd=5000 MxCh= 0
    D: Ver= 3.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs= 1
    P: Vendor=0e8d ProdID=7663 Rev= 1.00
    S: Manufacturer=MediaTek Inc.
    S: Product=Wireless_Device
    S: SerialNumber=000000000
    C:* #Ifs= 3 Cfg#= 1 Atr=a0 MxPwr=160mA
    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=125us
    E: Ad=82(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E: Ad=02(O) Atr=02(Bulk) MxPS=1024 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#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms
    E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms

    Signed-off-by: Sean Wang
    Signed-off-by: Marcel Holtmann

    Sean Wang
     
  • This adds the support of enabling MT7668U Bluetooth function running
    on the top of btusb driver.

    The information in /sys/kernel/debug/usb/devices about the Bluetooth
    device is listed as the below.

    T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=5000 MxCh= 0
    D: Ver= 3.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs= 1
    P: Vendor=0e8d ProdID=7668 Rev= 1.00
    S: Manufacturer=MediaTek Inc.
    S: Product=Wireless_Device
    S: SerialNumber=000000000
    C:* #Ifs= 3 Cfg#= 1 Atr=a0 MxPwr=160mA
    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=125us
    E: Ad=82(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E: Ad=02(O) Atr=02(Bulk) MxPS=1024 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#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms
    E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms

    Signed-off-by: Sean Wang
    Signed-off-by: Marcel Holtmann

    Sean Wang
     

06 Jul, 2019

2 commits

  • Without the QCA ROME setup routine this adapter fails to establish a SCO
    connection.

    T: Bus=01 Lev=01 Prnt=01 Port=08 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=13d3 ProdID=3491 Rev=00.01
    C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
    I: If#=0x0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    I: If#=0x1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb

    Signed-off-by: João Paulo Rechi Vita
    Signed-off-by: Marcel Holtmann

    João Paulo Rechi Vita
     
  • Without the QCA ROME setup routine this adapter fails to establish a SCO
    connection.

    T: Bus=01 Lev=01 Prnt=01 Port=04 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=13d3 ProdID=3501 Rev=00.01
    C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
    I: If#=0x0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    I: If#=0x1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb

    Signed-off-by: João Paulo Rechi Vita
    Signed-off-by: Marcel Holtmann

    João Paulo Rechi Vita