From: Sasha Levin <sashal@kernel.org>
To: patches@lists.linux.dev, stable@vger.kernel.org
Cc: Gustavo Evgucci <monesss315@gmail.com>,
Paul Menzel <pmenzel@molgen.mpg.de>,
Luiz Augusto von Dentz <luiz.von.dentz@intel.com>,
Sasha Levin <sashal@kernel.org>,
marcel@holtmann.org, luiz.dentz@gmail.com,
linux-bluetooth@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH AUTOSEL 6.18] Bluetooth: btusb: Add USB ID 13d3:3625 for MediaTek MT7922
Date: Mon, 19 Oct 2026 09:50:01 -0400 [thread overview]
Message-ID: <20261019135441.1420968-310-sashal@kernel.org> (raw)
In-Reply-To: <20261019135441.1420968-1-sashal@kernel.org>
From: Gustavo Evgucci <monesss315@gmail.com>
[ Upstream commit 849a3bf1489093996859ba0c3c1c0cd314d6ff96 ]
The IMC Networks MT7922 Bluetooth adapter with USB ID 13d3:3625 is not
recognized as a MediaTek device because it is missing from the btusb
device ID table. As a result, btmtk firmware loading is never triggered
and the HCI reset command times out with -ETIMEDOUT.
Add the device with BTUSB_MEDIATEK | BTUSB_WIDEBAND_SPEECH flags,
consistent with the neighboring 13d3:3627, 13d3:3628 and 13d3:3630
entries which use the same chip.
Tested on: MediaTek MT7922 (Wi-Fi 6E combo card, IMC Networks BT USB
interface), kernel 7.0.11-arch1-1.
/sys/kernel/debug/usb/devices:
T: Bus=01 Lev=01 Prnt=01 Port=12 Cnt=03 Dev#= 4 Spd=480 MxCh= 0
D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=13d3 ProdID=3625 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: Gustavo Evgucci <monesss315@gmail.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:
This is a two-line USB ID addition for an existing MediaTek btusb path.
The local tree is **6.18.53** (`pending-6.18`); `13d3:3625` is missing
here, while neighboring MediaTek IDs and `BTUSB_MEDIATEK` setup already
exist.
===============================================================
PHASE 1: COMMIT MESSAGE FORENSICS
===============================================================
**Step 1.1: PARSE THE SUBJECT LINE**
Record: [Bluetooth / btusb] [Add] [USB ID 13d3:3625 for MediaTek MT7922]
- Subsystem: Bluetooth USB driver (`btusb`)
- Action verb: **Add** (device ID to an existing driver)
- Claimed intent: enable an IMC Networks / MediaTek MT7922 adapter that
is already bound by generic Bluetooth USB matching but is not treated
as MediaTek
**Step 1.2: PARSE ALL COMMIT MESSAGE TAGS**
Record:
- **Fixes:** none (expected)
- **Reported-by:** none
- **Tested-by:** none as a tag; body says tested on kernel
7.0.11-arch1-1
- **Reviewed-by:** Paul Menzel `<pmenzel@molgen.mpg.de>`
- **Acked-by:** none
- **Link:** none in the commit message
- **Cc: stable:** none (expected)
- **Signed-off-by:** Gustavo Evgucci `<monesss315@gmail.com>` (author);
Luiz Augusto von Dentz `<luiz.von.dentz@intel.com>` (Bluetooth
maintainer)
- Ignore: any pipeline “Upstream commit …” / Sasha Levin SOB if present
Notable: maintainer SOB plus an independent Reviewed-by. Bluetooth CI
(bluez.test.bot) ran on v1 and v2.
**Step 1.3: ANALYZE THE COMMIT BODY TEXT**
Record:
- **Bug:** USB ID `13d3:3625` is missing from the btusb ID/quirks table,
so the adapter is not flagged `BTUSB_MEDIATEK`.
- **Symptom:** MediaTek firmware load (`btmtk`) never runs; HCI reset
times out with `-ETIMEDOUT` (`Opcode 0x0c03 failed: -110` in user
reports).
- **Root cause:** generic Bluetooth class match binds `btusb` with
`driver_info == 0`; MediaTek setup is skipped.
- **Fix:** add `{ USB_DEVICE(0x13d3, 0x3625), .driver_info =
BTUSB_MEDIATEK | BTUSB_WIDEBAND_SPEECH }` next to
`13d3:3627/3628/3630`.
- **Version info:** tested on 7.0.11-arch1-1;
`/sys/kernel/debug/usb/devices` dump included (vendor 13d3, product
3625, Manufacturer=MediaTek Inc., class e0/01/01, Driver=btusb).
**Step 1.4: DETECT HIDDEN BUG FIXES**
Record: Not a disguised cleanup. It is an explicit hardware ID addition.
That is a documented stable exception: new device IDs on an existing
driver. It also fixes a real functional failure (HCI timeout, adapter
unusable).
===============================================================
PHASE 2: DIFF ANALYSIS - LINE BY LINE
===============================================================
**Step 2.1: INVENTORY THE CHANGES**
Record:
- File: `drivers/bluetooth/btusb.c` only
- Scope: **+2 lines** in `quirks_table[]` (single-file surgical ID add)
- Functions: none; static `usb_device_id` table only
- Classification: single-file device ID addition
**Step 2.2: UNDERSTAND THE CODE FLOW CHANGE**
Record:
- **Before:** `13d3:3625` is absent from `quirks_table`. Probe matches
generic `{ USB_DEVICE_INFO(0xe0, 0x01, 0x01) }` in `btusb_table` with
empty `driver_info`. `btusb_probe()` only consults `quirks_table` when
`!id->driver_info` (lines 4064–4069). No MediaTek match →
`hdev->setup` is not set to `btusb_mtk_setup`.
- **After:** `usb_match_id(intf, quirks_table)` hits the new entry.
`id->driver_info & BTUSB_MEDIATEK` is true, so probe sets `hdev->setup
= btusb_mtk_setup` and related MTK callbacks (lines 4244–4258).
`BTUSB_WIDEBAND_SPEECH` sets `HCI_QUIRK_WIDEBAND_SPEECH_SUPPORTED`
(lines 4344–4345).
- Path affected: probe/init of this USB ID only.
**Step 2.3: IDENTIFY THE BUG MECHANISM**
Record: **Hardware workaround / device ID addition (category h)**
- Broken: MediaTek combo card enumerates as generic Bluetooth USB;
firmware is never loaded; HCI reset times out.
- Fix: same flags as neighboring IMC/MediaTek entries already in this
tree.
**Step 2.4: ASSESS THE FIX QUALITY**
Record:
- Obviously correct: two-line table entry matching established pattern.
- Minimal; no unrelated edits; no API/locking/data-structure change.
- Regression risk: **very low**, scoped to VID/PID 13d3:3625. Wrong
flags would only affect that device; flags match 3627/3628/3630.
- Chip naming is slightly inconsistent in history (3627 subject says
MT7925, body says MT7922); **flags are the same**, so the driver path
is identical.
===============================================================
PHASE 3: GIT HISTORY INVESTIGATION
===============================================================
**Step 3.1: BLAME THE CHANGED LINES**
Record:
- Insertion sits between `13d3:3613` (Youn Mélois, 2025-04-01,
`bbf56029322c06`) and `13d3:3627` (Chris Lu, 2025-09-04,
`576952cf981b7`).
- This is not a regression in old code; it is a **missing ID** for
hardware that uses the long-standing MediaTek path.
- MT7922 USB support: `8c0401b7308cb` (“Bluetooth: Add support for
MediaTek MT7922 device”), contained in v6.11-rc1 era. Present in this
6.18 tree.
**Step 3.2: FOLLOW THE FIXES: TAG**
Record: No `Fixes:` tag. Not applicable. The “bug” is omission of this
VID/PID, not a later regression.
**Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES**
Record:
- This tree already has many of the same class of commits, including:
- `576952cf981b7` 13d3/3627
- `f63f401130e5c` 13d3/3628
- `5bd5c716f7ec3` 13d3/3630
- `70cd38d22d465` 13d3/3633 for MT7922
- Candidate `ddd25808d4c2` is **not** an ancestor of HEAD (`git merge-
base --is-ancestor` exit 1).
- Standalone; not patch X/Y.
**Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS**
Record: `git log --author="Gustavo Evgucci" -- drivers/bluetooth/` is
empty in this tree. Author is a first-time hardware-ID contributor, not
the subsystem maintainer. Weight comes from Luiz’s merge and Paul
Menzel’s Reviewed-by.
**Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS**
Record:
- Needs `quirks_table`, `BTUSB_MEDIATEK`, `BTUSB_WIDEBAND_SPEECH`, and
`btusb_mtk_setup`. All exist here.
- `CONFIG_BT_HCIBTUSB_MTK` exists (`drivers/bluetooth/Kconfig`).
- No extra commits required.
- Can apply standalone. Parent of `ddd25808d4c2` also has `13d3:3609`,
which this 6.18 tree lacks; that is **context only**. Insertion
between 3613 and 3627 is valid here.
===============================================================
PHASE 4: MAILING LIST AND EXTERNAL RESEARCH
===============================================================
**Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION**
Record:
- `b4 dig -c ddd25808d4c2` matched patch-id
`ce1685f940593b167015292f6b73b7f2fc9ec8d9`
- Lore/msgid:
https://patch.msgid.link/20260625083230.300651-1-monesss315@gmail.com
- Thread saved to `/tmp/btusb-3625.mbox` (7 messages)
- **v1** (2026-06-23): `[PATCH] Bluetooth: btusb: Add IMC Networks
MT7922 device 0x13d3:0x3625`
- **v2** (2026-06-25): added usb/devices dump, Reviewed-by, full
maintainer To/Cc. **Code hunk unchanged.**
- Applied to bluetooth-next as `ddd25808d4c2` by Luiz (patchwork-bot,
2026-06-26).
- Review: Paul Menzel asked for usb/devices dump and get_maintainer.pl
recipients; then Reviewed-by. **No NAK.**
- Bluetooth CI: v1 all PASS; v2 GitLint FAIL only for an 82-char notes
line. Builds passed.
- No reviewer asked for `Cc: stable`.
**Step 4.2: CHECK WHO REVIEWED THE PATCH**
Record (`b4 dig -w`):
- Gustavo Evgucci (author)
- Luiz Augusto von Dentz (Bluetooth driver maintainer)
- Marcel Holtmann (Bluetooth maintainer)
- linux-bluetooth@, linux-kernel@
- Paul Menzel (reviewer)
Appropriate maintainers were on the thread; Luiz applied it.
**Step 4.3: SEARCH FOR THE BUG REPORT**
Record:
- User-tested on real hardware with a full usb/devices dump.
- External confirmation: DKMS workarounds for Mercusys MA80XE / IMC
Networks `13d3:3625` (`hci0: Opcode 0x0c03 failed: -110`). That
matches the commit’s -ETIMEDOUT description.
- Not syzbot; hardware enablement with a concrete timeout.
**Step 4.4: CHECK FOR RELATED PATCHES AND SERIES**
Record: Single-patch series (v1 → v2 documentation only). Neighboring
IDs already in this tree.
**Step 4.5: CHECK STABLE MAILING LIST HISTORY**
Record: No useful stable@ thread found (lore.kernel.org/stable WebFetch
blocked by anti-bot). Absence of prior stable discussion is not a
negative signal for a device-ID add.
===============================================================
PHASE 5: CODE SEMANTIC ANALYSIS
===============================================================
semcode MCP: not available. Used grep/read.
**Step 5.1: IDENTIFY KEY FUNCTIONS IN THE DIFF**
Record: No functions modified. Data: `quirks_table[]`. Consumers:
`btusb_probe()`.
**Step 5.2: TRACE CALLERS**
Record:
- `btusb_probe()` ← USB core when `btusb` matches.
- Generic match: `btusb_table` `{ USB_DEVICE_INFO(0xe0, 0x01, 0x01) }`
(line 83), which matches this device’s If#0 Cls=e0 Sub=01 Prot=01.
- Then `usb_match_id(intf, quirks_table)` when `driver_info` is 0.
**Step 5.3: TRACE CALLEES**
Record: With the new flags, probe assigns `btusb_mtk_setup`,
`btusb_mtk_shutdown`, `btmtk_reset_sync`, `btmtk_set_bdaddr`,
`btusb_send_frame_mtk`, USB suspend/resume/disconnect MTK hooks.
**Step 5.4: FOLLOW THE CALL CHAIN**
Record: Userspace-reachable: plug in / boot with the adapter.
Unprivileged users do not need a special syscall; udev/bluetoothd open
the HCI device. High priority for owners of this card. Not a universal
path.
**Step 5.5: SEARCH FOR SIMILAR PATTERNS**
Record: Dozens of `USB_DEVICE(0x13d3, …) … BTUSB_MEDIATEK |
BTUSB_WIDEBAND_SPEECH` entries. Same pattern as 3627/3628/3630 already
in this file. Systematic missing-ID class, not a one-off logic bug.
===============================================================
PHASE 6: CROSS-REFERENCING AGAINST THE LOCAL TREE
===============================================================
**Step 6.1: DOES THE BUGGY CODE EXIST IN THIS TREE?**
Record:
- Local tree: `git describe HEAD` → `p-6.18-1-g03b85e06ca9bf`; `make
kernelversion` → **6.18.53**; branch `pending-6.18`.
- `13d3:3625` is **not** in `drivers/bluetooth/btusb.c` (`rg` found only
unrelated Realtek `0x3625:0x010b`).
- `quirks_table` MediaTek block **is** here, with 3613 then 3627 (lines
787–794).
- Neighbor commits 3627/3628/3630 **are** ancestors of HEAD.
- Candidate `ddd25808d4c2` is **not** an ancestor of HEAD.
- Driver support for MT7922 has been in this lineage since ~v6.11
(`8c0401b7308cb`).
**Step 6.2: CHECK FOR BACKPORT COMPLICATIONS**
Record: **Clean / minor context fuzz.** Candidate parent has extra
`13d3:3609` above 3613; 6.18 does not. Added lines themselves match. No
refactor of `quirks_table` vs probe matching.
**Step 6.3: CHECK IF RELATED FIXES ARE ALREADY HERE**
Record: No other 13d3:3625 MediaTek entry. `d9da920233ec8` is Realtek
`3625:010b` (different vendor). Not a duplicate.
===============================================================
PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT
===============================================================
**Step 7.1: IDENTIFY THE SUBSYSTEM AND ITS CRITICALITY**
Record: [drivers/bluetooth/btusb.c] [IMPORTANT]
- Common USB Bluetooth driver, not core mm/fs.
- MediaTek Wi-Fi 6E combo cards are widely used (laptops, USB adapters).
Device-specific, but the class of fix is standard for stable.
**Step 7.2: ASSESS SUBSYSTEM ACTIVITY**
Record: Active. Recent 6.18 history includes many VID/PID adds and btusb
bugfixes. ID table is the normal place for this change.
===============================================================
PHASE 8: IMPACT AND RISK ASSESSMENT
===============================================================
**Step 8.1: DETERMINE WHO IS AFFECTED**
Record: Users of USB Bluetooth `13d3:3625` (IMC Networks / MediaTek
MT7922, e.g. combo cards / Mercusys MA80XE). Others unchanged. Requires
`CONFIG_BT_HCIBTUSB` and typically `CONFIG_BT_HCIBTUSB_MTK`.
**Step 8.2: DETERMINE THE TRIGGER CONDITIONS**
Record: Every probe of this device (boot or plug-in). Not a race. Not
unprivileged exploit; the device simply does not work. Reproduced by the
author and by out-of-tree DKMS users.
**Step 8.3: DETERMINE THE FAILURE MODE SEVERITY**
Record: [Bluetooth adapter fails HCI reset / -ETIMEDOUT; no controller]
[HIGH for affected hardware, LOW globally]
- Not a panic/UAF, but the device is dead without the ID. That is the
usual severity for missing USB IDs.
**Step 8.4: CALCULATE RISK-BENEFIT RATIO**
Record:
- **Benefit:** High for holders of this adapter on 6.18; zero for
everyone else.
- **Risk:** Very low (2 lines, existing flags, existing probe path).
- **Ratio:** Strongly favors backport. This is the textbook new-device-
ID exception.
===============================================================
PHASE 9: FINAL SYNTHESIS
===============================================================
**Step 9.1: COMPILE THE EVIDENCE**
FOR:
- Explicit stable exception: new USB ID on an existing driver
- Real user-visible bug: HCI reset -ETIMEDOUT, adapter unusable
- 2-line, obviously correct, same flags as 3627/3628/3630 already in
this tree
- MTK setup path (`btusb_mtk_setup`) present
- Reviewed-by Paul Menzel; merged by Luiz von Dentz; CI built
- Author tested on hardware; usb/devices dump matches
- Independent DKMS users hit the same ID/symptom
- Applies with at most minor context adjustment (missing 3609)
AGAINST:
- Not a crash/security/corruption bug (hardware enablement)
- Author is not a regular Bluetooth contributor
- Chip labeled MT7922 vs some neighbor commits saying MT7925 (flags
still match)
- No Cc: stable (not a negative under these rules)
UNRESOLVED:
- lore.kernel.org HTTP 403 for WebFetch; thread recovered via `b4 dig
-m`
- No stable@ discussion found (search not useful)
**Step 9.2: APPLY THE STABLE RULES CHECKLIST**
1. Obviously correct and tested? **PASS** — 2-line ID; hardware test;
reviewer + maintainer
2. Fixes a real bug that affects users? **PASS** — missing ID → firmware
never loads → HCI timeout
3. Important issue? **PASS** under the device-ID exception; adapter
otherwise unusable
4. Small and contained? **PASS** — +2 lines, one table
5. No new features or APIs? **PASS** — ID only; no new driver/API
6. Can apply to the local tree? **PASS** — insertion point 3613/3627
exists; 3625 absent
**Step 9.3: CHECK FOR EXCEPTION CATEGORIES**
Record: **Device ID addition to existing driver** — automatic YES
category.
**Step 9.4: MAKE YOUR DECISION**
Backport to this 6.18 tree. The bug exists here, the MediaTek path
exists here, neighboring IDs exist here, and the change is a two-line
USB ID with the established flags.
---
**What the commit solves for this tree**
On 6.18.53, `13d3:3625` still matches only the generic Bluetooth USB
class, so `btusb_probe()` never sets `BTUSB_MEDIATEK` and never calls
`btusb_mtk_setup`. HCI reset then times out. Adding the quirks_table
entry with `BTUSB_MEDIATEK | BTUSB_WIDEBAND_SPEECH` is the same
enablement already used for 3627/3628/3630 in this file.
**Risk vs benefit**
Benefit is making this MediaTek/IMC adapter work; risk is confined to
that VID/PID. No locking, no API, no refactor.
**Concerns**
Parent context includes `13d3:3609`, which 6.18 does not have. Insert
between existing 3613 and 3627. No other prerequisites.
Verification:
- [Phase 1] Parsed subject/tags/body from `git show -s ddd25808d4c2` and
the supplied message: Add USB ID; Reviewed-by Paul Menzel; SOB Luiz;
no Fixes/Cc stable
- [Phase 2] Diff: +2 lines in `quirks_table`; confirmed `btusb_probe`
uses that table when `!id->driver_info` (btusb.c:4064–4069); MTK setup
at 4244–4258; WBS quirk at 4344–4345
- [Phase 2] Generic match `USB_DEVICE_INFO(0xe0, 0x01, 0x01)` at line 83
matches the dumped interface class
- [Phase 3] `git describe HEAD` / `make kernelversion`: p-6.18-1 /
6.18.53
- [Phase 3] `git merge-base --is-ancestor ddd25808d4c2 HEAD` → not
ancestor; 3627/3628/3630 commits are ancestors
- [Phase 3] `rg 0x3625 drivers/bluetooth/btusb.c`: no 13d3:3625; only
Realtek 3625:010b
- [Phase 3] blame 785–796: 3613/3627/3628/3630 present as described
- [Phase 3] MT7922 intro `8c0401b7308cb` contained around v6.11-rc1;
present in this tree
- [Phase 3] author log empty in drivers/bluetooth/
- [Phase 4] `b4 dig -c ddd25808d4c2` → msgid 20260625083230.300651-1;
v1+v2; applied as ddd25808d4c2
- [Phase 4] `b4 dig -a`: v1 then v2 (docs only); `b4 dig -w`: Luiz,
Marcel, linux-bluetooth, Paul Menzel
- [Phase 4] mbox: Paul Reviewed-by; CI pass (v2 gitlint notes-line
only); no NAK
- [Phase 4] lore WebFetch 403; used b4 mbox instead. Stable list search:
no relevant hit
- [Phase 5] semcode unavailable; callers via grep: quirks_table →
btusb_probe only
- [Phase 6] 3613 and 3627 present, 3625 absent — insertion point
verified in this checkout
- [Phase 8] Failure mode: HCI -ETIMEDOUT / no controller for this USB
ID; not a kernel oops
- UNVERIFIED: live lore.kernel.org HTML of the thread (403); chip MT7922
vs MT7925 labeling of neighbors (flags verified identical)
**YES**
drivers/bluetooth/btusb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 59fff918fd2de..9257341b01399 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -788,6 +788,8 @@ static const struct usb_device_id quirks_table[] = {
BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x13d3, 0x3613), .driver_info = BTUSB_MEDIATEK |
BTUSB_WIDEBAND_SPEECH },
+ { USB_DEVICE(0x13d3, 0x3625), .driver_info = BTUSB_MEDIATEK |
+ BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x13d3, 0x3627), .driver_info = BTUSB_MEDIATEK |
BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x13d3, 0x3628), .driver_info = BTUSB_MEDIATEK |
--
2.53.0
next prev parent reply other threads:[~2026-10-19 14:02 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20261019135441.1420968-1-sashal@kernel.org>
2026-10-19 13:45 ` [PATCH AUTOSEL 6.18-6.1] Bluetooth: hci_event: fix out-of-bounds read in LE PA report reassembly Sasha Levin
2026-10-19 13:45 ` [PATCH AUTOSEL 6.18-5.10] Bluetooth: btrsi: Move set_bt_context after successful HCI registration Sasha Levin
2026-10-19 13:47 ` [PATCH AUTOSEL 6.18] Bluetooth: bfusb: validate received block boundaries Sasha Levin
2026-10-19 13:48 ` [PATCH AUTOSEL 6.18-5.15] Bluetooth: btusb: Add support for 1357:c123 Realtek 8852BE device Sasha Levin
2026-10-19 13:48 ` [PATCH AUTOSEL 6.18-5.10] Bluetooth: hci_bcsp: validate received packet lengths Sasha Levin
2026-10-19 13:48 ` [PATCH AUTOSEL 6.18-5.10] Bluetooth: hci_nokia: validate firmware packet bounds Sasha Levin
2026-10-19 13:50 ` Sasha Levin [this message]
2026-10-19 13:50 ` [PATCH AUTOSEL 6.18-6.1] Bluetooth: hci_sync: Disable legacy instance's ext adv before setup snapshot Sasha Levin
2026-10-19 13:51 ` [PATCH AUTOSEL 6.18] Bluetooth: btnxpuart: Fix use-after-free in probe error path Sasha Levin
2026-10-19 13:52 ` [PATCH AUTOSEL 6.18] Bluetooth: fix BT dependency for submodules Sasha Levin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261019135441.1420968-310-sashal@kernel.org \
--to=sashal@kernel.org \
--cc=linux-bluetooth@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luiz.dentz@gmail.com \
--cc=luiz.von.dentz@intel.com \
--cc=marcel@holtmann.org \
--cc=monesss315@gmail.com \
--cc=patches@lists.linux.dev \
--cc=pmenzel@molgen.mpg.de \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox