[PATCH AUTOSEL 6.19-6.18] Bluetooth: hci_qca: Fix SSR (SubSystem Restart) fail when BT_EN is pulled up by hw

[PATCH AUTOSEL 6.19-6.18] Bluetooth: hci_qca: Fix SSR (SubSystem Restart) fail when BT_EN is pulled up by hw

[Sasha Levin]

From: Shuai Zhang <shuai.zhang@oss.qualcomm.com>

[ Upstream commit fce1a9244a0f85683be8530e623bc729f24c5067 ]

On QCS9075 and QCA8275 platforms, the BT_EN pin is always pulled up by hw
and cannot be controlled by the host. As a result, in case of a firmware
crash, the host cannot trigger a cold reset. Instead, the BT controller
performs a warm restart on its own, without reloading the firmware.

This leads to the controller remaining in IBS_WAKE state, while the host
expects it to be in sleep mode. The mismatch causes HCI reset commands
to time out. Additionally, the driver does not clear internal flags
QCA_SSR_TRIGGERED and QCA_IBS_DISABLED, which blocks the reset sequence.
If the SSR duration exceeds 2 seconds, the host may enter TX sleep mode
due to tx_idle_timeout, further preventing recovery. Also, memcoredump_flag
is not cleared, so only the first SSR generates a coredump.

Tell the driver that the BT controller has undergone a proper restart sequence:

- Clear QCA_SSR_TRIGGERED and QCA_IBS_DISABLED flags after SSR.
- Add a 50ms delay to allow the controller to complete its warm reset.
- Reset tx_idle_timer to prevent the host from entering TX sleep mode.
- Clear memcoredump_flag to allow multiple coredump captures.

Apply these steps only when HCI_QUIRK_NON_PERSISTENT_SETUP is not set,
which indicates that BT_EN is defined in DTS and cannot be toggled.

Refer to the comment in include/net/bluetooth/hci.h for details on
HCI_QUIRK_NON_PERSISTENT_SETUP.

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Shuai Zhang <shuai.zhang@oss.qualcomm.com>
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:

`HCI_QUIRK_NON_PERSISTENT_SETUP` has existed since 2018 (commit
`740011cfe9485`), so it's available in all stable trees. The only issue
is the accessor macro change (`test_bit` → `hci_test_quirk`).

### 8. FINAL ASSESSMENT

**Bug being fixed**: Real, user-impacting bug — Bluetooth SSR (SubSystem
Restart) fails on specific Qualcomm platforms (QCS9075, QCA8275) where
BT_EN is hardware-pulled high. After a firmware crash, Bluetooth becomes
permanently non-functional until reboot.

**Severity**: HIGH — Complete loss of Bluetooth functionality after
firmware crash with no recovery path.

**Fix quality**: Well-documented, well-reviewed (by Qualcomm and
Bluetooth maintainers), small and contained.

**Scope**: LOW risk — only affects platforms where
`HCI_QUIRK_NON_PERSISTENT_SETUP` is NOT set (specific hardware
configuration). Does not change behavior for any other platforms.

**Backportability concern**: The `hci_test_quirk()` macro only exists in
v6.16+. For older stable trees (6.1.y, 6.6.y, 6.12.y, 6.13.y), the
backport would need to use `!test_bit(HCI_QUIRK_NON_PERSISTENT_SETUP,
&hu->hdev->quirks)` instead. This is a trivial adaptation but means the
patch won't apply cleanly to older stable trees.

**Other concern**: The fix adds `msleep(50)` in the hw_error path, which
is acceptable for an error recovery path but not something you'd want in
a hot path.

**Verdict**: This fixes a real, important bug (complete Bluetooth
failure after firmware crash) on specific hardware. The fix is small,
well-contained, and guarded by a quirk check so it has minimal risk. It
meets stable kernel criteria. The backport will need minor adaptation
for older trees due to the quirk API change, but this is
straightforward. The fix has proper review from Qualcomm and the
Bluetooth subsystem maintainer.

**YES**

 drivers/bluetooth/hci_qca.c | 33 +++++++++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index 888176b0faa90..a3c217571c3c4 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -1653,6 +1653,39 @@ static void qca_hw_error(struct hci_dev *hdev, u8 code)
 		skb_queue_purge(&qca->rx_memdump_q);
 	}
 
