[PATCH AUTOSEL 6.18] Bluetooth: hci_sync: annotate data-races around hdev->req_status

[PATCH AUTOSEL 6.18] Bluetooth: hci_sync: annotate data-races around hdev->req_status

[Sasha Levin]

From: Cen Zhang <zzzccc427@gmail.com>

[ Upstream commit b6807cfc195ef99e1ac37b2e1e60df40295daa8c ]

__hci_cmd_sync_sk() sets hdev->req_status under hdev->req_lock:

    hdev->req_status = HCI_REQ_PEND;

However, several other functions read or write hdev->req_status without
holding any lock:

  - hci_send_cmd_sync() reads req_status in hci_cmd_work (workqueue)
  - hci_cmd_sync_complete() reads/writes from HCI event completion
  - hci_cmd_sync_cancel() / hci_cmd_sync_cancel_sync() read/write
  - hci_abort_conn() reads in connection abort path

Since __hci_cmd_sync_sk() runs on hdev->req_workqueue while
hci_send_cmd_sync() runs on hdev->workqueue, these are different
workqueues that can execute concurrently on different CPUs. The plain
C accesses constitute a data race.

Add READ_ONCE()/WRITE_ONCE() annotations on all concurrent accesses
to hdev->req_status to prevent potential compiler optimizations that
could affect correctness (e.g., load fusing in the wait_event
condition or store reordering).

Signed-off-by: Cen Zhang <zzzccc427@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:

Error: Failed to generate final synthesis

 net/bluetooth/hci_conn.c |  2 +-
 net/bluetooth/hci_core.c |  2 +-
 net/bluetooth/hci_sync.c | 20 ++++++++++----------
 3 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
index 24b71ec8897ff..71a24be2a6d67 100644
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -2967,7 +2967,7 @@ int hci_abort_conn(struct hci_conn *conn, u8 reason)
 	 * hci_connect_le serializes the connection attempts so only one
 	 * connection can be in BT_CONNECT at time.
 	 */
