[PATCH AUTOSEL 6.19-5.10] Bluetooth: btusb: Add device ID for Realtek RTL8761BU

[Sasha Levin <sashal@kernel.org>]

From: Jacopo Scannella <code@charlie.cat>

[ Upstream commit cc6383d4f0cf6127c0552f94cae517a06ccc6b17 ]

Add USB device ID 0x2c0a:0x8761 to the btusb driver fo the Realtek
RTL8761BU Bluetooth adapter.

Reference:
https://www.startech.com/en-us/networking-io/av53c1-usb-bluetooth

Signed-off-by: Jacopo Scannella <code@charlie.cat>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis

### Commit Message Analysis
The commit adds a USB device ID (0x2c0a:0x8761) for the Realtek
RTL8761BU Bluetooth adapter to the btusb driver. It references a
specific commercial product (StarTech USB Bluetooth adapter), confirming
this is real hardware that users need supported.

### Code Change Analysis
The change is a single line addition:
```c
{ USB_DEVICE(0x2c0a, 0x8761), .driver_info = BTUSB_REALTEK },
```

This adds a new USB vendor/product ID entry to the `quirks_table[]` in
`drivers/bluetooth/btusb.c`. The entry uses the `BTUSB_REALTEK`
driver_info flag, which routes the device through the existing Realtek
firmware loading and initialization path that is already well-tested for
many other Realtek Bluetooth adapters.

### Classification
This falls squarely into the **New Device IDs** exception category. The
stable kernel rules explicitly allow adding device IDs to existing
drivers:
- The btusb driver already exists in all stable trees
- The Realtek support code (`BTUSB_REALTEK`) is already present
- Only the ID mapping is new — no new code paths are exercised

### Scope and Risk Assessment
- **Lines changed:** 1 (single line addition)
- **Files touched:** 1 (`drivers/bluetooth/btusb.c`)
- **Risk:** Essentially zero. This only affects devices with USB ID
  0x2c0a:0x8761. It cannot affect any other hardware or code path. If
  the ID is wrong, the worst case is that this specific adapter doesn't
  work — no regression for anyone else.

### User Impact
Without this device ID, users with the Realtek RTL8761BU (StarTech
AV53C1) Bluetooth adapter simply cannot use it at all with Linux. The
device won't be recognized by the btusb driver. This is a complete
hardware enablement issue — the fix makes the difference between "device
works" and "device doesn't work."

### Dependency Check
No dependencies. The `BTUSB_REALTEK` flag and all associated Realtek
support code have been in the kernel for years and are present in all
actively maintained stable trees.

### Minor Note on Placement
The new entry is placed under the "Additional Realtek 8723BU Bluetooth
devices" comment section, while the subject says "RTL8761BU." This is a
minor organizational issue (it would fit better near the "Additional
Realtek 8761BUV" section), but it has zero functional impact — the
quirks_table is searched linearly and the position doesn't matter.

### Conclusion
This is a textbook example of a device ID addition that should be
backported. It's a single-line, zero-risk change that enables real
hardware for real users, using an existing well-tested driver path.

**YES**

 drivers/bluetooth/btusb.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 972139729e8fd..cbb6ab2fd5e45 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -779,6 +779,7 @@ static const struct usb_device_id quirks_table[] = {
 
 	/* Additional Realtek 8723BU Bluetooth devices */
 	{ USB_DEVICE(0x7392, 0xa611), .driver_info = BTUSB_REALTEK },
+	{ USB_DEVICE(0x2c0a, 0x8761), .driver_info = BTUSB_REALTEK },
 
 	/* Additional Realtek 8723DE Bluetooth devices */
 	{ USB_DEVICE(0x0bda, 0xb009), .driver_info = BTUSB_REALTEK },
-- 
2.51.0