Re: [PATCH] Bluetooth: btusb: treat 0bda:0002 as a generic HCI device

[Andrew Bille]

Hi Paul,

thank you for the review.

The controller is the internal Bluetooth adapter of an old Quanta JW6H laptop.

Its relevant USB information is:

D:  Ver= 2.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P:  Vendor=0bda ProdID=0002 Rev=75.58
S:  Product=CSR BS8510
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb

No external firmware is required when the controller is handled through
the generic HCI path; no Bluetooth firmware is requested by the kernel
in this configuration.

I have addressed the possible regression for other 0bda:0002 devices by
limiting the exception to the observed bcdDevice revision 0x7558. The
driver also logs when the generic HCI path is selected.

I have sent v3 rebased onto the current bluetooth-next tree. I also
re-tested it on the affected hardware: the controller registers
successfully, and scanning, pairing and A2DP audio work correctly.

Thank you again for the review.

Kind regards,
Andrew



On Sat, Aug 15, 2026 at 2:38 PM Paul Menzel <pmenzel@xxxxxxxxxxxxx> wrote:
>
> Dear Andrew,
>
>
> Thank you for your patch.
>
> Am 15.08.26 um 05:33 schrieb Andrew Bille:
> > The 0bda:0002 Bluetooth controller reports itself as "CSR BS8510"
> > and exposes a standard Bluetooth USB interface.
>
> Where did you find this controller?
>
> > It currently matches the vendor-wide Realtek quirk and is therefore
> > initialized through btrtl. The controller does not respond to the
> > Realtek-specific register access and initialization fails with:
> >
> >      Bluetooth: hci0: RTL: RTL: Read reg16 failed (-110)
> >
> > No Bluetooth controller is then available to userspace.
> >
> > Add an exact match for 0bda:0002 before the generic Realtek entry so
> > that the device is handled as a generic USB HCI controller.
>
> Does the device need any firmware?
>
> > With this change the controller registers successfully. Scanning,
> > pairing and A2DP audio have been tested successfully.
>
> Please include relevant output of `/sys/kernel/debug/usb/devices`.
>
> > Fixes: a2698a9bf9b0 ("Bluetooth: btusb: Add Realtek 8723A/8723B/8761A/8821A support")
> > Cc: stable@xxxxxxxxxxxxxxx
> > Assisted-by: ChatGPT:GPT-5.6-Sol
> > Signed-off-by: Andrew Bille <andrewbille@xxxxxxxxx>
> > ---
> >   drivers/bluetooth/btusb.c | 3 +++
> >   1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> > index 184e95c1625e..fb9fdf90a3b9 100644
> > --- a/drivers/bluetooth/btusb.c
> > +++ b/drivers/bluetooth/btusb.c
> > @@ -615,6 +615,9 @@ static const struct usb_device_id quirks_table[] = {
> >       { USB_DEVICE(0x0489, 0xe130), .driver_info = BTUSB_REALTEK |
> >                                                    BTUSB_WIDEBAND_SPEECH },
> >
> > +     /* CSR BS8510 device using a Realtek USB vendor ID */
> > +     { USB_DEVICE(0x0bda, 0x0002) },
> > +
>
> Could some sort of message be logged, as we don’t know if there actual
> Realtek devices out there, that would regress? (More info in the commit
> message regarding regression potential would be useful.)
>
> >       /* Realtek Bluetooth devices */
> >       { USB_VENDOR_AND_INTERFACE_INFO(0x0bda, 0xe0, 0x01, 0x01),
> >         .driver_info = BTUSB_REALTEK },
>
> With my comments addressed:
>
> Reviewed-by: Paul Menzel <pmenzel@xxxxxxxxxxxxx>
>
>
> Kind regards,
>
> Paul