-	if (conn->state == BT_CONNECT && hdev->req_status == HCI_REQ_PEND) {
+	if (conn->state == BT_CONNECT && READ_ONCE(hdev->req_status) == HCI_REQ_PEND) {
 		switch (hci_skb_event(hdev->sent_cmd)) {
 		case HCI_EV_CONN_COMPLETE:
 		case HCI_EV_LE_CONN_COMPLETE:
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 8ccec73dce45c..0f86b81b39730 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -4125,7 +4125,7 @@ static int hci_send_cmd_sync(struct hci_dev *hdev, struct sk_buff *skb)
 		kfree_skb(skb);
 	}
 
-	if (hdev->req_status == HCI_REQ_PEND &&
+	if (READ_ONCE(hdev->req_status) == HCI_REQ_PEND &&
 	    !hci_dev_test_and_set_flag(hdev, HCI_CMD_PENDING)) {
 		kfree_skb(hdev->req_skb);
 		hdev->req_skb = skb_clone(hdev->sent_cmd, GFP_KERNEL);
diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c
index 9a7bd4a4b14c4..f498ab28f1aa0 100644
--- a/net/bluetooth/hci_sync.c
+++ b/net/bluetooth/hci_sync.c
@@ -25,11 +25,11 @@ static void hci_cmd_sync_complete(struct hci_dev *hdev, u8 result, u16 opcode,
 {
 	bt_dev_dbg(hdev, "result 0x%2.2x", result);
 
-	if (hdev->req_status != HCI_REQ_PEND)
+	if (READ_ONCE(hdev->req_status) != HCI_REQ_PEND)
 		return;
 
 	hdev->req_result = result;
-	hdev->req_status = HCI_REQ_DONE;
+	WRITE_ONCE(hdev->req_status, HCI_REQ_DONE);
 
 	/* Free the request command so it is not used as response */
 	kfree_skb(hdev->req_skb);
@@ -167,20 +167,20 @@ struct sk_buff *__hci_cmd_sync_sk(struct hci_dev *hdev, u16 opcode, u32 plen,
 
 	hci_cmd_sync_add(&req, opcode, plen, param, event, sk);
 
-	hdev->req_status = HCI_REQ_PEND;
+	WRITE_ONCE(hdev->req_status, HCI_REQ_PEND);
 
 	err = hci_req_sync_run(&req);
 	if (err < 0)
 		return ERR_PTR(err);
 
 	err = wait_event_interruptible_timeout(hdev->req_wait_q,
-					       hdev->req_status != HCI_REQ_PEND,
+					       READ_ONCE(hdev->req_status) != HCI_REQ_PEND,
 					       timeout);
 
 	if (err == -ERESTARTSYS)
 		return ERR_PTR(-EINTR);
 
-	switch (hdev->req_status) {
+	switch (READ_ONCE(hdev->req_status)) {
 	case HCI_REQ_DONE:
 		err = -bt_to_errno(hdev->req_result);
 		break;
@@ -194,7 +194,7 @@ struct sk_buff *__hci_cmd_sync_sk(struct hci_dev *hdev, u16 opcode, u32 plen,
 		break;
 	}
 
-	hdev->req_status = 0;
+	WRITE_ONCE(hdev->req_status, 0);
 	hdev->req_result = 0;
 	skb = hdev->req_rsp;
 	hdev->req_rsp = NULL;
@@ -665,9 +665,9 @@ void hci_cmd_sync_cancel(struct hci_dev *hdev, int err)
 {
 	bt_dev_dbg(hdev, "err 0x%2.2x", err);
 
-	if (hdev->req_status == HCI_REQ_PEND) {
+	if (READ_ONCE(hdev->req_status) == HCI_REQ_PEND) {
 		hdev->req_result = err;
-		hdev->req_status = HCI_REQ_CANCELED;
+		WRITE_ONCE(hdev->req_status, HCI_REQ_CANCELED);
 
 		queue_work(hdev->workqueue, &hdev->cmd_sync_cancel_work);
 	}
@@ -683,12 +683,12 @@ void hci_cmd_sync_cancel_sync(struct hci_dev *hdev, int err)
 {
 	bt_dev_dbg(hdev, "err 0x%2.2x", err);
 
-	if (hdev->req_status == HCI_REQ_PEND) {
+	if (READ_ONCE(hdev->req_status) == HCI_REQ_PEND) {
 		/* req_result is __u32 so error must be positive to be properly
 		 * propagated.
 		 */
 		hdev->req_result = err < 0 ? -err : err;
-		hdev->req_status = HCI_REQ_CANCELED;
+		WRITE_ONCE(hdev->req_status, HCI_REQ_CANCELED);
 
 		wake_up_interruptible(&hdev->req_wait_q);
 	}
-- 
2.53.0

[PATCH AUTOSEL 6.18] Bluetooth: hci_sync: annotate data-races around hdev->req_status

[Sasha Levin]

From: Cen Zhang <zzzccc427@gmail.com>

[ Upstream commit b6807cfc195ef99e1ac37b2e1e60df40295daa8c ]

__hci_cmd_sync_sk() sets hdev->req_status under hdev->req_lock:

    hdev->req_status = HCI_REQ_PEND;

However, several other functions read or write hdev->req_status without
holding any lock:

  - hci_send_cmd_sync() reads req_status in hci_cmd_work (workqueue)
  - hci_cmd_sync_complete() reads/writes from HCI event completion
  - hci_cmd_sync_cancel() / hci_cmd_sync_cancel_sync() read/write
  - hci_abort_conn() reads in connection abort path

Since __hci_cmd_sync_sk() runs on hdev->req_workqueue while
hci_send_cmd_sync() runs on hdev->workqueue, these are different
workqueues that can execute concurrently on different CPUs. The plain
C accesses constitute a data race.

Add READ_ONCE()/WRITE_ONCE() annotations on all concurrent accesses
to hdev->req_status to prevent potential compiler optimizations that
could affect correctness (e.g., load fusing in the wait_event
condition or store reordering).

Signed-off-by: Cen Zhang <zzzccc427@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:

Error: Failed to generate final synthesis

 net/bluetooth/hci_conn.c |  2 +-
 net/bluetooth/hci_core.c |  2 +-
 net/bluetooth/hci_sync.c | 20 ++++++++++----------
 3 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
index 24b71ec8897ff..71a24be2a6d67 100644
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -2967,7 +2967,7 @@ int hci_abort_conn(struct hci_conn *conn, u8 reason)
 	 * hci_connect_le serializes the connection attempts so only one
 	 * connection can be in BT_CONNECT at time.
 	 */
-	if (conn->state == BT_CONNECT && hdev->req_status == HCI_REQ_PEND) {
+	if (conn->state == BT_CONNECT && READ_ONCE(hdev->req_status) == HCI_REQ_PEND) {
 		switch (hci_skb_event(hdev->sent_cmd)) {
 		case HCI_EV_CONN_COMPLETE:
 		case HCI_EV_LE_CONN_COMPLETE:
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 8ccec73dce45c..0f86b81b39730 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -4125,7 +4125,7 @@ static int hci_send_cmd_sync(struct hci_dev *hdev, struct sk_buff *skb)
 		kfree_skb(skb);
 	}
 
-	if (hdev->req_status == HCI_REQ_PEND &&
+	if (READ_ONCE(hdev->req_status) == HCI_REQ_PEND &&
 	    !hci_dev_test_and_set_flag(hdev, HCI_CMD_PENDING)) {
 		kfree_skb(hdev->req_skb);
 		hdev->req_skb = skb_clone(hdev->sent_cmd, GFP_KERNEL);
diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c
index 9a7bd4a4b14c4..f498ab28f1aa0 100644
--- a/net/bluetooth/hci_sync.c
+++ b/net/bluetooth/hci_sync.c
@@ -25,11 +25,11 @@ static void hci_cmd_sync_complete(struct hci_dev *hdev, u8 result, u16 opcode,
 {
 	bt_dev_dbg(hdev, "result 0x%2.2x", result);
 
-	if (hdev->req_status != HCI_REQ_PEND)
+	if (READ_ONCE(hdev->req_status) != HCI_REQ_PEND)
 		return;
 
 	hdev->req_result = result;
-	hdev->req_status = HCI_REQ_DONE;
+	WRITE_ONCE(hdev->req_status, HCI_REQ_DONE);
 
 	/* Free the request command so it is not used as response */
 	kfree_skb(hdev->req_skb);
@@ -167,20 +167,20 @@ struct sk_buff *__hci_cmd_sync_sk(struct hci_dev *hdev, u16 opcode, u32 plen,
 
 	hci_cmd_sync_add(&req, opcode, plen, param, event, sk);
 
-	hdev->req_status = HCI_REQ_PEND;
+	WRITE_ONCE(hdev->req_status, HCI_REQ_PEND);
 
 	err = hci_req_sync_run(&req);
 	if (err < 0)
 		return ERR_PTR(err);
 
 	err = wait_event_interruptible_timeout(hdev->req_wait_q,
-					       hdev->req_status != HCI_REQ_PEND,
+					       READ_ONCE(hdev->req_status) != HCI_REQ_PEND,
 					       timeout);
 
 	if (err == -ERESTARTSYS)
 		return ERR_PTR(-EINTR);
 
-	switch (hdev->req_status) {
+	switch (READ_ONCE(hdev->req_status)) {
 	case HCI_REQ_DONE:
 		err = -bt_to_errno(hdev->req_result);
 		break;
@@ -194,7 +194,7 @@ struct sk_buff *__hci_cmd_sync_sk(struct hci_dev *hdev, u16 opcode, u32 plen,
 		break;
 	}
 
-	hdev->req_status = 0;
+	WRITE_ONCE(hdev->req_status, 0);
 	hdev->req_result = 0;
 	skb = hdev->req_rsp;
 	hdev->req_rsp = NULL;
@@ -665,9 +665,9 @@ void hci_cmd_sync_cancel(struct hci_dev *hdev, int err)
 {
 	bt_dev_dbg(hdev, "err 0x%2.2x", err);
 
-	if (hdev->req_status == HCI_REQ_PEND) {
+	if (READ_ONCE(hdev->req_status) == HCI_REQ_PEND) {
 		hdev->req_result = err;
-		hdev->req_status = HCI_REQ_CANCELED;
+		WRITE_ONCE(hdev->req_status, HCI_REQ_CANCELED);
 
 		queue_work(hdev->workqueue, &hdev->cmd_sync_cancel_work);
 	}
@@ -683,12 +683,12 @@ void hci_cmd_sync_cancel_sync(struct hci_dev *hdev, int err)
 {
 	bt_dev_dbg(hdev, "err 0x%2.2x", err);
 
-	if (hdev->req_status == HCI_REQ_PEND) {
+	if (READ_ONCE(hdev->req_status) == HCI_REQ_PEND) {
 		/* req_result is __u32 so error must be positive to be properly
 		 * propagated.
 		 */
 		hdev->req_result = err < 0 ? -err : err;
-		hdev->req_status = HCI_REQ_CANCELED;
+		WRITE_ONCE(hdev->req_status, HCI_REQ_CANCELED);
 
 		wake_up_interruptible(&hdev->req_wait_q);
 	}
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.12] Bluetooth: btusb: Add new VID/PID 13d3/3579 for MT7902

[Sasha Levin]

From: Sean Wang <sean.wang@mediatek.com>

[ Upstream commit 51c4173b89fe7399bad1381016096cc154588660 ]

Add VID 13d3 & PID 3579 for MediaTek MT7902 USB Bluetooth chip.

The information in /sys/kernel/debug/usb/devices about the Bluetooth
device is listed as the below.

T:  Bus=01 Lev=01 Prnt=01 Port=09 Cnt=04 Dev#=  7 Spd=480  MxCh= 0
D:  Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=13d3 ProdID=3579 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=btusb
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=btusb
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: Sean Wang <sean.wang@mediatek.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:

Now I have all the information needed for the full analysis. Let me
compile the results.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line**
Record: [Bluetooth: btusb] [Add] Adding new USB VID/PID 13d3/3579 for
MediaTek MT7902 Bluetooth chip.

**Step 1.2: Tags**
- Signed-off-by: Sean Wang <sean.wang@mediatek.com> (author, MediaTek
  Bluetooth developer)
- Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
  (Bluetooth subsystem maintainer)
- No Fixes: tag (expected for device ID additions)
- No Cc: stable (expected for commits under review)
- No Reported-by (but user interest is documented on the mailing list)

**Step 1.3: Body Text**
The commit message describes adding a new USB VID/PID pair for the
MT7902 Bluetooth chip. It includes full USB device descriptor
information from `/sys/kernel/debug/usb/devices`, confirming this is
real hardware with Vendor=13d3 ProdID=3579, manufactured by MediaTek
Inc.

**Step 1.4: Hidden Bug Fix?**
Record: This is not a hidden bug fix. It is a straightforward new device
ID addition to an existing driver. It falls into the "device ID
addition" exception category.

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
- Files changed: `drivers/bluetooth/btusb.c` only
- Lines: +3, -1 (net +2 lines)
- Change: Adds one USB_DEVICE entry (13d3/3579) with BTUSB_MEDIATEK |
  BTUSB_WIDEBAND_SPEECH flags, plus a comment "MediaTek MT7902 Bluetooth
  devices"
- Scope: Single-file, single-table, trivially contained

**Step 2.2: Code Flow**
The change adds an entry to the `quirks_table[]` static array. This is a
USB device matching table. When a USB device with VID=0x13d3 PID=0x3579
is plugged in, the btusb driver will now claim it with BTUSB_MEDIATEK
and BTUSB_WIDEBAND_SPEECH flags, causing the MediaTek initialization
path (btmtk) to be used.

**Step 2.3: Bug Mechanism**
Category: Hardware enablement (device ID addition). Without this ID, the
MT7902 Bluetooth hardware is not recognized by the btusb driver, leaving
users without Bluetooth.

**Step 2.4: Fix Quality**
The fix itself is a trivial 2-line device ID table addition, following
the exact pattern of dozens of existing entries. It is obviously correct
in isolation. However, it has a **critical dependency** - see Phase 3.

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: Blame**
Verified: The surrounding code (other 13d3 device IDs like 3578, 3583,
3606) was introduced by various authors from 2021-2024 and is well-
established. The btusb MediaTek infrastructure has been in the tree
since ~2021.

**Step 3.2: Fixes tag**
N/A - no Fixes: tag (expected for device ID additions).

**Step 3.3: File History**
Recent changes to `drivers/bluetooth/btusb.c` include other device ID
additions (e.g., commit 6c0568b7741a3 adding USB ID 7392:e611 for
Edimax). This is a well-trodden path.

**Step 3.4: Author**
Sean Wang is a MediaTek Bluetooth developer and regular contributor. He
has 10+ commits in `drivers/bluetooth/` including MediaTek-specific
fixes and firmware support. The commit was merged by Luiz Augusto von
Dentz, the Bluetooth subsystem maintainer.

**Step 3.5: Dependencies - CRITICAL FINDING**
This commit is patch 3/4 of a series. Patch 2/4 ("Bluetooth: btmtk: add
MT7902 MCU support") adds:
1. `case 0x7902:` to the switch in `btmtk_usb_setup()` (btmtk.c line
   ~1328)
2. `#define FIRMWARE_MT7902` to btmtk.h

**Without patch 2/4, this commit would cause the btusb driver to claim
the device, but `btmtk_usb_setup()` would hit the `default:` case at
line 1369 and return `-ENODEV` with "Unsupported hardware variant
(00007902)"**. The device would be claimed but non-functional.

Verified: grep confirmed `0x7902` is NOT in btmtk.c's switch and
`FIRMWARE_MT7902` is NOT defined in btmtk.h in this tree.

## PHASE 4: MAILING LIST RESEARCH

**Step 4.1: Original Discussion**
Found the original submission at spinics.net (mirror of linux-bluetooth
list). This was submitted as patch 3/4 on 2026-02-19. A reviewer
(Bitterblue Smith) noted a copy-paste error in the commit message body
text ("MT7922" should be "MT7902").

**Step 4.2: Reviewers**
Sent to linux-bluetooth@vger.kernel.org and linux-
mediatek@lists.infradead.org. Merged by the Bluetooth subsystem
maintainer (Luiz Augusto von Dentz).

**Step 4.3: User Reports**
Multiple users confirmed they have MT7902 hardware:
- OnlineLearningTutorials reported PID 13d3/3580 (another MT7902
  variant)
- Two additional USB IDs (13d3/3594, 13d3/3596) were reported
- Bitterblue Smith reported 0e8d/1ede (yet another MT7902 variant)
- Sean Wang acknowledged these and promised to add them in a future
  version

This confirms real user demand for MT7902 support.

**Step 4.4/4.5: Series and Stable Context**
The series is 4 patches: SDIO ID (1/4), MCU support (2/4), USB ID (3/4),
SDIO support (4/4). Patches 1 and 4 are for SDIO and not needed for USB.
Patch 2 is required for this commit.

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1-5.4: Function Analysis**
The change is to a static data table (`quirks_table[]`), not a function.
The table is used by the USB subsystem's device matching mechanism. When
a matching USB device is found, `btusb_probe()` is called, which sets up
the device using MediaTek-specific code paths (via `btmtk_usb_setup()`).

The `btmtk_fw_get_filename()` function at line 112-127 already handles
0x7902 correctly via its `else` branch (generates
"mediatek/BT_RAM_CODE_MT7902_1_X_hdr.bin"). The only missing piece is
the `case 0x7902:` in the switch statement to reach that code path.

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1: Buggy Code in Stable?**
The btusb driver and MediaTek support infrastructure (BTUSB_MEDIATEK)
exist in this stable tree (7.0). There are already ~70 BTUSB_MEDIATEK
entries. The code to support MT7902 exists in principle (same firmware
loading path as MT7922/MT7925/MT7961), but the specific device ID 0x7902
is not handled in btmtk.c's switch.

**Step 6.2: Backport Complications**
The USB device ID addition itself would apply cleanly. However, it MUST
be accompanied by patch 2/4 (adding `case 0x7902:` to btmtk.c). That
patch is also trivially small (1 line in btmtk.c, 1 line in btmtk.h).

**Step 6.3: Related Fixes in Stable**
No MT7902 support exists in this stable tree.

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

**Step 7.1:** Bluetooth subsystem (`drivers/bluetooth/`), Criticality:
IMPORTANT. Bluetooth is used widely on laptops and desktops.

**Step 7.2:** The btusb driver is actively developed with frequent
device ID additions.

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: Affected Users**
Users with MediaTek MT7902 Bluetooth hardware (13d3/3579 variant). The
mailing list confirms multiple people have this hardware.

**Step 8.2: Trigger**
Without this patch: Bluetooth hardware is not recognized at all. No
Bluetooth functionality.

**Step 8.3: Severity**
Without this: complete hardware non-functionality (no Bluetooth). With
this (plus dependency): hardware works. Severity of the absence: HIGH
for affected users.

**Step 8.4: Risk-Benefit**
- BENEFIT: Enables Bluetooth on MT7902 hardware. Users have no
  workaround.
- RISK: Extremely low. Device ID table additions are the safest possible
  changes - they only affect users who have the specific hardware.
  Combined with the dependency, total change is ~4 lines.

## PHASE 9: FINAL SYNTHESIS

**Evidence FOR backporting:**
- Classic device ID addition pattern - explicitly allowed in stable
- Trivially small change (2 lines in btusb.c)
- Real users need this (confirmed on mailing list by multiple people)
- Follows exact pattern of 70+ existing BTUSB_MEDIATEK entries
- Written by MediaTek developer, merged by Bluetooth maintainer
- Zero risk to users without this hardware

**Evidence AGAINST backporting:**
- Requires a companion patch (2/4: btmtk MCU support) to function
- Without that companion, this would make things slightly worse (device
  claimed but non-functional)
- Part of a 4-patch series (though only 2/4 is needed for USB)

**Stable Rules Checklist:**
1. Obviously correct? YES - trivial table entry following established
   pattern
2. Fixes real bug? YES - enables hardware that doesn't work without it
3. Important? YES for affected users - complete Bluetooth failure
4. Small/contained? YES - 2 lines
5. No new features/APIs? Correct - device ID in existing driver
6. Applies to stable? YES, with dependency

**Exception Category:** NEW DEVICE ID to existing driver - explicitly
allowed.

## Verification

- [Phase 1] Parsed tags: Sean Wang (MediaTek dev) authored, Luiz von
  Dentz (BT maintainer) merged
- [Phase 2] Diff: 2 lines added to `quirks_table[]` in btusb.c, adds
  USB_DEVICE(0x13d3, 0x3579)
- [Phase 3] git blame: surrounding entries from 2021-2024, well-
  established table
- [Phase 3] Dependency: grep confirmed 0x7902 NOT in btmtk.c switch,
  FIRMWARE_MT7902 NOT in btmtk.h
- [Phase 3] btmtk_usb_setup default case returns -ENODEV (line
  1369-1372), confirmed by reading code
- [Phase 4] Found original submission at spinics.net/lists/linux-
  bluetooth/msg126673.html
- [Phase 4] Multiple users confirmed MT7902 hardware on mailing list
  (msg126726, msg126732)
- [Phase 4] Sean Wang promised additional MT7902 VID/PIDs (msg126729)
- [Phase 5] btmtk_fw_get_filename() else clause handles 0x7902 correctly
  (line 123-126)
- [Phase 6] BTUSB_MEDIATEK infrastructure confirmed present (70 entries,
  grep verified)
- [Phase 6] MT7902 MCU support NOT present in stable 7.0 tree (grep
  verified)
- [Phase 8] Risk is extremely low - only affects specific hardware,
  follows existing pattern
- DEPENDENCY: Patch 2/4 ("Bluetooth: btmtk: add MT7902 MCU support") is
  REQUIRED for this to function

This is a textbook device ID addition that should be backported to
stable, with the caveat that patch 2/4 from the same series must also be
included. Without that companion patch, the device would be claimed but
fail initialization. The combined change is ~4 lines and extremely low
risk.

**YES**

 drivers/bluetooth/btusb.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index d07db8e3a79d5..1acc07d0dc061 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -671,7 +671,9 @@ static const struct usb_device_id quirks_table[] = {
 						     BTUSB_WIDEBAND_SPEECH },
 	{ USB_DEVICE(0x13d3, 0x3606), .driver_info = BTUSB_MEDIATEK |
 						     BTUSB_WIDEBAND_SPEECH },
-
+	/* MediaTek MT7902 Bluetooth devices */
+	{ USB_DEVICE(0x13d3, 0x3579), .driver_info = BTUSB_MEDIATEK |
+						     BTUSB_WIDEBAND_SPEECH },
 	/* MediaTek MT7922 Bluetooth devices */
 	{ USB_DEVICE(0x13d3, 0x3585), .driver_info = BTUSB_MEDIATEK |
 						     BTUSB_WIDEBAND_SPEECH },
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.12] Bluetooth: btusb: MediaTek MT7922: Add VID 0489 & PID e11d

[Sasha Levin]

From: Kamiyama Chiaki <nercone@nercone.dev>

[ Upstream commit 5e17010bfc7e6820a5004f1e06d08db886e3927e ]

Add VID 0489 & PID e11d for MediaTek MT7922 USB Bluetooth chip.
Found in Dynabook GA/ZY (W6GAZY5RCL).

The information in /sys/kernel/debug/usb/devices about the Bluetooth
device is listed as the below.

T:  Bus=03 Lev=01 Prnt=01 Port=03 Cnt=02 Dev#=  3 Spd=480  MxCh= 0
D:  Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=0489 ProdID=e11d Rev= 1.00
S:  Manufacturer=MediaTek Inc.
S:  Product=Wireless_Device
S:  SerialNumber=000000000

Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Signed-off-by: Kamiyama Chiaki <nercone@nercone.dev>
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:

Good. Now let me finalize the analysis. I have all the key facts.

---

## Complete Analysis: Bluetooth: btusb: MediaTek MT7922: Add VID 0489 &
PID e11d

### PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line**
- Subsystem: `Bluetooth: btusb`
- Action: "Add" (device ID addition)
- Summary: Adds USB Vendor ID 0489 and Product ID e11d for a MediaTek
  MT7922 Bluetooth chip.
- Record: [Bluetooth/btusb] [Add] [New USB device ID for MT7922 variant
  in Dynabook laptop]

**Step 1.2: Tags**
- Reviewed-by: Paul Menzel (well-known kernel reviewer)
- Signed-off-by: Kamiyama Chiaki (author)
- Signed-off-by: Luiz Augusto von Dentz (Bluetooth subsystem maintainer)
- No Fixes: tag (expected — this is a device ID, not a bug fix)
- No Reported-by / syzbot
- Record: Reviewed by Paul Menzel. Signed off by the Bluetooth
  maintainer (Luiz von Dentz). No Fixes/Cc: stable tags expected for
  device ID additions.

**Step 1.3: Commit Body**
- Identifies the specific laptop: Dynabook GA/ZY (W6GAZY5RCL)
- Provides full USB descriptor dump confirming MediaTek Inc. as
  manufacturer
- The device is a "Wireless_Device" at USB 2.0 speed (480 Mbps)
- Record: Clear real-world hardware identification. Without this ID,
  Bluetooth does not work on this specific laptop.

**Step 1.4: Hidden Bug Fix Detection**
- This is not a hidden bug fix — it's an explicit device ID addition.
  But it does fix a real user problem: Bluetooth doesn't work on
  Dynabook GA/ZY without this entry.
- Record: Not a hidden bug fix. Straightforward device enablement.

### PHASE 2: DIFF ANALYSIS

**Step 2.1: Changes Inventory**
- 1 file modified: `drivers/bluetooth/btusb.c`
- 2 lines added, 0 lines removed
- Change location: USB device ID quirks_table[] in the MT7922A section
- Record: Single file, +2 lines, one function (static table). Scope:
  trivially small.

**Step 2.2: Code Flow Change**
- Before: Device 0489:e11d is not recognized by btusb → generic USB
  handling, Bluetooth non-functional
- After: Device 0489:e11d is matched → BTUSB_MEDIATEK |
  BTUSB_WIDEBAND_SPEECH flags set → proper MediaTek initialization path
  used → Bluetooth works
- Record: Table entry addition only. No logic change.

**Step 2.3: Bug Mechanism**
- Category: Hardware enablement (device ID addition)
- The new entry `{ USB_DEVICE(0x0489, 0xe11d), .driver_info =
  BTUSB_MEDIATEK | BTUSB_WIDEBAND_SPEECH }` is identical in pattern to
  all other MT7922A entries in the table.
- Record: Device ID addition to existing driver table. Uses identical
  flags as all sibling entries.

**Step 2.4: Fix Quality**
- Obviously correct — exact same pattern as dozens of adjacent entries
- Minimal/surgical — 2 lines in a static table
- Zero regression risk — only affects the specific USB device 0489:e11d
- Record: Trivially correct. Zero regression risk.

### PHASE 3: GIT HISTORY

**Step 3.1: Blame**
- MT7922A section created in commit 6932627425d6 (Dec 2021, v5.17 cycle)
- MT7922 support added in 8c0401b7308cb (Mar 2024)
- Both are ancestors of HEAD (v7.0)
- Many other device IDs have been added to this section over the years
- Record: MT7922A driver support has existed since Linux 5.17. Present
  in all active stable trees.

**Step 3.3: File History**
- `btusb.c` is actively maintained with frequent device ID additions
- Recent commits include other MT7922 ID additions (e170, e152, e153,
  3584, etc.)
- Record: Active file. Frequent device ID additions. No prerequisites
  needed.

**Step 3.4: Author Context**
- Author (Kamiyama Chiaki) appears to be a first-time contributor (no
  other commits found)
- Signed off by Bluetooth maintainer Luiz Augusto von Dentz
- Reviewed by Paul Menzel
- Record: New contributor, but patch reviewed and signed off by the
  subsystem maintainer.

**Step 3.5: Dependencies**
- The diff context shows `0xe174` and `0x04ca, 0x3807` in the
  surrounding lines, which are NOT present in the 7.0 tree. These are
  other device IDs added around the same time.
- However, this is a table entry addition — it has no code dependencies.
  The entry can be placed anywhere in the MT7922A section.
- Record: No functional dependencies. Minor context conflict expected
  (trivially resolvable by placing the entry adjacent to existing
  0489:e102 entry).

### PHASE 4: MAILING LIST RESEARCH

**Step 4.1-4.2:** b4 dig could not find the commit (it hasn't been
applied to the tree under analysis). Web search did not find the
specific lore thread. However, the commit was reviewed by Paul Menzel
and signed off by the Bluetooth maintainer, which is sufficient vetting.

**Step 4.3-4.5:** No bug report — this is hardware enablement rather
than a bug fix. No stable discussion found.

### PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1-5.4:** Not applicable in the traditional sense — this is a
static data table addition, not a function change. The `quirks_table[]`
is used by the USB core to match devices during enumeration. When a
device with VID 0489/PID e11d is connected, the `BTUSB_MEDIATEK` flag
triggers the MediaTek initialization path in btusb.

Record: Static table entry. The MediaTek code path is well-tested and
used by dozens of other device IDs.

### PHASE 6: STABLE TREE ANALYSIS

**Step 6.1:** The MT7922A device ID section exists in all stable trees
from 5.17 onward. The `BTUSB_MEDIATEK` and `BTUSB_WIDEBAND_SPEECH` flags
exist in all active stable trees.

**Step 6.2:** Minor context conflict expected due to other device IDs
added in the same section. Trivial to resolve — just add the 2-line
entry in the correct position.

**Step 6.3:** No related fixes already in stable for this specific
device ID.

### PHASE 7: SUBSYSTEM CONTEXT

**Step 7.1:** Bluetooth (drivers/bluetooth/) — IMPORTANT subsystem.
Bluetooth is critical for laptops and mobile devices.

**Step 7.2:** btusb.c is actively developed with frequent device ID
additions. This is a well-established pattern.

### PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1:** Affects users of Dynabook GA/ZY (W6GAZY5RCL) and any other
device using the Foxconn/MediaTek 0489:e11d Bluetooth adapter.

**Step 8.2:** Trigger: any user who has this hardware and plugs it in or
boots with it. Without this entry, Bluetooth is completely non-
functional.

**Step 8.3:** Without the fix: Bluetooth does not work at all. Severity:
HIGH for affected users (complete loss of functionality).

**Step 8.4:**
- Benefit: HIGH — enables Bluetooth on real hardware
- Risk: VERY LOW — 2-line static table entry, affects only this specific
  USB device
- Ratio: Excellent benefit-to-risk ratio

### PHASE 9: FINAL SYNTHESIS

**Step 9.1: Evidence FOR backporting:**
- Textbook USB device ID addition — the #1 most common exception
  category for stable
- 2 lines added to a static table — minimal possible change
- Zero regression risk — only affects the specific 0489:e11d device
- MT7922 driver support exists in all active stable trees (since 5.17)
- Reviewed and signed off by the Bluetooth subsystem maintainer
- Enables hardware for a real product (Dynabook GA/ZY)

**Evidence AGAINST backporting:**
- None identified. Minor context conflict is trivially resolvable.

**Step 9.2: Stable Rules Checklist:**
1. Obviously correct? YES — identical pattern to 20+ adjacent entries
2. Fixes a real problem? YES — Bluetooth non-functional without it
3. Important issue? YES — complete loss of Bluetooth functionality
4. Small and contained? YES — 2 lines in one file
5. No new features or APIs? CORRECT — just a device ID
6. Can apply to stable? YES — with trivial context adjustment

**Step 9.3: Exception Category:** YES — This is a **NEW DEVICE ID**
addition to an existing driver. This is explicitly listed as an allowed
exception to stable rules.

### Verification

- [Phase 1] Parsed tags: Reviewed-by Paul Menzel, Signed-off-by Luiz von
  Dentz (Bluetooth maintainer)
- [Phase 2] Diff analysis: +2 lines in static USB device ID table,
  identical pattern to adjacent entries
- [Phase 3] git blame: MT7922A section created in 6932627425d6 (Dec
  2021), present in tree since v5.17
- [Phase 3] git merge-base: Confirmed 6932627425d6 and 8c0401b7308cb are
  ancestors of HEAD
- [Phase 3] Grep for 0xe11d: Confirmed device ID not yet present in v7.0
  tree
- [Phase 5] Grep for MT7922: Confirmed MT7922/MT7922A sections exist
  with many similar entries at lines 675-719
- [Phase 6] MT7922A support exists in all active stable trees
  (introduced in 5.17 cycle)
- [Phase 6] Context conflict: 0xe174 and 0x04ca:3807 in diff context
  don't exist in 7.0 — trivial conflict
- [Phase 8] Impact: Complete Bluetooth failure on Dynabook GA/ZY without
  this ID
- UNVERIFIED: Could not access lore.kernel.org discussion thread due to
  anti-bot protection

This is a textbook device ID addition — the most common and safest type
of stable backport. Two lines in a static table, zero regression risk,
enables real hardware for real users.

**YES**

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

diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 1acc07d0dc061..5672f0ac27557 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -699,6 +699,8 @@ static const struct usb_device_id quirks_table[] = {
 						     BTUSB_WIDEBAND_SPEECH },
 	{ USB_DEVICE(0x0489, 0xe102), .driver_info = BTUSB_MEDIATEK |
 						     BTUSB_WIDEBAND_SPEECH },
+	{ USB_DEVICE(0x0489, 0xe11d), .driver_info = BTUSB_MEDIATEK |
+						     BTUSB_WIDEBAND_SPEECH },
 	{ USB_DEVICE(0x0489, 0xe152), .driver_info = BTUSB_MEDIATEK |
 						     BTUSB_WIDEBAND_SPEECH },
 	{ USB_DEVICE(0x0489, 0xe153), .driver_info = BTUSB_MEDIATEK |
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.12] Bluetooth: btusb: Add Lite-On 04ca:3807 for MediaTek MT7921

[Sasha Levin]

From: Dylan Eray <dylan.eray6@gmail.com>

[ Upstream commit 67377cd38b89ce782ccdb83bda3f65a2def843cd ]

Add USB device ID (04ca:3807) for a Lite-On Wireless_Device containing
a MediaTek MT7921 (MT7920) Bluetooth chipset found in Acer laptops.

Without this entry, btusb binds via the generic USB class-based wildcard
match but never sets the BTUSB_MEDIATEK flag. This means btmtk never
triggers firmware loading, and the driver sends a raw HCI Reset that
the uninitialized chip cannot respond to, resulting in:

  Bluetooth: hci0: Opcode 0x0c03 failed: -110

The information in /sys/kernel/debug/usb/devices about the Bluetooth
device is listed as the below:

T:  Bus=03 Lev=01 Prnt=01 Port=09 Cnt=01 Dev#=5 Spd=480 MxCh=0
P:  Vendor=04ca ProdID=3807 Rev=1.00
S:  Manufacturer=MediaTek Inc.
S:  Product=Wireless_Device
S:  SerialNumber=000000000
C:  #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I:  If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I:  If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)

Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Signed-off-by: Dylan Eray <dylan.eray6@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:

Now I have all the information needed for a complete analysis. Let me
compile the findings.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line**
- Subsystem: `Bluetooth: btusb:`
- Action verb: "Add" (adding a USB device ID)
- Summary: Adding USB device ID 04ca:3807 for Lite-On/MediaTek MT7921
  Bluetooth adapter

Record: [Bluetooth: btusb] [Add] [New USB device ID for existing
MediaTek BT chipset]

**Step 1.2: Tags**
- Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> (confirmed from
  mailing list review)
- Signed-off-by: Dylan Eray <dylan.eray6@gmail.com> (author)
- Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
  (Bluetooth maintainer)
- No Fixes: tag, no Cc: stable — expected for the commits under review

Record: Reviewed by Paul Menzel, applied by Bluetooth subsystem
maintainer Luiz Augusto von Dentz.

**Step 1.3: Commit Body**
The commit describes a clear, concrete bug: without this device ID
entry, btusb binds via the generic USB class wildcard but never sets
`BTUSB_MEDIATEK`, preventing firmware loading. The chip receives a raw
HCI Reset it cannot handle, producing:
`Bluetooth: hci0: Opcode 0x0c03 failed: -110`
This means Bluetooth is completely non-functional on Acer laptops with
this Lite-On adapter.

Record: [Bug: Bluetooth completely broken on affected Acer laptops]
[Symptom: HCI Reset fails with -110 timeout] [Root cause: missing
device-specific flag prevents firmware loading]

**Step 1.4: Hidden Bug Fix Detection**
This is not disguised — it's a straightforward device ID addition that
fixes a real hardware enablement issue.

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
- 1 file changed: `drivers/bluetooth/btusb.c`
- +2 lines added, 0 lines removed
- Only change is adding a new entry to the `quirks_table[]` array

Record: [1 file, +2 lines] [quirks_table[] in btusb.c] [Trivial single-
table addition]

**Step 2.2: Code Flow Change**
Before: Device 04ca:3807 matches the generic USB class wildcard, btusb
loads without `BTUSB_MEDIATEK` flag, firmware not loaded, chip cannot
respond to HCI commands.
After: Device 04ca:3807 matches the specific USB_DEVICE entry with
`BTUSB_MEDIATEK | BTUSB_WIDEBAND_SPEECH` flags, btmtk firmware loading
is triggered, Bluetooth works.

**Step 2.3: Bug Mechanism**
Category: Hardware workaround / Device ID addition. The format is
identical to dozens of surrounding entries in the same table.

**Step 2.4: Fix Quality**
The fix is a 2-line addition to a static table, following the exact same
pattern as all neighboring entries (e.g., 04ca:3804, 04ca:38e4).
Obviously correct. Zero regression risk — only affects the specific USB
VID/PID.

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: Blame**
The neighboring entry `04ca:3804` was added in commit 59be4be82bd363
"Bluetooth: btusb: Add new VID/PID 04ca/3804 for MT7922" by Chris Lu
(2023-07-07). The MediaTek device ID section has been present and
actively extended since at least 2023.

**Step 3.2: Fixes tag** — No Fixes: tag (expected). Not applicable.

**Step 3.3: File History**
Recent btusb.c changes show a pattern of frequent device ID additions,
which are standard for this file. The device ID 04ca:3807 is confirmed
NOT yet in the 7.0 tree.

**Step 3.4: Author**
Dylan Eray appears to be an external contributor (Acer laptop user who
encountered the bug). The patch was reviewed and applied by the
Bluetooth subsystem maintainer Luiz Augusto von Dentz.

**Step 3.5: Dependencies**
None. This is a standalone 2-line addition to a static array. The
MediaTek MT7921/MT7922 support infrastructure (`btmtk.c`, `btmtk.h`,
`BTUSB_MEDIATEK` flag) has been present in the kernel since well before
v6.1.

## PHASE 4: MAILING LIST RESEARCH

**Step 4.1: Original Patch Discussion**
Found via web search. The patch went through v1 -> v2. The v1 was
submitted 2026-02-19 and reviewer Paul Menzel suggested adding USB
device info output to the commit message. The v2 incorporated that
feedback and received Paul Menzel's Reviewed-by. It was applied to
bluetooth/bluetooth-next as commit 79e029818394.

**Step 4.2: Reviewers**
- Paul Menzel (reviewer) — confirmed reviewed the diff and said "The
  diff looks good."
- Luiz Augusto von Dentz (Bluetooth maintainer) — applied the patch
- Sean Wang (MediaTek) was CC'd on the submission

**Step 4.3: Bug Report**
The author IS the bug reporter — they discovered the issue on their Acer
laptop. No syzbot or bugzilla, but a clear real-world user who can't use
Bluetooth.

**Step 4.4-4.5: Related Patches / Stable Discussion**
No explicit stable nomination found. This is typical for device ID
additions that are manually selected.

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1-5.4:** The change only affects the `quirks_table[]` static
initializer in btusb.c. It adds a new USB device match entry. When USB
enumeration encounters this VID/PID, it will now set `BTUSB_MEDIATEK |
BTUSB_WIDEBAND_SPEECH` flags, causing the btmtk firmware loading path to
be used. The MT7921 support code is confirmed present in `btmtk.c`,
`btmtk.h`.

**Step 5.5:** There are ~70 existing `BTUSB_MEDIATEK` entries in this
file. This follows an identical pattern.

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1:** The MediaTek Bluetooth support (BTUSB_MEDIATEK, btmtk
firmware loading) exists in all active stable trees. The
`quirks_table[]` structure exists in all versions. The neighboring entry
04ca:3804 was added in 2023 and is in older stable trees.

**Step 6.2:** The patch will apply cleanly or with trivial context
adjustment. The table area may have slightly different surrounding
entries in older stable trees, but the insertion point (between
04ca:3804 and 04ca:38e4) should be present.

**Step 6.3:** No related fix already in stable for this specific device
ID.

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

**Step 7.1:** Bluetooth is an IMPORTANT subsystem — widely used on
laptops, IoT, and mobile devices. btusb.c is the primary USB Bluetooth
driver.

**Step 7.2:** btusb.c is actively maintained with frequent device ID
additions.

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1:** Affected: Users of Acer laptops with the Lite-On 04ca:3807
Bluetooth adapter.

**Step 8.2:** Trigger: Every boot. Bluetooth is completely non-
functional without this fix.

**Step 8.3:** Severity: HIGH — complete loss of Bluetooth functionality
on affected hardware. Not a crash, but total feature loss.

**Step 8.4:**
- **Benefit:** HIGH — makes Bluetooth work on Acer laptops with this
  chipset
- **Risk:** VERY LOW — 2-line addition to a static table, only affects
  devices with this specific VID/PID. Zero chance of regression to
  existing devices.

## PHASE 9: FINAL SYNTHESIS

**Evidence FOR:**
- Classic device ID addition — explicitly listed as an exception that is
  "almost always YES" for stable
- 2-line change, zero regression risk
- Fixes complete Bluetooth failure on real hardware (Acer laptops)
- Reviewed by Paul Menzel, applied by Bluetooth maintainer
- MediaTek MT7921 support infrastructure exists in all active stable
  trees
- Follows identical pattern of dozens of existing entries
- Standalone — no dependencies whatsoever

**Evidence AGAINST:**
- None

**Stable Rules Checklist:**
1. Obviously correct? YES — identical to surrounding entries
2. Fixes a real bug? YES — Bluetooth completely broken without it
3. Important issue? YES — total hardware feature loss
4. Small and contained? YES — 2 lines in 1 file
5. No new features/APIs? CORRECT — just a device ID to an existing
   driver
6. Can apply to stable? YES — clean apply expected

**Exception Category:** This is a USB device ID addition to an existing
driver — an explicitly recognized exception for stable backporting.

## Verification

- [Phase 1] Parsed tags: Reviewed-by Paul Menzel, SOB by author and
  maintainer
- [Phase 2] Diff analysis: 2-line addition to `quirks_table[]`, adds
  `USB_DEVICE(0x04ca, 0x3807)` with `BTUSB_MEDIATEK |
  BTUSB_WIDEBAND_SPEECH`
- [Phase 3] git blame: neighboring 04ca:3804 added in commit
  59be4be82bd363 (2023-07-07), MediaTek support long-standing
- [Phase 3] grep confirmed 04ca:3807 NOT yet in the 7.0 tree
- [Phase 3] Confirmed MT7921/MT7922 firmware support present in btmtk.h
  and btmtk.c
- [Phase 4] Found v1 and v2 submissions on spinics.net mirror; v1
  reviewed by Paul Menzel who requested USB device info, v2 incorporated
  feedback
- [Phase 4] Patch applied to bluetooth-next as commit 79e029818394 by
  Luiz Augusto von Dentz
- [Phase 5] BTUSB_MEDIATEK appears ~70 times in btusb.c — this is a
  well-established pattern
- [Phase 6] MediaTek support infrastructure confirmed present in all
  stable trees
- [Phase 8] Impact: Bluetooth completely non-functional without this fix
  on affected Acer laptops

**YES**

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

diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index aeba026bdb427..d07db8e3a79d5 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -707,6 +707,8 @@ static const struct usb_device_id quirks_table[] = {
 						     BTUSB_WIDEBAND_SPEECH },
 	{ USB_DEVICE(0x04ca, 0x3804), .driver_info = BTUSB_MEDIATEK |
 						     BTUSB_WIDEBAND_SPEECH },
+	{ USB_DEVICE(0x04ca, 0x3807), .driver_info = BTUSB_MEDIATEK |
+						     BTUSB_WIDEBAND_SPEECH },
 	{ USB_DEVICE(0x04ca, 0x38e4), .driver_info = BTUSB_MEDIATEK |
 						     BTUSB_WIDEBAND_SPEECH },
 	{ USB_DEVICE(0x13d3, 0x3568), .driver_info = BTUSB_MEDIATEK |
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.12] Bluetooth: btmtk: add MT7902 MCU support

[Sasha Levin]

From: Sean Wang <sean.wang@mediatek.com>

[ Upstream commit aab25984e55972e53f3e58821cb85a7101876056 ]

Add MT7902 device ID and firmware filename to enable MCU firmware
loading.

Signed-off-by: Sean Wang <sean.wang@mediatek.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:

Now I have enough information for a thorough analysis. Let me compile my
findings.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: PARSE THE SUBJECT LINE**
Record: [Bluetooth: btmtk] [add] [MT7902 MCU support - adds device ID
and firmware filename for MT7902 chip]

**Step 1.2: PARSE ALL COMMIT MESSAGE TAGS**
- Signed-off-by: Sean Wang <sean.wang@mediatek.com> - Author, MediaTek
  employee, regular Bluetooth/WiFi contributor
- Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> -
  Bluetooth subsystem maintainer, applied the patch
- No Fixes: tag (expected for this type of commit)
- No Reported-by: (this is hardware enablement, not a bug report)
- No Cc: stable (expected)

Record: Author is MediaTek developer. Applied by Bluetooth subsystem
maintainer.

**Step 1.3: ANALYZE THE COMMIT BODY TEXT**
The commit message is straightforward: "Add MT7902 device ID and
firmware filename to enable MCU firmware loading." This is new hardware
enablement for the MT7902 Bluetooth chip.

Record: No bug description - this is a device ID addition for hardware
enablement.

**Step 1.4: DETECT HIDDEN BUG FIXES**
Without this patch, MT7902 devices that are matched by the vendor
wildcard USB entry `USB_VENDOR_AND_INTERFACE_INFO(0x0e8d, 0xe0, 0x01,
0x01)` will hit the `default:` case in `btmtk_usb_setup()` and return
-ENODEV with "Unsupported hardware variant". This effectively makes the
hardware non-functional.

Record: This is a hardware enablement commit, not a hidden bug fix. But
it prevents -ENODEV for real hardware.

---

## PHASE 2: DIFF ANALYSIS

**Step 2.1: INVENTORY THE CHANGES**
- `drivers/bluetooth/btmtk.h`: +1 line (FIRMWARE_MT7902 define)
- `drivers/bluetooth/btmtk.c`: +1 line (case 0x7902: in switch)
- Total: 2 lines added, 0 removed
- Functions modified: `btmtk_usb_setup()` (new case label in switch)
- Scope: single-file surgical addition

Record: 2 files, 2 lines added, scope is minimal.

**Step 2.2: UNDERSTAND THE CODE FLOW CHANGE**
- Before: `btmtk_usb_setup()` switch on dev_id has cases for 0x7663,
  0x7668, 0x7922, 0x7925, 0x7961. Device ID 0x7902 falls to `default:`
  -> returns -ENODEV.
- After: 0x7902 falls through to the same path as 0x7922/0x7925/0x7961,
  which calls `btmtk_fw_get_filename()` to generate firmware name and
  `btmtk_setup_firmware_79xx()` to load it.

Record: Adds a case label to fall through to existing firmware loading
code. No new execution paths.

**Step 2.3: IDENTIFY THE BUG MECHANISM**
Category: Hardware workaround / Device ID addition.
The change adds chip ID 0x7902 to a switch statement and a firmware
filename define. The firmware name generation function
`btmtk_fw_get_filename()` already handles 0x7902 correctly via its
`else` branch, producing `"mediatek/BT_RAM_CODE_MT7902_1_%x_hdr.bin"`.

Record: Device ID addition pattern. Existing code infrastructure handles
0x7902 without changes.

**Step 2.4: ASSESS THE FIX QUALITY**
- Obviously correct: new case label falls through to identical handling
  as 0x7922/0x7925/0x7961
- Minimal and surgical: 2 lines
- Regression risk: essentially zero - this code path was unreachable
  before (would hit default case)
- No red flags

Record: Trivially correct, zero regression risk.

---

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: BLAME THE CHANGED LINES**
- `case 0x7922:` introduced by Chris Lu in 5c5e8c52e3cafa (2024-07-04) -
  the btmtk refactoring commit
- `case 0x7961:` introduced by Hao Qin in a7208610761ae9 (2025-01-10) -
  same pattern of adding device ID
- The switch statement and firmware loading infrastructure have been in
  the tree since mid-2024

Record: Code infrastructure stable since mid-2024. Existing device IDs
added via same pattern.

**Step 3.2: FOLLOW THE FIXES TAG**
No Fixes: tag present (expected for device ID additions).

**Step 3.3: CHECK FILE HISTORY**
Recent changes to btmtk.c are mostly refactoring (btusb -> btmtk moves)
and bug fixes (UAF, shutdown timeout). The device ID infrastructure is
stable.

Record: Standalone commit, no prerequisites needed.

**Step 3.4: CHECK AUTHOR**
Sean Wang is a MediaTek developer, regular contributor to both Bluetooth
and WiFi subsystems. Multiple recent commits in drivers/bluetooth/.

Record: Author is domain expert from the hardware vendor.

**Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS**
This is patch 2/4 in a series, but it is standalone for USB devices. The
other patches add SDIO device ID (1/4), USB VID/PID for third-party
module (3/4), and SDIO support code (4/4). This patch is sufficient for
USB devices matched by the vendor wildcard
`USB_VENDOR_AND_INTERFACE_INFO(0x0e8d, ...)`.

Record: Standalone for USB devices via vendor wildcard matching.

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

**Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION**
Found via spinics.net. This is [PATCH 2/4] in Sean Wang's MT7902 series
posted 2026-02-19. The series includes:
1. mmc: sdio: add MediaTek MT7902 SDIO device ID
2. Bluetooth: btmtk: add MT7902 MCU support (THIS commit)
3. Bluetooth: btusb: Add new VID/PID 13d3/3579 for MT7902
4. Bluetooth: btmtk: add MT7902 SDIO support

Record: Part of 4-patch series. This specific patch is standalone for
USB via vendor wildcard.

**Step 4.2: CHECK WHO REVIEWED**
Applied by Luiz Augusto von Dentz, the Bluetooth subsystem maintainer.
Sent to linux-bluetooth and linux-mediatek mailing lists.

Record: Applied by subsystem maintainer.

**Step 4.3: SEARCH FOR BUG REPORT**
No specific bug report - this is proactive hardware enablement by the
chip vendor.

**Step 4.4: RELATED PATCHES**
A separate patch from OnlineLearningTutorials also attempted to add
MT7902 USB IDs (with the same case 0x7902 addition). This confirms real
user demand for MT7902 support.

Record: Multiple independent submissions for MT7902 support indicate
real hardware availability.

**Step 4.5: STABLE MAILING LIST**
No specific stable discussion found.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1: KEY FUNCTIONS**
Modified: `btmtk_usb_setup()` - only a new case label added.

**Step 5.2: TRACE CALLERS**
`btmtk_usb_setup()` <- `btusb_mtk_setup()` <- assigned to `hdev->setup`
for all BTUSB_MEDIATEK devices. Called during device initialization for
every MediaTek Bluetooth USB device.

**Step 5.3-5.4: CALL CHAIN**
USB device probes -> btusb_probe() -> sets hdev->setup = btusb_mtk_setup
-> HCI core calls hdev->setup() -> btusb_mtk_setup() ->
btmtk_usb_setup() -> switch(dev_id). This is a standard device
initialization path, triggered on every device connection.

**Step 5.5: SIMILAR PATTERNS**
The same pattern is used for MT7922, MT7925, MT7961 - all case labels in
the same switch with identical fall-through behavior.

---

## PHASE 6: CROSS-REFERENCING AND STABLE TREE ANALYSIS

**Step 6.1: DOES THE BUGGY CODE EXIST IN STABLE?**
The switch statement and all 79xx case labels exist in the 7.0 tree. The
firmware loading infrastructure is present. Only the 0x7902 case is
missing.

Record: Infrastructure exists in stable. Only the device ID is missing.

**Step 6.2: BACKPORT COMPLICATIONS**
The diff context shows a retry mechanism (`BTMTK_FIRMWARE_DL_RETRY`)
that doesn't exist in the 7.0 tree. The patch will need minor context
adjustment for the btmtk.c hunk. The btmtk.h hunk applies cleanly.

Record: Minor context conflict expected; trivial manual resolution
needed.

**Step 6.3: RELATED FIXES IN STABLE**
No MT7902 support exists in stable at all.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

**Step 7.1: SUBSYSTEM CRITICALITY**
Bluetooth (drivers/bluetooth/) - IMPORTANT subsystem. Bluetooth is
widely used in laptops, phones, and IoT devices.

**Step 7.2: SUBSYSTEM ACTIVITY**
Actively developed with regular commits. Device ID additions are a
common pattern.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: WHO IS AFFECTED**
Users with MT7902 Bluetooth hardware. The MT7902 is a MediaTek wireless
chip used in laptops and embedded devices. It appears to be a
recent/current-generation chip.

**Step 8.2: TRIGGER CONDITIONS**
Triggered when a user has MT7902 hardware and the device is enumerated
via USB. The vendor wildcard USB entry matches MediaTek devices, so the
driver binds but fails at firmware loading without this patch.

**Step 8.3: FAILURE MODE**
Without this patch: `bt_dev_err(hdev, "Unsupported hardware variant
(%08x)")` and return -ENODEV. Bluetooth is completely non-functional for
these devices.

Record: Severity: MEDIUM-HIGH (complete loss of Bluetooth functionality
for affected hardware).

**Step 8.4: RISK-BENEFIT RATIO**
- BENEFIT: Enables Bluetooth for MT7902 hardware users on stable
  kernels. High benefit.
- RISK: 2 lines, falls through to well-tested existing code path.
  Essentially zero risk.

Record: Very high benefit-to-risk ratio.

---

## PHASE 9: FINAL SYNTHESIS

**Step 9.1: EVIDENCE**

FOR backporting:
- Classic device ID addition to existing driver (explicit exception
  category)
- Only 2 lines changed
- Falls through to well-tested code path (same as MT7922/MT7925/MT7961)
- Author is the chip vendor's engineer
- Applied by Bluetooth subsystem maintainer
- Enables real hardware that would otherwise be completely non-
  functional
- Multiple independent submissions for MT7902 confirm real user demand
- Zero regression risk (new case label, previously unreachable code
  path)

AGAINST backporting:
- Part of a 4-patch series (but this patch is standalone for USB via
  vendor wildcard)
- Minor context conflict may need resolution for btmtk.c hunk
- No Fixes: tag or Cc: stable (expected for device ID additions)

**Step 9.2: STABLE RULES CHECKLIST**
1. Obviously correct and tested? YES - trivial fall-through case label
2. Fixes a real bug? YES - enables hardware that returns -ENODEV
3. Important issue? YES - complete Bluetooth non-functionality for
   affected hardware
4. Small and contained? YES - 2 lines across 2 files
5. No new features or APIs? YES - just enables existing infrastructure
   for new chip ID
6. Can apply to stable? YES - with minor context adjustment

**Step 9.3: EXCEPTION CATEGORY**
YES - Device ID addition to existing driver. This is an explicitly
allowed exception.

---

## Verification

- [Phase 1] Parsed tags: Sean Wang (MediaTek) authored, Luiz von Dentz
  (BT maintainer) applied
- [Phase 2] Diff analysis: +1 case label in switch, +1 firmware define.
  2 lines total.
- [Phase 3] git blame: switch infrastructure from 5c5e8c52e3cafa
  (2024-07-04), present in stable
- [Phase 3] git log: confirmed 0x7902 does not exist anywhere in the
  current tree
- [Phase 4] Found original submission on spinics.net: [PATCH 2/4] in
  MT7902 series dated 2026-02-19
- [Phase 4] Multiple submissions: both Sean Wang (MediaTek) and an
  independent user submitted MT7902 support
- [Phase 5] Traced call chain: USB probe -> btusb_probe ->
  btusb_mtk_setup -> btmtk_usb_setup -> switch(dev_id)
- [Phase 5] Verified `btmtk_fw_get_filename()` handles 0x7902 via
  existing `else` branch
- [Phase 5] Verified vendor wildcard USB entry
  `USB_VENDOR_AND_INTERFACE_INFO(0x0e8d, ...)` matches MT7902
- [Phase 6] Confirmed switch statement and firmware loading
  infrastructure exist in 7.0 tree
- [Phase 6] Identified minor context conflict: retry mechanism in diff
  not present in stable
- [Phase 8] Without patch: "Unsupported hardware variant" error, -ENODEV
  returned, Bluetooth non-functional

This is a textbook device ID addition - minimal, obviously correct,
enabling real hardware for real users on stable kernels, with
essentially zero regression risk.

**YES**

 drivers/bluetooth/btmtk.c | 1 +
 drivers/bluetooth/btmtk.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/bluetooth/btmtk.c b/drivers/bluetooth/btmtk.c
index 0ada5a12130dc..c56c9e077040d 100644
--- a/drivers/bluetooth/btmtk.c
+++ b/drivers/bluetooth/btmtk.c
@@ -1332,6 +1332,7 @@ int btmtk_usb_setup(struct hci_dev *hdev)
 	case 0x7922:
 	case 0x7925:
 	case 0x7961:
+	case 0x7902:
 		btmtk_fw_get_filename(fw_bin_name, sizeof(fw_bin_name), dev_id,
 				      fw_version, fw_flavor);
 
diff --git a/drivers/bluetooth/btmtk.h b/drivers/bluetooth/btmtk.h
index 5df7c32966247..b4506186b2f70 100644
--- a/drivers/bluetooth/btmtk.h
+++ b/drivers/bluetooth/btmtk.h
@@ -5,6 +5,7 @@
 #define FIRMWARE_MT7663		"mediatek/mt7663pr2h.bin"
 #define FIRMWARE_MT7668		"mediatek/mt7668pr2h.bin"
 #define FIRMWARE_MT7922		"mediatek/BT_RAM_CODE_MT7922_1_1_hdr.bin"
+#define FIRMWARE_MT7902		"mediatek/BT_RAM_CODE_MT7902_1_1_hdr.bin"
 #define FIRMWARE_MT7961		"mediatek/BT_RAM_CODE_MT7961_1_2_hdr.bin"
 #define FIRMWARE_MT7925		"mediatek/mt7925/BT_RAM_CODE_MT7925_1_1_hdr.bin"
 
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.1] Bluetooth: btmtk: improve mt79xx firmware setup retry flow

[Sasha Levin]

From: Chris Lu <chris.lu@mediatek.com>

[ Upstream commit 54f1f020e9f4a087779cc4d96a7c86f47d0c6797 ]

If retries are exhausted, driver should not do futher operation.
During mt79xx firmware download process, if the retry count reaches0,
driver will return an -EIO error and release the firmware resources.

Signed-off-by: Chris Lu <chris.lu@mediatek.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:

Now I have all the information needed for a thorough analysis. Let me
compile the full assessment.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line**
Record: [bluetooth/btmtk] [improve] Fix retry exhaustion handling in
mt79xx firmware setup - when retry count reaches 0, driver should return
error instead of continuing.

**Step 1.2: Tags**
- Signed-off-by: Chris Lu <chris.lu@mediatek.com> (author, regular
  MediaTek Bluetooth contributor)
- Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
  (Bluetooth maintainer, committed the patch)
- No Fixes: tag, no Reported-by, no Cc: stable - expected for manual
  review candidates.

**Step 1.3: Commit Body**
The body describes: "If retries are exhausted, driver should not do
further operation. During mt79xx firmware download process, if the retry
count reaches 0, driver will return an -EIO error and release the
firmware resources." Clear description of a missing error check.

**Step 1.4: Hidden Bug Fix Detection**
Despite the word "improve" in the subject, this IS a bug fix. The word
"improve" masks a clear logic error: the retry loop can exhaust without
any error return, causing the driver to silently proceed with firmware
download on a device in an abnormal state.

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
- 1 file changed: `drivers/bluetooth/btmtk.c`
- +6 lines added (1 comment, 5 code lines)
- Function modified: `btmtk_setup_firmware_79xx()`
- Scope: single-file surgical fix

**Step 2.2: Code Flow Change**
The retry loop at line 171 (`while (retry > 0)`) handles
`BTMTK_WMT_PATCH_PROGRESS` by decrementing `retry`. BEFORE: if retry
hits 0, the loop exits normally and code falls through to `fw_ptr +=
section_offset`, proceeding with firmware download. AFTER: a check for
`retry == 0` returns `-EIO` and jumps to `err_release_fw`.

**Step 2.3: Bug Mechanism**
This is a **logic/correctness fix** - missing error check after retry
exhaustion. The `while (retry > 0)` loop can exit via:
1. `break` when status == `BTMTK_WMT_PATCH_UNDONE` (normal path -
   proceed to download)
2. `goto next_section` when status == `BTMTK_WMT_PATCH_DONE` (skip
   section)
3. `goto err_release_fw` on command error or unexpected status
4. Loop exhaustion when retry reaches 0 (BUG: falls through to download
   path)

Case 4 is the bug - the code proceeds as if the device is ready when
it's not.

**Step 2.4: Fix Quality**
Obviously correct. The check `if (retry == 0)` can only be true if the
loop exhausted, meaning the device never left `PATCH_PROGRESS` state.
Returning `-EIO` and cleaning up is the correct behavior. No regression
risk.

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: Blame**
The buggy code was introduced in commit `8c0d17b6b06c5b` "Bluetooth:
mediatek: add BT_MTK module" by Sean Wang on 2021-10-19. This was the
initial creation of the BT_MTK module.

**Step 3.2: No Fixes: tag** - expected.

**Step 3.3: File History**
The function `btmtk_setup_firmware_79xx` has been stable since 2021 in
the retry loop area. The surrounding code has only had one minor change
(commit `995d948cf2e458` adding `err = -EIO` in the else branch).

**Step 3.4: Author**
Chris Lu is a regular MediaTek Bluetooth contributor with 28+ commits
touching `drivers/bluetooth/`, including many device ID additions and
critical fixes.

**Step 3.5: Dependencies**
This commit is patch 1/3 of a series, but it is **standalone**. Patches
2/3 and 3/3 add additional improvements (status checking and reset
mechanism) that build on this but are not required. The fix applies
cleanly without dependencies.

## PHASE 4: MAILING LIST RESEARCH

**Step 4.1: Original Discussion**
Found via `b4 dig -c 54f1f020e9f4`: Submitted as `[PATCH v1 1/3]` on
2026-02-03. The cover letter explains: "When the device unexpectedly
restarts during previous firmware download process, it can cause mt79xx
firmware status to be abnormal in the next attempt." Series applied to
bluetooth-next by Luiz Augusto von Dentz on 2026-04-10.

**Step 4.2: Review**
Only v1 was submitted (no revisions needed). The Bluetooth maintainer
(Luiz Augusto von Dentz) applied the series directly, indicating
confidence in the fix quality.

**Step 4.3: Bug Report**
No specific bug report link. The cover letter describes a real-world
scenario where the device unexpectedly restarts during firmware
download.

**Step 4.4: Series Context**
Part of 3-patch series, but this patch is standalone. Patches 2 and 3
are independent improvements that enhance the error recovery further.

**Step 4.5: Stable Discussion**
No existing stable nomination or discussion found.

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1: Key Function**
`btmtk_setup_firmware_79xx()` - firmware setup for MT79xx series.

**Step 5.2: Callers**
- `btmtk_usb_setup()` in `btmtk.c` line 1332 - USB path for MT7922,
  MT7925, MT7961
- `mt79xx_setup()` in `btmtksdio.c` line 873 - SDIO path

Both are called during device initialization/setup.

**Step 5.3-5.4: Reachability**
Called during HCI device setup, triggered when a MT79xx Bluetooth device
is initialized. This is a common code path for all MT792x Bluetooth
device users.

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1: Code exists in stable**
The buggy code was introduced in October 2021 (commit `8c0d17b6b06c5b`).
Tags show it's in p-6.1, p-6.6, and all newer stable trees. The bug
affects ALL active stable trees.

**Step 6.2: Backport Complexity**
The patch should apply cleanly - the retry loop code hasn't changed
since the original 2021 commit.

## PHASE 7: SUBSYSTEM CONTEXT

**Step 7.1: Subsystem**
Bluetooth driver (drivers/bluetooth/) - IMPORTANT criticality.
MT7921/MT7922/MT7925 are extremely popular WiFi/BT combo chips found in
many laptops (Lenovo, ASUS, Dell, etc.).

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: Affected Users**
Users of MediaTek MT7921, MT7922, MT7925 Bluetooth devices (very large
population).

**Step 8.2: Trigger Conditions**
Triggered when the device reports `BTMTK_WMT_PATCH_PROGRESS`
continuously for 2+ seconds during firmware download. The cover letter
describes this happening after an unexpected device restart during a
previous firmware download attempt.

**Step 8.3: Failure Mode**
Without fix: firmware download proceeds on a device in an abnormal
state, potentially leading to device malfunction, failed bluetooth
initialization, or undefined behavior. Severity: MEDIUM-HIGH.

**Step 8.4: Risk-Benefit Ratio**
- BENEFIT: Prevents firmware download to a device in an abnormal state
  for widely-used hardware
- RISK: Extremely low - 5 lines, obviously correct, only affects an
  already-failed case
- Ratio: Strongly favorable

## PHASE 9: FINAL SYNTHESIS

**Evidence FOR backporting:**
- Fixes a real logic error (missing error check after retry exhaustion)
- Very small and surgical (5 lines of code)
- Obviously correct
- Affects widely-used hardware (MT792x family)
- Standalone fix with no dependencies
- Applied by subsystem maintainer without revisions needed
- Buggy code exists in all active stable trees since 2021
- Clean apply expected

**Evidence AGAINST backporting:**
- Not a crash/panic fix - the immediate impact is proceeding with
  firmware download in an abnormal state
- No specific user-reported bug linked
- Commit message uses "improve" rather than "fix"

**Stable Rules Checklist:**
1. Obviously correct and tested? YES - trivially verifiable, applied to
   bluetooth-next
2. Fixes a real bug? YES - missing error handling after retry exhaustion
3. Important issue? MEDIUM-HIGH - prevents undefined device behavior
   during firmware setup for popular hardware
4. Small and contained? YES - 5 lines, one file, one function
5. No new features? CORRECT - pure error handling fix
6. Can apply to stable? YES - clean apply expected

## Verification

- [Phase 1] Parsed tags: Signed-off-by from Chris Lu (author) and Luiz
  Augusto von Dentz (maintainer/committer)
- [Phase 2] Diff analysis: 5 lines added after retry loop in
  `btmtk_setup_firmware_79xx()`, adds `retry == 0` check returning -EIO
- [Phase 3] git blame: buggy code introduced in commit 8c0d17b6b06c5b
  (2021-10-19, Sean Wang), present in all stable trees
- [Phase 3] git tag --contains: confirmed present in p-6.1, p-6.6, and
  all newer stable tags
- [Phase 3] git log --author="Chris Lu": confirmed Chris Lu is a regular
  MediaTek BT contributor with 28+ commits
- [Phase 4] b4 dig -c 54f1f020e9f4: found original submission at
  https://patch.msgid.link/20260203062510.848761-2-chris.lu@mediatek.com
- [Phase 4] b4 dig -a: only v1, no revisions needed, applied directly by
  maintainer
- [Phase 4] Thread mbox: series was applied to bluetooth-next,
  patchwork-bot confirmed
- [Phase 4] Cover letter: describes real-world scenario (device restart
  during firmware download)
- [Phase 5] Grep callers: btmtk_usb_setup() (USB path) and
  mt79xx_setup() (SDIO path) both call this function
- [Phase 6] Code unchanged in retry loop since 2021 - clean apply
  expected
- [Phase 8] Failure mode: proceeds with firmware download on abnormal
  device state, severity MEDIUM-HIGH

**YES**

 drivers/bluetooth/btmtk.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/bluetooth/btmtk.c b/drivers/bluetooth/btmtk.c
index fa7533578f85c..0ada5a12130dc 100644
--- a/drivers/bluetooth/btmtk.c
+++ b/drivers/bluetooth/btmtk.c
@@ -205,6 +205,12 @@ int btmtk_setup_firmware_79xx(struct hci_dev *hdev, const char *fwname,
 				}
 			}
 
+			/* If retry exhausted goto err_release_fw */
+			if (retry == 0) {
+				err = -EIO;
+				goto err_release_fw;
+			}
+
 			fw_ptr += section_offset;
 			wmt_params.op = BTMTK_WMT_PATCH_DWNLD;
 			wmt_params.status = NULL;
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.12] Bluetooth: btusb: MT7922: Add VID/PID 0489/e174

[Sasha Levin]

From: Chris Lu <chris.lu@mediatek.com>

[ Upstream commit 1f2ac009d3e06380400618e777c858e582872efa ]

Add VID 0489 & PID e174 for MediaTek MT7922 USB Bluetooth chip.

The information in /sys/kernel/debug/usb/devices about the Bluetooth
device is listed as the below.

T:  Bus=06 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=480  MxCh= 0
D:  Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=0489 ProdID=e174 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=btusb
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=btusb
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: Chris Lu <chris.lu@mediatek.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:

Good. The patch would insert the `0xe174` entry right after the `0xe170`
entry (line 704-705), which is exactly the position shown in the diff.
The context lines match perfectly. Now I have all the information needed
for the analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: PARSE THE SUBJECT LINE**
Record: [Bluetooth: btusb] [Add] [VID/PID 0489/e174 for MediaTek MT7922
USB Bluetooth chip]

**Step 1.2: PARSE ALL COMMIT MESSAGE TAGS**
- Signed-off-by: Chris Lu <chris.lu@mediatek.com> — author, MediaTek
  employee
- Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> —
  Bluetooth subsystem maintainer
- No Fixes: tag (expected for device ID additions)
- No Reported-by: tag (not a bug fix, so expected)
- No Cc: stable tag (expected — that's why we're reviewing)

Record: Author is from MediaTek (chip vendor). Merged by the Bluetooth
subsystem maintainer.

**Step 1.3: ANALYZE THE COMMIT BODY TEXT**
The commit body provides the USB device descriptor dump from
`/sys/kernel/debug/usb/devices`, confirming this is a real MediaTek
MT7922 Bluetooth USB device (Vendor=0489, ProdID=e174,
Manufacturer=MediaTek Inc., Product=Wireless_Device). The device runs at
USB 2.0 High Speed (480 Mbps) and has 3 interfaces typical of a
Bluetooth HCI device.

Record: No bug described — this is a device ID addition enabling
hardware support. The device is verified to exist and be manufactured by
MediaTek.

**Step 1.4: DETECT HIDDEN BUG FIXES**
Record: This is not a hidden bug fix. It is a straightforward device ID
addition to enable Bluetooth on hardware with this specific VID/PID.

## PHASE 2: DIFF ANALYSIS - LINE BY LINE

**Step 2.1: INVENTORY THE CHANGES**
- Files changed: `drivers/bluetooth/btusb.c` only
- Lines added: +2 (one `USB_DEVICE` table entry spanning 2 lines)
- Lines removed: 0
- Function modified: None — this adds to the static `quirks_table[]`
  array
- Scope: single-file, single-table-entry addition

Record: [1 file, +2/-0 lines] [quirks_table[] static data only] [Trivial
single-entry addition]

**Step 2.2: UNDERSTAND THE CODE FLOW CHANGE**
- BEFORE: Device with VID 0489 / PID e174 is not recognized by btusb
  driver, so Bluetooth doesn't work on this hardware
- AFTER: Device is matched by `usb_device_id` table with `BTUSB_MEDIATEK
  | BTUSB_WIDEBAND_SPEECH` flags, enabling the existing MediaTek
  Bluetooth support path

Record: Purely a data table entry; no logic changes.

**Step 2.3: IDENTIFY THE BUG MECHANISM**
Category: (h) Hardware workaround / Device ID addition. Without this
entry, the btusb driver doesn't bind to the device, and the user's
Bluetooth hardware is completely non-functional.

Record: [Device ID addition] [Enables existing MT7922 driver code for a
new PID variant]

**Step 2.4: ASSESS THE FIX QUALITY**
- Obviously correct: Yes — identical pattern to dozens of other entries
  in the same table
- Minimal: Yes — 2 lines, data-only
- Regression risk: Zero — only affects devices with this specific
  VID/PID
- No API changes, no logic changes, no locking changes

Record: [Perfect quality — trivial table entry] [Zero regression risk]

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: BLAME THE CHANGED LINES**
The neighboring entry `0xe170` was added by Chris Lu (same author) in
commit `5a6700a31c953` on 2025-10-15. The MT7922A device section has
entries going back to 2023. The BTUSB_MEDIATEK driver support has been
present since at least v6.10.

Record: MT7922 support exists in tree since v6.10. This is just another
PID variant for the same chip family.

**Step 3.2: FOLLOW THE FIXES: TAG**
No Fixes: tag — expected for a device ID addition.

**Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES**
Recent btusb.c commits are heavily dominated by device ID additions
(e0e2, e0e4, e0f1, e0f2, e0f5, e0f6, e102, e152, e153, e170, plus IDs
from other vendors). This is a pattern of ongoing hardware enablement
for the MT7922 family.

Record: Standalone commit. No prerequisites beyond existing MT7922
support.

**Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS**
Chris Lu at MediaTek is a regular contributor to the Bluetooth/btusb
subsystem. He authored the e170 entry, the e135 (MT7920) entry, and a
kernel crash fix for MediaTek ISO interfaces. He clearly works on
Bluetooth at MediaTek.

Record: Author is a domain expert from the chip vendor.

**Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS**
The only prerequisite is MT7922 support via BTUSB_MEDIATEK, which has
been present since v6.10 (commit `8c0401b7308cb`). The entry `0xe170`
(the sibling right before) exists in the current tree. The patch applies
cleanly — the diff context matches the current file exactly.

Record: No dependencies beyond base MT7922 support already in stable
trees (v6.10+).

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

**Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION**
Found via web search: The patch was submitted as `[PATCH v1]` and then
`[PATCH RESEND v1]` on the linux-mediatek mailing list in January 2026.
The RESEND indicates initial posting may not have received attention.
The mailing list archive at lists.infradead.org confirms the exact same
diff.

Record: [https://lists.infradead.org/pipermail/linux-
mediatek/2026-January/103452.html] [v1 + RESEND v1] [No concerns or NAKs
visible]

**Step 4.2: CHECK WHO REVIEWED THE PATCH**
Merged by Luiz Augusto von Dentz (Bluetooth subsystem maintainer at
Intel), as indicated by his Signed-off-by.

Record: Bluetooth subsystem maintainer merged this.

**Step 4.3-4.5:** Not applicable — no bug report (this is hardware
enablement), no series dependencies.

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1-5.5:** The change is purely to the `quirks_table[]` static
data array. No functions are modified. The USB_DEVICE macro expands to
match criteria for the USB core's device matching infrastructure. When a
device with VID=0x0489/PID=0xe174 is plugged in, the btusb driver will
bind to it using the BTUSB_MEDIATEK code path. This code path is well-
tested through dozens of other MT7922 variants.

Record: No function changes. Data-only addition to existing, well-tested
USB device matching infrastructure.

## PHASE 6: CROSS-REFERENCING AND STABLE TREE ANALYSIS

**Step 6.1: DOES THE BUGGY CODE EXIST IN STABLE TREES?**
The MT7922 BTUSB_MEDIATEK support exists since v6.10. The
`quirks_table[]` and the entire MT7922 code path exist in all current
active stable trees from v6.10 onward. For older stable trees (v6.6,
v6.1), the base MT7922 support may not be present, so the device ID
alone wouldn't help there.

Record: Applicable to stable trees v6.10+, v6.12+, and future LTS
branches.

**Step 6.2: CHECK FOR BACKPORT COMPLICATIONS**
The diff context matches the current tree perfectly. The entry goes
right after 0xe170 and before 0x04ca entries. The patch will apply
cleanly.

Record: Clean apply expected.

**Step 6.3: CHECK IF RELATED FIXES ARE ALREADY IN STABLE**
No prior fix for this specific VID/PID exists.

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

**Step 7.1:** Subsystem: Bluetooth (drivers/bluetooth/). Criticality:
IMPORTANT — Bluetooth is essential on laptops and IoT devices.

**Step 7.2:** btusb.c is very actively developed with frequent device ID
additions. The MT7922 is a popular WiFi/Bluetooth combo chip used in
many laptops.

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: WHO IS AFFECTED**
Users with laptops/devices containing a MediaTek MT7922 Bluetooth chip
with the specific VID/PID 0489:e174. Without this patch, Bluetooth is
completely non-functional for these users.

**Step 8.2: TRIGGER CONDITIONS**
Trigger: simply having this hardware. Every boot, every time.

**Step 8.3: FAILURE MODE**
Without the patch: Bluetooth hardware is completely non-functional
(driver doesn't bind). With the patch: full Bluetooth functionality.

**Step 8.4: RISK-BENEFIT RATIO**
- BENEFIT: HIGH — enables Bluetooth for real hardware users
- RISK: VERY LOW — 2-line data-only change, cannot affect any other
  device
- Ratio: Excellent — maximum benefit, minimum risk

## PHASE 9: FINAL SYNTHESIS

**Step 9.1: EVIDENCE COMPILATION**
FOR backporting:
- Classic device ID addition — an explicit exception category that is
  always YES
- Only 2 lines added, data-only (zero code changes)
- Zero regression risk (only matches this specific VID/PID)
- Author is from MediaTek (chip vendor), merged by subsystem maintainer
- Real hardware that users have (USB device dump provided)
- Identical pattern to dozens of existing entries
- MT7922 driver support exists in stable trees (v6.10+)

AGAINST backporting:
- None

**Step 9.2: STABLE RULES CHECKLIST**
1. Obviously correct? YES — trivial table entry
2. Fixes a real bug? YES — enables hardware for real users
3. Important issue? YES — without it, Bluetooth is completely broken on
   this hardware
4. Small and contained? YES — 2 lines
5. No new features/APIs? CORRECT — no new features
6. Can apply to stable? YES — clean apply

**Step 9.3: EXCEPTION CATEGORY**
This is a **Device ID addition to an existing driver** — one of the
explicit exception categories that is automatically YES for stable.

## Verification

- [Phase 1] Parsed tags: Signed-off-by from Chris Lu (MediaTek) and Luiz
  Augusto von Dentz (Bluetooth maintainer)
- [Phase 2] Diff analysis: +2 lines, single USB_DEVICE entry in
  quirks_table[], data-only
- [Phase 3] git blame: neighboring entry 0xe170 added by same author in
  5a6700a31c953 (Oct 2025)
- [Phase 3] MT7922 base support in commit 8c0401b7308cb, present since
  v6.10
- [Phase 3] git merge-base: confirmed MT7922 support in v6.10 and v6.12,
  NOT in v6.6 or v6.1
- [Phase 4] Web search: found mailing list post at lists.infradead.org
  confirming RESEND v1 submission Jan 2026
- [Phase 4] Mailing list archive: identical diff confirmed, no NAKs or
  objections
- [Phase 5] No functions modified — purely static data table change
- [Phase 6] Patch applies cleanly — verified context lines match current
  tree exactly (lines 704-706)
- [Phase 6] BTUSB_MEDIATEK appears 70 times in btusb.c — well-tested
  code path
- [Phase 8] Risk: zero (only affects devices with VID=0x0489,
  PID=0xe174)

This is a textbook device ID addition to an existing, well-tested
driver. It enables Bluetooth on real MediaTek MT7922 hardware for users
who have this specific VID/PID variant. The change is 2 lines of data-
only additions with zero 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 5c535f3ab7228..aeba026bdb427 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -703,6 +703,8 @@ static const struct usb_device_id quirks_table[] = {
 						     BTUSB_WIDEBAND_SPEECH },
 	{ USB_DEVICE(0x0489, 0xe170), .driver_info = BTUSB_MEDIATEK |
 						     BTUSB_WIDEBAND_SPEECH },
+	{ USB_DEVICE(0x0489, 0xe174), .driver_info = BTUSB_MEDIATEK |
+						     BTUSB_WIDEBAND_SPEECH },
 	{ USB_DEVICE(0x04ca, 0x3804), .driver_info = BTUSB_MEDIATEK |
 						     BTUSB_WIDEBAND_SPEECH },
 	{ USB_DEVICE(0x04ca, 0x38e4), .driver_info = BTUSB_MEDIATEK |
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.10] Bluetooth: L2CAP: CoC: Disconnect if received packet size exceeds MPS

[Sasha Levin]

From: Christian Eggers <ceggers@arri.de>

[ Upstream commit 728a3d128325bad286b1e4f191026e8de8d12a85 ]

Core 6.0, Vol 3, Part A, 3.4.3:
"... If the payload size of any K-frame exceeds the receiver's MPS, the
receiver shall disconnect the channel..."

This fixes L2CAP/LE/CFC/BV-27-C (running together with 'l2test -r -P
0x0027 -V le_public -I 100').

Signed-off-by: Christian Eggers <ceggers@arri.de>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Tested-by: Christian Eggers <ceggers@arri.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information needed for a comprehensive analysis. Let
me compile the findings.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Parse Subject Line
- **Subsystem**: `Bluetooth: L2CAP: CoC` (Bluetooth L2CAP Connection-
  oriented Channels)
- **Action verb**: "Disconnect" - implies enforcing mandatory protocol
  behavior (a fix for missing behavior)
- **Summary**: Enforce Bluetooth spec-mandated channel disconnect when
  received packet exceeds MPS (Maximum PDU Size)

Record: [Bluetooth: L2CAP: CoC] [Disconnect/fix] [Enforce mandatory MPS
check and channel disconnect per BT Core 6.0 spec]

### Step 1.2: Parse Tags
- **Signed-off-by**: Christian Eggers (author), Luiz Augusto von Dentz
  (Bluetooth subsystem maintainer, committer)
- **Tested-by**: Christian Eggers (author tested the v2 version)
- **No Fixes: tag** - Expected for AUTOSEL review
- **No Cc: stable** - Expected for AUTOSEL review
- **No Reported-by** - This was found through BT Qualification test
  suite compliance testing

Record: Author is Christian Eggers, a regular Bluetooth contributor.
Committed by subsystem maintainer Luiz Augusto von Dentz. Tested by the
author.

### Step 1.3: Analyze Commit Body
- References **Bluetooth Core 6.0, Vol 3, Part A, 3.4.3** specification
  requirement
- The spec mandates: "If the payload size of any K-frame exceeds the
  receiver's MPS, the receiver shall disconnect the channel"
- This fixes **L2CAP/LE/CFC/BV-27-C** Bluetooth test case (a PTS
  qualification test)
- Without this fix, the kernel violates the Bluetooth specification

Record: Bug = missing mandatory MPS check per Bluetooth spec. Symptom =
BT qualification test failure; potential protocol state confusion from
oversized packets. Root cause = l2cap_ecred_data_rcv() never validated
packet size against MPS.

### Step 1.4: Detect Hidden Bug Fixes
This IS a bug fix, not disguised at all. The commit enforces a mandatory
spec requirement that was missing, preventing oversized packets from
being processed.

Record: Yes, this is a genuine spec compliance bug fix.

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Inventory
- **Files changed**: `net/bluetooth/l2cap_core.c` (1 file)
- **Lines**: +7 added, 0 removed
- **Function modified**: `l2cap_ecred_data_rcv()`
- **Scope**: Single-file, single-function, surgical addition

### Step 2.2: Code Flow Change
The patch adds a new check between the existing IMTU check and the
credit decrement:

- **Before**: After validating `skb->len <= chan->imtu`, immediately
  decrements rx_credits
- **After**: After IMTU check, also validates `skb->len <= chan->mps`.
  If exceeded, logs error, sends disconnect request, returns -ENOBUFS

### Step 2.3: Bug Mechanism
Category: **Logic/correctness fix** - missing validation per Bluetooth
specification

The ERTM path (`l2cap_data_rcv()` at line 6561) already checks MPS: `if
(len > chan->mps)`. This check was missing from the LE/Enhanced Credit
Based flow control path (`l2cap_ecred_data_rcv()`), which was added in
v5.7.

### Step 2.4: Fix Quality
- **Obviously correct**: Yes - identical pattern to the MPS check in
  `l2cap_data_rcv()` and the IMTU check immediately above
- **Minimal/surgical**: Yes - +7 lines, single check block
- **Regression risk**: Very low - this only rejects oversized packets
  that the spec says must be rejected
- **Red flags**: None

Record: Trivial, obviously correct spec compliance fix.

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: Blame
- `l2cap_ecred_data_rcv()` was created in commit `15f02b91056253`
  ("Bluetooth: L2CAP: Add initial code for Enhanced Credit Based Mode")
  from v5.7-rc1
- The original LE flow control code (`aac23bf63659`) dates from
  v3.14-rc1 (2013)
- The MPS check was never present in the ecred/LE flow control receive
  path

### Step 3.2: Fixes Tag
No Fixes: tag present (expected for AUTOSEL). However, the sibling
commits by the same author (e1d9a66889867, b6a2bf43aa376) reference
`Fixes: aac23bf63659`, which is in v3.14+.

### Step 3.3: File History / Related Changes
The commit is part of a **4-patch series** by Christian Eggers:
1. [PATCH 1/4] `e1d9a66889867` - Disconnect if SDU exceeds IMTU
   (**already in v7.0**)
2. [PATCH 2/4] THIS COMMIT - Disconnect if packet exceeds MPS (reworked
   as v2 by maintainer)
3. [PATCH 3/4] `b6a2bf43aa376` - Disconnect if sum of payload sizes
   exceed SDU (**already in v7.0**)
4. [PATCH 4/4] `0e4d4dcc1a6e8` - SMP test fix (**already in v7.0**)

Patches 1, 3, 4 are in the v7.0 tree. Patch 2 was reworked as a v2 by
the maintainer and applied to bluetooth-next (commit cb75c9a0505b).

### Step 3.4: Author's Context
Christian Eggers is a regular Bluetooth contributor with 8+ commits to
the Bluetooth subsystem. The maintainer (Luiz von Dentz) reworked v1 to
a simpler v2 (using `chan->mps` directly instead of a new `mps_orig_le`
field), demonstrating active review.

### Step 3.5: Dependencies
- **Soft dependency**: Commit `e1d9a66889867` changes the context above
  (reformats IMTU check and adds `l2cap_send_disconn_req`). Without it,
  the patch needs minor context adjustment, but the code logic is
  independent.
- This is functionally standalone - the MPS check is new code that
  doesn't depend on any other check.

Record: The MPS check is functionally standalone. In older stable trees
without e1d9a66889867, the context would differ slightly but the fix can
be adapted.

---

## PHASE 4: MAILING LIST RESEARCH

### Step 4.1: Original Discussion
- **v1** submitted as [PATCH 2/4] at
  `20260225170728.30327-2-ceggers@arri.de`
- v1 introduced a new `mps_orig_le` field (Luiz questioned this
  approach)
- **v2** submitted by Luiz Augusto von Dentz with simplified approach
  using `chan->mps` directly
- Applied to bluetooth-next on Feb 27, 2026

### Step 4.2: Reviewers
- Luiz Augusto von Dentz (Bluetooth subsystem maintainer) personally
  reworked the patch
- Christian Eggers provided Tested-by on v2
- No NAKs or concerns raised

### Step 4.3: No syzbot or user bug reports; found via BT qualification
testing

### Step 4.4: Series Context
The other 3 patches in the series are already in v7.0. This is the only
one remaining to be backported.

### Step 4.5: No stable-specific discussion found.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: Key Function
- `l2cap_ecred_data_rcv()` - receives data for LE FlowCtl and Enhanced
  Credit Based modes

### Step 5.2: Callers
Called from `l2cap_data_channel()` at line 6834 for both
`L2CAP_MODE_LE_FLOWCTL` and `L2CAP_MODE_EXT_FLOWCTL` modes. This is the
main L2CAP data receive path for all LE Connection-oriented Channels.

### Step 5.3-5.4: Impact Surface
This function is called on every incoming L2CAP packet for LE CoC
connections. Any Bluetooth device using LE L2CAP (BLE) can trigger this
code path.

### Step 5.5: Similar Patterns
The ERTM path in `l2cap_data_rcv()` (line 6561) already has `if (len >
chan->mps)` with disconnect. The ecred path was missing this analogous
check.

---

## PHASE 6: STABLE TREE ANALYSIS

### Step 6.1: Buggy Code Existence
- `l2cap_ecred_data_rcv()` exists since v5.7 (commit `15f02b91056253`)
- The function exists in ALL active stable trees: v5.10, v5.15, v6.1,
  v6.6, v6.12, v7.0

### Step 6.2: Backport Complications
- For stable trees that already have `e1d9a66889867` (IMTU disconnect
  fix): clean apply
- For trees without it: minor context adjustment needed (the IMTU check
  looks slightly different)

### Step 6.3: No related MPS fix already in stable.

---

## PHASE 7: SUBSYSTEM CONTEXT

### Step 7.1: Subsystem
- **Bluetooth** (`net/bluetooth/`) - IMPORTANT subsystem
- Used by all BLE-capable devices (billions of devices)

### Step 7.2: Activity
Very active - 30+ L2CAP changes in recent history with many security and
correctness fixes.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: Affected Users
All users of Bluetooth Low Energy (BLE) with L2CAP Connection-oriented
Channels. This includes IoT devices, audio devices, input peripherals,
and more.

### Step 8.2: Trigger Conditions
Any remote BLE device sending a K-frame with payload exceeding the
receiver's MPS. This can be triggered by:
- A misbehaving or malicious remote BLE device
- Protocol violations from buggy firmware

### Step 8.3: Failure Mode Severity
Without the fix:
- **Spec violation**: Oversized packets are processed instead of being
  rejected (MEDIUM)
- **Potential protocol state confusion**: Processing oversized data can
  corrupt SDU reassembly (MEDIUM-HIGH)
- **Security implication**: Remote device can send larger-than-expected
  data that gets processed (MEDIUM)
- Severity: **MEDIUM-HIGH**

### Step 8.4: Risk-Benefit Ratio
- **Benefit**: HIGH - enforces mandatory Bluetooth spec requirement,
  fixes qualification test, prevents oversized packet processing
- **Risk**: VERY LOW - +7 lines, identical pattern to existing checks,
  only rejects already-invalid packets
- **Ratio**: Strongly favorable for backport

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence Compilation

**FOR backporting:**
- Fixes missing mandatory Bluetooth Core Spec validation (spec
  compliance bug)
- +7 lines, single function, obviously correct surgical fix
- Follows identical pattern to existing MPS check in ERTM path and IMTU
  check in same function
- Reviewed/reworked by Bluetooth subsystem maintainer
- Tested by the original author
- The companion patches (1/4, 3/4) are already merged, making this
  independent
- Prevents processing oversized packets from remote devices (security-
  adjacent)
- Code exists in all active stable trees (v5.7+)

**AGAINST backporting:**
- Not triggered by syzbot or user crash reports (found via qualification
  testing)
- No explicit Fixes: tag (expected for AUTOSEL)
- Minor context adjustment may be needed for older trees without
  e1d9a66889867

### Step 9.2: Stable Rules Checklist
1. Obviously correct and tested? **YES** - tested by author, pattern-
   matched to existing code
2. Fixes a real bug? **YES** - missing mandatory spec validation
3. Important issue? **YES** - protocol compliance, potential
   security/state confusion
4. Small and contained? **YES** - +7 lines in one function
5. No new features/APIs? **YES** - only adds validation
6. Can apply to stable? **YES** - clean apply to v7.0; minor adjustment
   for older trees

### Step 9.3: Exception Categories
Not an exception category; this is a standard protocol compliance bug
fix.

### Step 9.4: Decision
This is a small, obviously correct fix that enforces a mandatory
Bluetooth specification requirement. It prevents oversized packets from
being processed by the kernel, which is both a spec compliance issue and
a security-adjacent concern. The fix is minimal (+7 lines), follows
established patterns in the same codebase, was reviewed/reworked by the
subsystem maintainer, and tested by the author.

---

## Verification

- [Phase 1] Parsed commit message: references BT Core 6.0, Vol 3, Part
  A, 3.4.3; fixes L2CAP/LE/CFC/BV-27-C test
- [Phase 2] Diff analysis: +7 lines in `l2cap_ecred_data_rcv()`, adds
  MPS size validation with disconnect
- [Phase 3] git blame: `l2cap_ecred_data_rcv()` created in
  `15f02b91056253` (v5.7-rc1), MPS check never present
- [Phase 3] git show: ERTM path at line 6561 already has `if (len >
  chan->mps)` - ecred path missing this
- [Phase 3] Related commits: siblings e1d9a66889867, b6a2bf43aa376
  already in v7.0 with Fixes: aac23bf63659
- [Phase 3] git merge-base: aac23bf63659 is in v3.14+; 15f02b91056253 is
  in v5.7+; both in all active stable trees
- [Phase 4] Mailing list: v1 reworked to v2 by maintainer Luiz von
  Dentz; Christian Eggers confirmed v2 works (Tested-by)
- [Phase 4] Applied to bluetooth-next on Feb 27, 2026 (patchwork-bot
  confirmation)
- [Phase 4] No NAKs or objections raised
- [Phase 5] Callers: `l2cap_data_channel()` for L2CAP_MODE_LE_FLOWCTL
  and L2CAP_MODE_EXT_FLOWCTL
- [Phase 6] Code exists in all active stable trees (v5.10+, v6.1, v6.6,
  v6.12)
- [Phase 8] Impact: all BLE CoC users; trigger: remote device sends
  packet > MPS; severity MEDIUM-HIGH

**YES**

 net/bluetooth/l2cap_core.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 95c65fece39bd..9916ae6abef04 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -6705,6 +6705,13 @@ static int l2cap_ecred_data_rcv(struct l2cap_chan *chan, struct sk_buff *skb)
 		return -ENOBUFS;
 	}
 
+	if (skb->len > chan->mps) {
+		BT_ERR("Too big LE L2CAP MPS: len %u > %u", skb->len,
+		       chan->mps);
+		l2cap_send_disconn_req(chan, ECONNRESET);
+		return -ENOBUFS;
+	}
+
 	chan->rx_credits--;
 	BT_DBG("chan %p: rx_credits %u -> %u",
 	       chan, chan->rx_credits + 1, chan->rx_credits);
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.10] Bluetooth: btbcm: Add entry for BCM4343A2 UART Bluetooth

[Sasha Levin]

From: Marek Vasut <marex@nabladev.com>

[ Upstream commit 04c217a7fc8f23a1c99b014cb6a89cf77ac7a012 ]

This patch adds the device ID for the BCM4343A2 module, found e.g.
in the muRata 1YN WiFi+BT combined device. The required firmware
file is named 'BCM4343A2.hcd'.

Signed-off-by: Marek Vasut <marex@nabladev.com>
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
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:

The analysis is clear. Let me write it up.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line**
- Subsystem: `Bluetooth: btbcm:`
- Action verb: "Add entry"
- Summary: Adds a device ID for BCM4343A2 UART Bluetooth chip.
Record: [Bluetooth/btbcm] [Add] [Device ID for BCM4343A2 UART module]

**Step 1.2: Tags**
- `Signed-off-by: Marek Vasut <marex@nabladev.com>` — author
- `Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>` — reviewer
- `Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>` —
  Bluetooth subsystem maintainer
- No Fixes: tag (expected — this is a device ID addition, not a bug fix
  per se)
- No Cc: stable tag (expected)
Record: Reviewed by Paul Menzel, committed by Bluetooth maintainer Luiz
von Dentz.

**Step 1.3: Commit Body**
The BCM4343A2 module is found in the muRata 1YN WiFi+BT combined device.
The required firmware file is `BCM4343A2.hcd`. Without this entry, the
driver cannot identify the chip variant and load the correct firmware.
Record: [Without this ID, users with muRata 1YN hardware cannot use
Bluetooth properly]

**Step 1.4: Hidden Bug Fix?**
Not a hidden bug fix — it's an explicit device ID addition to enable
hardware support.
Record: [Not a hidden fix — explicit hardware enablement via device ID]

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
- Files changed: 1 (`drivers/bluetooth/btbcm.c`)
- Lines added: 1
- Lines removed: 0
- Function modified: none — change is in a static data table
  (`bcm_uart_subver_table[]`)
Record: [1 file, +1 line, data table only, zero code logic change]

**Step 2.2: Code Flow**
The `bcm_uart_subver_table[]` is iterated in `btbcm_setup()` (line 618)
to match a `subver` value from the hardware against known chip names. If
a match is found, `hw_name` is set, which is then used to construct the
firmware filename (e.g., `brcm/BCM4343A2.hcd`). Without the entry, the
chip gets a generic "BCM" name and firmware loading will likely fail.
Record: [Before: BCM4343A2 not recognized → generic fallback. After:
correct name and firmware path used]

**Step 2.3: Bug Mechanism**
Category: Hardware enablement / device ID addition. This is not fixing a
code bug — it enables a previously unsupported hardware variant.
Record: [Device ID addition — enables correct firmware loading for
BCM4343A2]

**Step 2.4: Fix Quality**
Trivially correct — a single static data table entry following an
established pattern used by dozens of other entries. Zero regression
risk.
Record: [Trivially correct, zero regression risk, follows established
pattern]

## PHASE 3: GIT HISTORY

**Step 3.1: Blame**
The `bcm_uart_subver_table` was introduced in 2015 by Marcel Holtmann
(commit `9a0bb57d2d08f1`) and has been populated with additional entries
continuously ever since. The table and driver exist in all stable trees.
Record: [Table exists since 2015, present in all stable trees]

**Step 3.2: Fixes Tag**
No Fixes: tag — not applicable for device ID additions.

**Step 3.3: Related Changes**
Multiple identical-pattern commits exist: BCM4343A0 (`d456f678a074b`),
BCM43430A1 (`feb16722b5d5f`), BCM43430B0 (`27f4d1f214ae4`), BCM4373A0
(`0d37ddfc50d9a`). This commit is entirely standalone.
Record: [Standalone, follows well-established pattern of prior device ID
additions]

**Step 3.4: Author**
Marek Vasut is a well-known Linux kernel developer, primarily in
embedded/ARM. This is a straightforward hardware enablement patch from a
board vendor.
Record: [Established kernel contributor]

**Step 3.5: Dependencies**
None. The change is a single table entry addition. The data structure
and all surrounding code are unchanged.
Record: [No dependencies, standalone patch]

## PHASE 4: MAILING LIST

**Step 4.1: Discussion**
Found the original submission on patchew.org. Paul Menzel reviewed it,
asking about firmware availability. Marek pointed to the muRata firmware
repository. Paul gave `Reviewed-by`. No objections or NAKs.
Record: [Clean review, no concerns raised, Reviewed-by given]

**Step 4.2: Reviewers**
The Bluetooth maintainer (Luiz von Dentz) committed the patch. Paul
Menzel reviewed.
Record: [Committed by subsystem maintainer]

**Step 4.3-4.5:** No bug report (this is hardware enablement), no series
context needed, no stable discussion found.

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1-5.4:** The modified data is consumed by `btbcm_setup()` which
iterates the table to match a subver ID from hardware. This function is
called during Bluetooth device initialization — a standard, well-tested
code path. Adding an entry to the lookup table does not change any code
flow.
Record: [Consumed by btbcm_setup(), standard init path, no code flow
change]

**Step 5.5:** Many similar entries exist (20+ in UART table alone). This
is an established pattern.

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1:** The `bcm_uart_subver_table` has existed since 2015. The
file and table structure are present in all active stable trees.
Record: [Present in all stable trees]

**Step 6.2:** The patch applies cleanly — it's a single line insertion
into a data table. Even if surrounding entries differ slightly between
trees, this adds a new entry after the BCM4356A2 line (`0x230f`), which
has been in the table since 2017.
Record: [Clean apply expected]

**Step 6.3:** No related fix exists in stable for BCM4343A2.

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

**Step 7.1:** Bluetooth driver — IMPORTANT subsystem. Bluetooth is
widely used, and BCM chips are common in embedded/IoT platforms.
Record: [Bluetooth/driver, IMPORTANT criticality]

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1:** Users with muRata 1YN WiFi+BT hardware (BCM4343A2 chip)
are affected.
Record: [Driver-specific: users of BCM4343A2/muRata 1YN hardware]

**Step 8.2:** Triggered on every boot/device init for users with this
hardware.
Record: [Triggered on device init — blocking for affected users]

**Step 8.3:** Without this ID, the Bluetooth chip cannot be properly
identified and firmware cannot be loaded — Bluetooth is non-functional
for this hardware.
Record: [Bluetooth non-functional for affected hardware, severity
MEDIUM-HIGH]

**Step 8.4:**
- Benefit: HIGH — enables Bluetooth for specific hardware that otherwise
  doesn't work
- Risk: VERY LOW — 1 line data table addition, zero code change, follows
  established pattern
Record: [Excellent risk-benefit ratio]

## PHASE 9: FINAL SYNTHESIS

**Step 9.1: Evidence FOR backporting:**
- Classic device ID addition to existing driver (explicit exception
  category)
- 1-line change, trivially correct, zero code logic change
- Follows established pattern (20+ prior similar entries)
- Reviewed by Paul Menzel, committed by Bluetooth maintainer
- Enables real hardware (muRata 1YN) for real users
- Table exists in all stable trees since 2015

**Evidence AGAINST backporting:**
- None identified.

**Step 9.2: Stable Rules Checklist:**
1. Obviously correct and tested? YES — single static data entry
2. Fixes a real bug? YES — enables broken-without-it hardware
3. Important issue? YES for affected users (no Bluetooth at all)
4. Small and contained? YES — 1 line
5. No new features/APIs? YES — just a data table entry
6. Applies to stable? YES — table unchanged across trees

**Step 9.3: Exception Category:**
This is a **Device ID addition to an existing driver** — an explicit
exception category that is automatically YES for stable.

## Verification

- [Phase 1] Parsed tags: Reviewed-by Paul Menzel, SOB by Bluetooth
  maintainer Luiz von Dentz
- [Phase 2] Diff analysis: exactly 1 line added to static
  `bcm_uart_subver_table[]` data table
- [Phase 3] git blame: table introduced in 2015 (commit
  `9a0bb57d2d08f1`), present in all stable trees
- [Phase 3] git log for related entries: confirmed 5+ prior identical-
  pattern device ID additions
- [Phase 4] Patchew/lore: found original submission, clean review, no
  objections
- [Phase 5] Code tracing: table consumed by `btbcm_setup()` at line
  615-622, standard init path
- [Phase 6] Table structure unchanged since 2015, clean apply expected
- [Phase 8] Without entry, BCM4343A2 Bluetooth is non-functional for
  muRata 1YN users

**YES**

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

diff --git a/drivers/bluetooth/btbcm.c b/drivers/bluetooth/btbcm.c
index d33cc70eec662..975b73cd04e67 100644
--- a/drivers/bluetooth/btbcm.c
+++ b/drivers/bluetooth/btbcm.c
@@ -507,6 +507,7 @@ static const struct bcm_subver_table bcm_uart_subver_table[] = {
 	{ 0x6119, "BCM4345C0"	},	/* 003.001.025 */
 	{ 0x6606, "BCM4345C5"	},	/* 003.006.006 */
 	{ 0x230f, "BCM4356A2"	},	/* 001.003.015 */
+	{ 0x2310, "BCM4343A2"	},	/* 001.003.016 */
 	{ 0x220e, "BCM20702A1"  },	/* 001.002.014 */
 	{ 0x420d, "BCM4349B1"	},	/* 002.002.013 */
 	{ 0x420e, "BCM4349B1"	},	/* 002.002.014 */
-- 
2.53.0