New: btusb misidentifies Realtek 13d3:3556 as Broadcom (IMC Networks wildcard match)

https://bugzilla.kernel.org/show_bug.cgi?id=221876

Bug ID: 221876
Summary: btusb misidentifies Realtek 13d3:3556 as Broadcom (IMC
Networks wildcard match)
Product: Drivers
Version: 2.5
Hardware: AMD
OS: Linux
Status: NEW
Severity: high
Priority: P3
Component: Bluetooth
Assignee: [email protected]
Reporter: [email protected]
Regression: No

# Bug Report: btusb misidentifies Realtek 13d3:3556 as Broadcom (IMC Networks wildcard match)

## Summary
The btusb driver's generic IMC Networks match rule (USB_VENDOR_AND_INTERFACE_INFO(0x13d3, 0xff, 0x01, 0x01) → BTUSB_BCM_PATCHRAM) catches a Realtek-based IMC Networks Bluetooth adapter (13d3:3556) that has no specific entry in the Realtek ID table. As a result, no vendor firmware is loaded and no Realtek-specific quirks are applied. The adapter operates in a degraded/generic mode, causing consistent BR/EDR pairing and connection failures (br-connection-key-missing) even though the link key is present in BlueZ's storage and correctly reloaded into the kernel.

## System information
- Kernel: 7.1.5-ogc5.1.fc44.x86_64
- Distro: Bazzite (Kinoite-based), VERSION="44.20260801.0 (Kinoite)"
- BlueZ: bluetoothctl 5.87 / bluetoothd 5.87
- Bluetooth adapter: lsusb reports 13d3:3556 IMC Networks Bluetooth Radio, USB descriptor Manufacturer string: "Realtek"
- Same symptom previously reproduced on Nobara and Linux Mint (different kernel versions), so this is not distro-specific.

## Expected behavior
The Realtek chip should be recognized by btusb/btrtl, load the correct RTL firmware/config, and complete BR/EDR pairing and reconnection normally.

## Actual behavior
- Pairing (bluetoothctl pair) with a Sonos Ace headset completes and reports Paired: yes / Bonded: yes.
- The resulting link key is correctly written to /var/lib/bluetooth/<adapter>/<device>/info under [LinkKey].
- Any subsequent connect attempt fails immediately with:

  ```
  Failed to connect: org.bluez.Error.Failed br-connection-key-missing
  ```

- This happens consistently even after:
- Restarting bluetooth.service
- Power-cycling the adapter (power off / power on) — this changes the
error to le-connection-abort-by-local, suggesting a bearer-selection issue as well
- Forcing bearer bredr (with bluetoothd --experimental)
- Enabling link-security explicitly via btmgmt
- A pairing done purely over BR/EDR (scan bredr, avoiding any LE bonding)
- No combination of BlueZ-level configuration resolves the issue, pointing to a driver/firmware-level problem rather than a BlueZ configuration problem.

## Evidence pointing to root cause
sudo journalctl -k -b shows no line of the form RTL: examining hci_ver=... (which btrtl normally logs when it takes over a Realtek device), and no Broadcom patchram firmware load messages either. Only the generic registration is seen:

```
usbcore: registered new interface driver btusb
Bluetooth: hci0: Ignoring error of Inquiry Cancel command
```

lsmod confirms btrtl is loaded as a module but appears unused for this device (no firmware-load log entries reference it).

The current upstream btusb.c ID table contains a wildcard entry:

```c
/* IMC Networks - Broadcom based */
{ USB_VENDOR_AND_INTERFACE_INFO(0x13d3, 0xff, 0x01, 0x01),
  .driver_info = BTUSB_BCM_PATCHRAM },
```

This matches *any* IMC Networks (13d3) device with USB interface class/subclass/protocol ff/01/01 that isn't already claimed by a more specific USB_DEVICE() entry earlier in the table. Since 13d3:3556 has no specific Realtek entry, it falls through to this Broadcom-oriented rule, even though the chip identifies itself as Realtek in its USB manufacturer string. This causes btusb to initialize it via the Broadcom patchram path instead of btrtl, so no Realtek firmware/config is ever loaded.

## Steps to reproduce
1. Attach a device with USB ID 13d3:3556 (IMC Networks Bluetooth Radio, Realtek-based).
2. lsmod | grep -i bt — confirm btrtl is loaded but journalctl -k -b | grep -i RTL shows no RTL: examining... line for this device.
3. Pair a BR/EDR audio device (tested with Sonos Ace headphones).
4. Disconnect and attempt to reconnect — observe br-connection-key-missing despite a valid stored link key.

## Suggested fix
Add an explicit USB_DEVICE(0x13d3, 0x3556) entry to the Realtek ID table in btusb.c (mapped to the appropriate BTUSB_REALTEK driver_info / RTL config), so it's matched before the generic IMC Networks Broadcom wildcard rule.

## Additional notes
Happy to provide btmon captures, btmgmt info output, and full journalctl -k -b logs on request.

You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.