[REPORT] btusb: QCA9377 13d3:3503 on ROM firmware: HCI hang during mSBC SCO

[Iaroslav Voitovych <yaroslav.voytovych@gmail.com>]

Hi,

A report with two questions, mainly for Qualcomm; not a patch. For
13d3:3503 the kernel side is already fixed: dc16388d45ec ("Bluetooth:
btusb: Add IMC Networks QCA9377 to quirks table") is in v7.3 and in
stable releases, so I am not asking for another fix for this ID. The
entry was sent for BLE-scan errors; in my tests it also avoided the
controller-wide hang below.

Summary
-------
Without a btusb entry this QCA9377 runs its ROM firmware (ROM 0x302,
build 0x111). In twelve recorded failures, the first HCI command
issued after a transparent (mSBC) SCO link came up got no reply, and
later commands timed out too. With the QCA setup path, which loads
qca/rampatch_usb_00000302.bin and qca/nvm_usb_00000302.bin, 74 SCO
links logged no command timeout. What goes wrong inside the
controller I do not know.

Questions
---------
1. Is this known for ROME ROM 0x302 build 0x111? Is there an erratum,
   an affected ROM range, or a rampatch/NVM revision that addresses
   it?

2. Is there a list of ROME-based USB IDs, or a reliable way to
   identify such adapters, that could be compared with btusb's table?
   This year three were added one at a time, each after a user ran
   into the 0x2005 BLE-scan errors: 13d3:3503 (dc16388d45ec),
   0b05:1868 (d54601f21faf) and 0b05:1825 (cfa67a1dbfd9). An
   earlier, unmerged submission for 0b05:1825 (2026-07-21) also
   reported SCO audio broken on the ROM firmware ("corrupted SCO
   packet", no HFP microphone).

On the ROM firmware
-------------------
The device has isochronous alternate settings 1-5 (wMaxPacketSize
9/17/25/33/49) and no alt 6. On the transparent links recorded here
btusb selected alt 1 (read live from sysfs), and the captures show
each 27-byte SCO buffer sent as three 9-byte USB packets. Setup
Synchronous Connection (0x0428) is answered and the link streams.
One of the twelve failures (kernel log, Bluetooth dynamic debug on;
"evt 5" is HCI_NOTIFY_ENABLE_SCO_TRANSP in btusb_notify()):

  02:09:36.646940 hci0 opcode 0x0428 plen 17
  02:09:36.718906 hci0 evt 5
  02:09:44.049893 hci0: handle 0x06 reason 0x13
  02:09:44.049956 hci0: Opcode 0x0406
  02:09:46.067797 Bluetooth: hci0: command 0x0406 tx timeout

Here the stream ran about 7.3 s before the Disconnect. In all twelve
failures the first command after link-up timed out about 2 s after
it was issued; where the delay from link-up is recorded, it was
34 ms to 9.65 s. The command was 0x0406 Disconnect in six, 0x0c1a
Write Scan Enable in one, the bare "command tx timeout" in five.
Whether the command causes the hang or only finds it, I cannot tell
from the host side.

No later command was answered. In one failure I probed the USB side:
two GET_DESCRIPTOR transfers timed out with -110 while the device
stayed enumerated. Removing power recovered the controller; a warm
reboot did not always.

The twelve were on Ubuntu 7.0.0-29, -30, -31 and -34 kernels with
stock btusb and three headset models from three vendors. I have no
count of ROM-firmware links that did not fail, so no failure rate.

With the QCA setup path
-----------------------
Before setup the controller reports ROM 0x302, build 0x111 and a
status with neither QCA_PATCH_UPDATED nor QCA_SYSCFG_UPDATED set, so
btusb_setup_qca() loads both files; both loads return 0, and a later
version read reports patch build 0x3e8. On the same laptop, across
the same three headset models, 74 SCO links then logged no command
timeout: 50 mSBC, still on alt 1 with the legacy 0x0428
(btusb_setup_qca() sets HCI_QUIRK_BROKEN_ENHANCED_SETUP_SYNC_CONN),
and 24 CVSD. Of these,

  58 ran on a diagnostic build giving this ID BTUSB_QCA_ROME without
     BTUSB_WIDEBAND_SPEECH and without the reset callback, so no
     reset could have hidden a timeout;
  16 ran with the exact dc16388d45ec entry.

This does not separate the rampatch from the NVM. Nor does it
separate the firmware from BTUSB_QCA_ROME's other host-side effects,
which the diagnostic build kept: the shutdown handler, set_bdaddr,
the simultaneous-discovery quirk and the reset-resume check.

For anyone searching the archive with a similar failure on a QCA
ROME USB controller: check whether its USB ID selects btusb's QCA
setup path and whether the rampatch and NVM load.

Kernel log extracts, with the commands that produced them:
https://github.com/ivoitovych/qca9377-bt-hang/blob/4b56813d311d/contributions/CO-25-qualcomm-rom-report/EVIDENCE.md

Thanks,
Iaroslav Voitovych