+	/*
+	 * If the BT chip's bt_en pin is connected to a 3.3V power supply via
+	 * hardware and always stays high, driver cannot control the bt_en pin.
+	 * As a result, during SSR (SubSystem Restart), QCA_SSR_TRIGGERED and
+	 * QCA_IBS_DISABLED flags cannot be cleared, which leads to a reset
+	 * command timeout.
+	 * Add an msleep delay to ensure controller completes the SSR process.
+	 *
+	 * Host will not download the firmware after SSR, controller to remain
+	 * in the IBS_WAKE state, and the host needs to synchronize with it
+	 *
+	 * Since the bluetooth chip has been reset, clear the memdump state.
+	 */
+	if (!hci_test_quirk(hu->hdev, HCI_QUIRK_NON_PERSISTENT_SETUP)) {
+		/*
+		 * When the SSR (SubSystem Restart) duration exceeds 2 seconds,
+		 * it triggers host tx_idle_delay, which sets host TX state
+		 * to sleep. Reset tx_idle_timer after SSR to prevent
+		 * host enter TX IBS_Sleep mode.
+		 */
+		mod_timer(&qca->tx_idle_timer, jiffies +
+				  msecs_to_jiffies(qca->tx_idle_delay));
+
+		/* Controller reset completion time is 50ms */
+		msleep(50);
+
+		clear_bit(QCA_SSR_TRIGGERED, &qca->flags);
+		clear_bit(QCA_IBS_DISABLED, &qca->flags);
+
+		qca->tx_ibs_state = HCI_IBS_TX_AWAKE;
+		qca->memdump_state = QCA_MEMDUMP_IDLE;
+	}
+
 	clear_bit(QCA_HW_ERROR_EVENT, &qca->flags);
 }
 
-- 
2.51.0

[PATCH AUTOSEL 6.19-6.18] Bluetooth: btusb: Add USB ID 0489:e112 for Realtek 8851BE

[Sasha Levin]

From: Techie Ernie <techieernie@gmail.com>

[ Upstream commit e07094a51ad8faf98ea64320799ce550828e97cd ]

Add USB ID 0489:e112 for the Realtek 8851BE Bluetooth adapter.
Without this entry, the device is not handled correctly by btusb and Bluetooth fails to initialise.
Adding the ID enables proper Realtek initialization for Bluetooth to work on various motherboards using this Bluetooth adapter.

The device identifies as:
  Bus 001 Device XXX: ID 0489:e112 Foxconn / Hon Hai Bluetooth Radio

Tested on Realtek 8851BE. Bluetooth works after this change is made.

Signed-off-by: Techie Ernie <techieernie@gmail.com>
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: Bluetooth: btusb: Add USB ID 0489:e112 for Realtek 8851BE

### Commit Message Analysis
The commit adds a new USB device ID (0489:e112, Foxconn/Hon Hai) for the
Realtek 8851BE Bluetooth adapter to the btusb driver's quirks table. The
commit message clearly states that without this entry, "Bluetooth fails
to initialise" — the device simply doesn't work. The author tested it
and confirmed Bluetooth works after the change.

### Code Change Analysis
The change is a **two-line addition** to the `quirks_table[]` array in
`drivers/bluetooth/btusb.c`:

```c
{ USB_DEVICE(0x0489, 0xe112), .driver_info = BTUSB_REALTEK |
                                             BTUSB_WIDEBAND_SPEECH },
```

This is placed in the "Realtek 8851BE Bluetooth devices" section
alongside other existing 8851BE entries (0x0bda:0xb850, 0x13d3:0x3600,
0x13d3:0x3601). The flags used (`BTUSB_REALTEK | BTUSB_WIDEBAND_SPEECH`)
are consistent with nearly all other Realtek entries in this table, so
this is well-established pattern.

### Classification: New Device ID Addition
This falls squarely into the **"New Device IDs"** exception category for
stable backports. This is one of the most common and safest types of
stable patches:
- The btusb driver already exists in all stable trees
- The Realtek initialization path already exists
- Only a new USB vendor/product ID pair is being added to route a
  specific hardware variant through the correct initialization

### Scope and Risk Assessment
- **Lines changed**: 2 lines added (trivially small)
- **Files touched**: 1 file (`drivers/bluetooth/btusb.c`)
- **Risk**: Essentially zero. This only affects systems with USB device
  0489:e112 plugged in. It cannot regress any other hardware.
- **Complexity**: None — it's a table entry addition following an
  established pattern

