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

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

[bugzilla-daemon]

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: linux-bluetooth@vger.kernel.org
          Reporter: alejodelarco@gmail.com
        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.