### User Impact
- **Who is affected**: Users with motherboards that have the Foxconn/Hon
  Hai variant of the Realtek 8851BE Bluetooth adapter
- **Severity without the fix**: Complete Bluetooth failure — the device
  doesn't initialize at all
- **Benefit**: Bluetooth works properly on affected hardware

### Stability Indicators
- Tested by the author on the actual hardware
- Accepted by the Bluetooth subsystem maintainer (Luiz Augusto von
  Dentz)
- Follows the exact same pattern as dozens of other device ID entries in
  the same table

### Dependency Check
No dependencies. This is a self-contained table entry addition.

### Conclusion
This is a textbook stable backport candidate: a trivial device ID
addition to an existing driver that enables hardware that otherwise
doesn't work at all. It's obviously correct, fixes a real problem
(Bluetooth completely broken), is tiny in scope, and carries virtually
no regression risk.

**YES**

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

diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 646de80c7e7be..de9e484efef71 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -521,6 +521,8 @@ static const struct usb_device_id quirks_table[] = {
 	{ USB_DEVICE(0x0bda, 0xb850), .driver_info = BTUSB_REALTEK },
 	{ USB_DEVICE(0x13d3, 0x3600), .driver_info = BTUSB_REALTEK },
 	{ USB_DEVICE(0x13d3, 0x3601), .driver_info = BTUSB_REALTEK },
+	{ USB_DEVICE(0x0489, 0xe112), .driver_info = BTUSB_REALTEK |
+						     BTUSB_WIDEBAND_SPEECH },
 
 	/* Realtek 8851BU Bluetooth devices */
 	{ USB_DEVICE(0x3625, 0x010b), .driver_info = BTUSB_REALTEK |
-- 
2.51.0

[PATCH AUTOSEL 6.19-6.12] Bluetooth: btusb: Add support for MediaTek7920 0489:e158

[Sasha Levin]

From: Bluecross <elantsew.andrew@gmail.com>

[ Upstream commit 2630bcc8343a9d2a38dc1793068e6754b3156811 ]

Add support for MediaTek7920 0489:e158

/sys/kernel/debug/usb/devices reports for that device:

T:  Bus=03 Lev=01 Prnt=01 Port=02 Cnt=03 Dev#=  5 Spd=480  MxCh= 0
D:  Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=0489 ProdID=e158 Rev= 1.00
S:  Manufacturer=MediaTek Inc.
S:  Product=Wireless_Device
S:  SerialNumber=000000000
C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA
A:  FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=125us
E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
I:  If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  63 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  63 Ivl=1ms
I:* If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E:  Ad=8a(I) Atr=03(Int.) MxPS=  64 Ivl=125us
E:  Ad=0a(O) Atr=03(Int.) MxPS=  64 Ivl=125us
I:  If#= 2 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E:  Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us
E:  Ad=0a(O) Atr=03(Int.) MxPS= 512 Ivl=125us

Signed-off-by: Andrew Elatsev <elantsew.andrew@gmail.com>
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
This commit adds a new USB device ID (0489:e158) for a MediaTek MT7920
Bluetooth adapter to the `btusb` driver. The commit message includes the
full USB device descriptor dump from `/sys/kernel/debug/usb/devices`,
confirming this is a real hardware device (manufactured by MediaTek
Inc., identified as "Wireless_Device").

### Code Change Analysis
The change is a **two-line addition** to the `quirks_table[]` array in
`drivers/bluetooth/btusb.c`:

```c
{ USB_DEVICE(0x0489, 0xe158), .driver_info = BTUSB_MEDIATEK |
                                             BTUSB_WIDEBAND_SPEECH },
```

This is added in the "Additional MediaTek MT7920 Bluetooth devices"
section, alongside other MT7920 device IDs that already exist
(0x0489:0xe134, 0x0489:0xe135, 0x13d3:0x3620, 0x13d3:0x3621,
0x13d3:0x3622). The new entry uses the exact same `driver_info` flags as
all other MT7920 entries.

### Classification
This is a **new device ID addition** to an existing, well-established
driver. This falls squarely into the "NEW DEVICE IDs" exception category
that is explicitly allowed and encouraged for stable backports.

### Scope and Risk Assessment
- **Lines changed**: 2 lines added (one table entry)
- **Files touched**: 1 file (`drivers/bluetooth/btusb.c`)
- **Risk**: Essentially zero. This only adds a USB ID match entry to a
  device table. It cannot affect any other device or code path. The
  driver (btusb with MediaTek support) already exists and works for the
  other MT7920 variants.
- **Complexity**: Trivial — it's a data table entry, not logic.

### User Impact
Without this entry, users with the MediaTek MT7920 variant (vendor
0x0489, product 0xe158) have **no Bluetooth functionality at all** — the
kernel simply won't bind the btusb driver to this device. With this
entry, Bluetooth works out of the box. This is a direct hardware
enablement fix.

### Stability Indicators
- The same pattern (USB_DEVICE + BTUSB_MEDIATEK | BTUSB_WIDEBAND_SPEECH)
  is used by dozens of other MediaTek entries in this table, all well-
  tested.
- The commit was accepted by the Bluetooth subsystem maintainer (Luiz
  Augusto von Dentz).

### Dependencies
None. This is a self-contained, single-entry table addition with no
dependencies on other commits.

### Conclusion
This is a textbook example of a stable-worthy device ID addition:
- Trivial two-line change to an existing device table
- Zero risk of regression to any other device or code path
- Enables hardware that otherwise doesn't work at all
- Uses the exact same flags as all other MT7920 entries
- The btusb driver and MediaTek support exist in all active stable trees

**YES**

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

diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index ded09e94d296d..646de80c7e7be 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -637,6 +637,8 @@ static const struct usb_device_id quirks_table[] = {
 						     BTUSB_WIDEBAND_SPEECH },
 	{ USB_DEVICE(0x13d3, 0x3622), .driver_info = BTUSB_MEDIATEK |
 						     BTUSB_WIDEBAND_SPEECH },
+	{ USB_DEVICE(0x0489, 0xe158), .driver_info = BTUSB_MEDIATEK |
+						     BTUSB_WIDEBAND_SPEECH },
 
 	/* Additional MediaTek MT7921 Bluetooth devices */
 	{ USB_DEVICE(0x0489, 0xe0c8), .driver_info = BTUSB_MEDIATEK |
-- 
2.51.0

[PATCH AUTOSEL 6.19-6.1] Bluetooth: btusb: Add new VID/PID for RTL8852CE

[Sasha Levin]

From: Shell Chen <w27@sorz.org>

[ Upstream commit d9f7c39c6b7548bd70519b241b6c2d1bcc658d4b ]

Add VID:PID 13d3:3612 to the quirks_table.

This ID pair is found in the Realtek RTL8852CE PCIe module
in an ASUS TUF A14 2025 (FA401KM) laptop.

Tested on aforementioned laptop.

The device info from /sys/kernel/debug/usb/devices is listed as below.

T:  Bus=03 Lev=01 Prnt=01 Port=04 Cnt=01 Dev#=  2 Spd=12   MxCh= 0
D:  Ver= 1.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=13d3 ProdID=3612 Rev= 0.00
S:  Manufacturer=Realtek
S:  Product=Bluetooth Radio
S:  SerialNumber=00e04c000001
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
I:  If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  63 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  63 Ivl=1ms

Signed-off-by: Shell Chen <w27@sorz.org>
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 Summary

This commit adds a single new USB VID/PID pair (0x13d3:0x3612) to the
`quirks_table[]` in `drivers/bluetooth/btusb.c` for the Realtek
RTL8852CE Bluetooth controller. This device is found in the ASUS TUF A14
2025 (FA401KM) laptop.

### Classification: New Device ID Addition

This falls squarely into the **"NEW DEVICE IDs"** exception category,
which is explicitly listed as appropriate for stable backporting:

> Adding PCI IDs, USB IDs, ACPI IDs, etc. to existing drivers. These are
trivial one-line additions that enable hardware support. Rule: The
driver must already exist in stable; only the ID is new.

### Code Change Analysis

The change is a **2-line addition** (one logical entry) inserting a new
`USB_DEVICE()` entry into the existing RTL8852CE section of the quirks
table:

```c
{ USB_DEVICE(0x13d3, 0x3612), .driver_info = BTUSB_REALTEK |
                                             BTUSB_WIDEBAND_SPEECH },
```

This is identical in structure to all neighboring entries for the same
chip family (RTL8852CE). The vendor 0x13d3 is Azurewave (a common
Realtek module OEM), and there are already multiple 0x13d3 entries for
this exact chip.

### Risk Assessment

- **Risk: Extremely Low.** This is a pure data addition to a device ID
  table. It cannot affect any other device or code path. The only effect
  is that a USB device with this specific VID/PID will now be recognized
  and handled by the btusb driver with the correct Realtek quirks.
- **Without this patch:** Bluetooth on this specific laptop model simply
  does not work.
- **Dependencies:** None. The RTL8852CE support infrastructure already
  exists in all recent stable trees.
- **Tested:** The commit message explicitly states "Tested on
  aforementioned laptop" and includes detailed USB device info
  confirming it works.

### User Impact

This enables Bluetooth functionality on the ASUS TUF A14 2025 laptop.
Without this entry, users of this laptop running stable kernels have no
Bluetooth. This is a real-world hardware enablement fix.

### Stable Criteria

1. **Obviously correct and tested:** Yes - trivial table entry addition,
   explicitly tested on the device.
2. **Fixes a real bug:** Yes - missing device ID means hardware doesn't
   work.
3. **Important issue:** Yes - complete loss of Bluetooth functionality
   on a shipping laptop.
4. **Small and contained:** Yes - 2 lines added to a single file's
   device ID table.
5. **No new features/APIs:** Correct - just enables existing driver for
   new hardware variant.
6. **Applies cleanly:** The change is a simple table entry insertion
   that should apply cleanly to any stable tree containing the RTL8852CE
   section.

**YES**

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

diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index de9e484efef71..972139729e8fd 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -559,6 +559,8 @@ static const struct usb_device_id quirks_table[] = {
 						     BTUSB_WIDEBAND_SPEECH },
 	{ USB_DEVICE(0x13d3, 0x3592), .driver_info = BTUSB_REALTEK |
 						     BTUSB_WIDEBAND_SPEECH },
+	{ USB_DEVICE(0x13d3, 0x3612), .driver_info = BTUSB_REALTEK |
+						     BTUSB_WIDEBAND_SPEECH },
 	{ USB_DEVICE(0x0489, 0xe122), .driver_info = BTUSB_REALTEK |
 						     BTUSB_WIDEBAND_SPEECH },
 
-- 
2.51.0

[PATCH AUTOSEL 6.19-6.6] Bluetooth: hci_conn: Set link_policy on incoming ACL connections

[Sasha Levin]

From: Stefan Sørensen <ssorensen@roku.com>

[ Upstream commit 4bb091013ab0f2edfed3f58bebe658a798cbcc4d ]

The connection link policy is only set when establishing an outgoing
ACL connection causing connection idle modes not to be available on
incoming connections. Move the setting of the link policy to the
creation of the connection so all ACL connection will use the link
policy set on the HCI device.

Signed-off-by: Stefan Sørensen <ssorensen@roku.com>
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 of Bluetooth: hci_conn: Set link_policy on incoming ACL
connections

### 1. COMMIT MESSAGE ANALYSIS

The commit message clearly describes a functional bug: the connection
link policy is **only** set when establishing an **outgoing** ACL
connection, which means **incoming** ACL connections don't get the link
policy configured on the HCI device. This causes "connection idle modes
not to be available on incoming connections."

The fix moves the `link_policy` assignment from the outgoing-connection-
specific path (`hci_acl_create_conn_sync`) to the generic connection
creation path (`__hci_conn_add`), so all ACL connections (both incoming
and outgoing) inherit the device's link policy.

### 2. CODE CHANGE ANALYSIS

The change is extremely small and surgical:

**In `net/bluetooth/hci_conn.c` (`__hci_conn_add`):**
- Adds one line: `conn->link_policy = hdev->link_policy;` in the
  `ACL_LINK` case of the switch statement during connection
  initialization.

**In `net/bluetooth/hci_sync.c` (`hci_acl_create_conn_sync`):**
- Removes the line `conn->link_policy = hdev->link_policy;` from the
  outgoing connection creation path (since it's now handled in the
  common path).

This is a pure **move** of a single assignment from a specific path to a
common path. The net effect:
- Outgoing connections: behavior is unchanged (link_policy was set
  before, still set now, just earlier in the flow)
- Incoming connections: link_policy is now properly set (was previously
  missing)

### 3. CLASSIFICATION

This is a **bug fix**. Incoming Bluetooth ACL connections were not
getting the correct link policy, which means features like sniff mode
(power saving) and role switching wouldn't work properly on incoming
connections. This is a real functional issue affecting Bluetooth power
management and connection behavior.

### 4. SCOPE AND RISK ASSESSMENT

- **Lines changed:** 2 (1 added, 1 removed - it's a move)
- **Files changed:** 2
- **Complexity:** Extremely low - moving an assignment to a more
  appropriate location
- **Risk of regression:** Minimal. The assignment already existed for
  outgoing connections; this just ensures incoming connections get the
  same treatment. The value being assigned (`hdev->link_policy`) is the
  same in both cases.

### 5. USER IMPACT

Bluetooth is widely used on laptops, desktops, and embedded systems. The
link policy controls important features like:
- **Sniff mode**: Power-saving mode that reduces radio duty cycle
- **Role switching**: Ability to switch between master and slave roles
- **Hold mode**: Another power management feature

Without the correct link policy on incoming connections, Bluetooth
devices connecting to the affected system would not benefit from power-
saving modes, potentially leading to increased battery drain and missing
expected Bluetooth behavior.

### 6. STABILITY INDICATORS

- The author (Stefan Sørensen) submitted the fix and it was signed off
  by Luiz Augusto von Dentz, the Bluetooth subsystem maintainer. This
  indicates it was reviewed and approved by the person most
  knowledgeable about the code.
- The change is trivially correct - it's moving an existing assignment
  to a more general location.

### 7. DEPENDENCY CHECK

This commit is completely self-contained. It doesn't depend on any other
changes - it simply moves an existing line of code. The `link_policy`
field, `hdev->link_policy`, and `__hci_conn_add` function have been in
the kernel for a long time, so this should apply cleanly to stable
trees.

### 8. STABLE KERNEL CRITERIA

- **Obviously correct:** Yes - it's a one-line move that ensures all ACL
  connections get the device's link policy
- **Fixes a real bug:** Yes - incoming connections missing link policy
  settings
- **Small and contained:** Yes - 2 lines across 2 files
- **No new features:** Correct - this enables existing functionality
  that was incorrectly not applied
- **Risk vs benefit:** Very low risk (trivially correct code move) vs
  meaningful benefit (proper Bluetooth power management on incoming
  connections)

**YES**

 net/bluetooth/hci_conn.c | 1 +
 net/bluetooth/hci_sync.c | 2 --
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
index c3f7828bf9d54..b5e345fa6c344 100644
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -1002,6 +1002,7 @@ static struct hci_conn *__hci_conn_add(struct hci_dev *hdev, int type,
 	switch (type) {
 	case ACL_LINK:
 		conn->pkt_type = hdev->pkt_type & ACL_PTYPE_MASK;
+		conn->link_policy = hdev->link_policy;
 		conn->mtu = hdev->acl_mtu;
 		break;
 	case LE_LINK:
diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c
index cbc3a75d73262..334eb4376a266 100644
--- a/net/bluetooth/hci_sync.c
+++ b/net/bluetooth/hci_sync.c
@@ -6897,8 +6897,6 @@ static int hci_acl_create_conn_sync(struct hci_dev *hdev, void *data)
 
 	conn->attempt++;
 
-	conn->link_policy = hdev->link_policy;
-
 	memset(&cp, 0, sizeof(cp));
 	bacpy(&cp.bdaddr, &conn->dst);
 	cp.pscan_rep_mode = 0x02;
-- 
2.51.0

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

[Sasha Levin]

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

[PATCH AUTOSEL 6.19-5.10] Bluetooth: hci_conn: use mod_delayed_work for active mode timeout

[Sasha Levin]

From: Stefan Sørensen <ssorensen@roku.com>

[ Upstream commit 49d0901e260739de2fcc90c0c29f9e31e39a2d9b ]

hci_conn_enter_active_mode() uses queue_delayed_work() with the
intention that the work will run after the given timeout. However,
queue_delayed_work() does nothing if the work is already queued, so
depending on the link policy we may end up putting the connection
into idle mode every hdev->idle_timeout ms.

Use mod_delayed_work() instead so the work is queued if not already
queued, and the timeout is updated otherwise.

Signed-off-by: Stefan Sørensen <ssorensen@roku.com>
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 of Bluetooth: hci_conn: use mod_delayed_work for active mode
timeout

### 1. COMMIT MESSAGE ANALYSIS

The commit message clearly describes a **behavioral bug**:

- `queue_delayed_work()` does nothing if the work is already queued
- This means the timeout is never refreshed/reset when
  `hci_conn_enter_active_mode()` is called while work is already pending
- The consequence: the connection may enter idle mode prematurely (every
  `hdev->idle_timeout` ms from the *first* queuing, not from the *last*
  activity)
- `mod_delayed_work()` fixes this by resetting the timer if already
  queued, or queuing if not

The commit message is well-written and explains the mechanism clearly.
The author (Stefan Sørensen) understood the semantic difference between
the two APIs.

### 2. CODE CHANGE ANALYSIS

The change is **minimal** - a two-line change replacing one function
call with another:

```c
- queue_delayed_work(hdev->workqueue, &conn->idle_work,
- msecs_to_jiffies(hdev->idle_timeout));
+               mod_delayed_work(hdev->workqueue, &conn->idle_work,
+                                msecs_to_jiffies(hdev->idle_timeout));
```

- `queue_delayed_work()` → queues work only if not already queued;
  returns false and does nothing if already queued
- `mod_delayed_work()` → if work is pending, cancels and re-queues with
  the new delay; if not pending, queues it fresh

This is exactly the right fix. The function
`hci_conn_enter_active_mode()` is called whenever there's activity on
the connection, and the idle timeout should be reset from the last
activity, not remain fixed from the first.

### 3. BUG CLASSIFICATION

This is a **real behavioral bug** affecting Bluetooth connection power
management:

- **Without the fix**: A Bluetooth connection may be put into sniff/idle
  mode too early if `hci_conn_enter_active_mode()` is called multiple
  times. The first call sets the timer, and subsequent calls (which
  indicate continued activity) fail to extend it. The connection gets
  idled based on the *first* activity, not the *last*.
- **User impact**: Bluetooth connections may experience unexpected power
  state transitions, potentially causing latency issues, dropped
  connections, or degraded performance for active Bluetooth devices
  (audio, input devices, etc.).

### 4. SCOPE AND RISK ASSESSMENT

- **Lines changed**: 2 (just the function name and indentation)
- **Files touched**: 1 (`net/bluetooth/hci_conn.c`)
- **Risk**: Very low. `mod_delayed_work()` is a well-established kernel
  API that has been available for many years. The semantic change is
  exactly what the code intended.
- **Could it break something?** Extremely unlikely. The only behavioral
  change is that the idle timeout now properly resets on each call,
  which is the correct behavior. If anything, the old behavior was
  silently broken.

### 5. USER IMPACT

Bluetooth is widely used:
- Audio devices (headphones, speakers)
- Input devices (keyboards, mice)
- Phone tethering
- IoT devices

Premature idle mode transitions could affect any of these use cases.
While this may not cause crashes, it affects the reliability of
Bluetooth connections, which is important for stable kernel users.

### 6. STABLE TREE CRITERIA CHECK

- **Obviously correct?** Yes - the commit message explains the API
  difference clearly, and `mod_delayed_work()` is the standard pattern
  for "reset this timer"
- **Fixes a real bug?** Yes - incorrect idle timeout behavior for
  Bluetooth connections
- **Small and contained?** Yes - 2-line change in a single file
- **No new features?** Correct - this is purely a bug fix
- **Tested?** Accepted by Bluetooth maintainer (Luiz Augusto von Dentz),
  merged to mainline

### 7. DEPENDENCY CHECK

This change has no dependencies. `mod_delayed_work()` has been in the
kernel since 3.x era. The surrounding code in
`hci_conn_enter_active_mode()` is stable and has existed for a long
time.

### Conclusion

This is a clean, minimal, obvious bug fix. It corrects a long-standing
behavioral issue in Bluetooth power management where the idle timeout
was not being properly reset. The fix is exactly two lines, uses a well-
established API, has zero risk of regression, and improves Bluetooth
connection reliability for all users. It perfectly meets stable kernel
criteria.

**YES**

 net/bluetooth/hci_conn.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
index b5e345fa6c344..1214216c7818e 100644
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -2615,8 +2615,8 @@ void hci_conn_enter_active_mode(struct hci_conn *conn, __u8 force_active)
 
 timer:
 	if (hdev->idle_timeout > 0)
-		queue_delayed_work(hdev->workqueue, &conn->idle_work,
-				   msecs_to_jiffies(hdev->idle_timeout));
+		mod_delayed_work(hdev->workqueue, &conn->idle_work,
+				 msecs_to_jiffies(hdev->idle_timeout));
 }
 
 /* Drop all connection on the device */
-- 
2.51.0