New knobs should default to 'n'. The mentioned one depends on
BT_HCIBTUSB, but the latter is enabled on most systems.
Acked-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Move USB ID 0x0043 next to 0x0040 to keep the Intel entries in
numerical order, and annotate it as Otter Peak 2 (AX231) used on
Wildcat Lake.
Fixes: 69bf0c2b34 ("Bluetooth: btusb: Add support for Intel Otter Peak2 (OrP2)")
Signed-off-by: Catherine L <catherine.l@intel.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Add support for MT7928 (internal device ID is MT7935) which requires
additional firmware (CBMCU firmware) loading before Bluetooth firmware.
CBMCU is a new component on MT7928 to handle common part shared across
the combo chip, providing a better user experience through improved
coordination between subsystems.
Implement two-phase CBMCU firmware download: Phase 1 loads section with
type 0x5 containing global descriptor, section maps and signature data;
Phase 2 loads remaining firmware sections. The firmware is rejected if it
has no Phase 1 section.
The CBMCU is shared with the Wi-Fi driver, which may download the same
firmware concurrently, so the firmware reports a status per section and
hands each one to a single driver. This driver downloads a section the
firmware reports as not downloaded, waits while the other driver holds
it, and leaves alone one the firmware already has. This is the scheme
btmtk_setup_firmware_79xx() already uses for the ROM patch shared with
Wi-Fi, so no host side lock is needed.
The driver then continues to load the corresponding BT firmware based on
device ID through fallthrough to case 0x7922/0x7925. A CBMCU failure is
only warned about and does not abort the setup, because the Wi-Fi driver
may finish the same download on its own. A CBMCU left unusable makes the
BT firmware download fail instead, which triggers the existing one-shot
btmtk_reset_sync() recovery.
The CBMCU firmware layout and section-map bounds are validated by
reusing btmtk_fw_validate_layout() and btmtk_fw_validate_section(),
the same helpers btmtk_setup_firmware_79xx() uses, instead of
duplicating the overflow checks.
Add the MT7928 (0x7935) case to btmtk_usb_subsys_reset(), which triggers
the subsystem reset by setting BIT(31) of MTK_BT_RESET_REG_CONNV3.
MT7928 bring-up kernel log:
[ 6931.197167] usb 1-3: New USB device found, idVendor=0e8d, idProduct=7935, bcdDevice= 1.00
[ 6931.197212] usb 1-3: New USB device strings: Mfr=5, Product=6, SerialNumber=7
[ 6931.197237] usb 1-3: Product: Wireless_Device
[ 6931.197258] usb 1-3: Manufacturer: MediaTek Inc.
[ 6931.197279] usb 1-3: SerialNumber: 000000000
[ 6931.213478] Bluetooth: hci1: Loading CBMCU firmware: mediatek/mt7928/CBMCU_CODE_MT7935_1_1.bin
[ 6931.215214] Bluetooth: hci1: CBMCU HW ver: 0x7935, SW ver: 0x0000, Build Time: 20260601T161751+
[ 6931.623962] Bluetooth: hci1: CBMCU firmware download completed
[ 6931.643916] Bluetooth: hci1: Loading BT firmware: mediatek/mt7928/BT_RAM_CODE_MT7935_1_1_hdr.bin
[ 6931.650467] Bluetooth: hci1: BT HW ver: 0x7935, SW ver: 0x0000, Build Time: 20260527000816
[ 6935.039790] Bluetooth: hci1: Device setup in 3369644 usecs
[ 6935.039833] Bluetooth: hci1: HCI Enhanced Setup Synchronous Connection command is advertised, but not supported.
[ 6935.160654] Bluetooth: hci1: AOSP extensions version v2.00
[ 6935.160710] Bluetooth: hci1: AOSP quality report is supported
[ 6935.162954] Bluetooth: MGMT ver 1.23
Signed-off-by: Chris Lu <chris.lu@mediatek.com>
Assisted-by: LLM
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
When an unsigned operational firmware image is needed for debug, the
controller requires intel/unlocker.sfi to be loaded first. Without the
unlocker image, the controller rejects the unsigned operational firmware.
Support both firmware download flows based on the unlock policy advertised
in the version TLV:
BlazarI/BlazarIW/BlazarU/Gale Peak (unlock_policy == 0):
Boot ROM -> unlocker.sfi -> IML -> OPFW
Scorpius Peak onwards (unlock_policy == 1):
Boot ROM -> IML -> unlocker.sfi -> OPFW
Parse the new INTEL_TLV_UNLOCK_POLICY and INTEL_TLV_PLATFORM_ID TLVs
into struct intel_version_tlv, track the pending unlocker load through
a new btintel_data::unlocker flag, and pick intel/unlocker.sfi as the
firmware filename when that flag is set. If the unlocker image is not
present in the firmware search path, the driver silently falls through
to the normal firmware download path. If the unlocker image is present
but fails to download to the controller, the driver logs the error and
aborts bootloader setup, since continuing would leave the controller in
an inconsistent state.
[ 413.375247] Bluetooth: hci0: Found device firmware: intel/unlocker.sfi
[ 413.501051] Bluetooth: hci0: Waiting for firmware download to complete
[ 413.501058] Bluetooth: hci0: Firmware loaded in 122864 usecs
[ 413.501537] Bluetooth: hci0: Found device firmware: intel/ibt-02a2-01a1.sfi
[ 413.501547] Bluetooth: hci0: Boot Address: 0x10001000
[ 413.501548] Bluetooth: hci0: Firmware Version: 137-39.26
[ 414.103473] Bluetooth: hci0: Waiting for firmware download to complete
[ 414.103478] Bluetooth: hci0: Firmware loaded in 587841 usecs
[ 414.149576] Bluetooth: hci0: Applying Intel DDC parameters completed
[ 414.150089] Bluetooth: hci0: Firmware timestamp 2026.39 buildtype 3 build 86921
[ 414.150092] Bluetooth: hci0: Firmware SHA1: 0xeb2e0a4b
[ 414.150093] Bluetooth: hci0: Platform ID: 570c6ffbcbe6
[ 414.150094] Bluetooth: hci0: Fseq status: Success (0x00)
[ 414.150730] Bluetooth: hci0: Fseq executed: 15.255.00.98
[ 414.150734] Bluetooth: hci0: Fseq BT Top: 06.32.00.02
Assisted-by: Copilot:Claude Opus 4.7
Signed-off-by: Ravindra <ravindra@intel.com>
Signed-off-by: Kiran K <kiran.k@intel.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Firmware may omit optional TLVs, leaving their corresponding fields
unset in the caller-supplied struct intel_version_tlv. Since the
structure is typically stack-allocated and not cleared beforehand,
fields for which no TLV is received retain uninitialized stack
memory. This stale data can be logged via btintel_version_info_tlv()
and copied back to the caller, leaking kernel stack contents.
Clear the structure in btintel_read_version_tlv() before parsing so
that fields with no corresponding TLV are deterministically zero
instead of containing garbage.
Fixes: 57375beef7 ("Bluetooth: btintel: Add infrastructure to read controller information")
Signed-off-by: Kiran K <kiran.k@intel.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
An open debugfs file retains its file_operations pointer in the
debugfs proxy state. However, force_suspend_fops, force_wakeup_fops,
aosp_capable_fops, and force_devcoredump_fops have no .owner set to
THIS_MODULE. As a result, full_proxy_open_regular() calls fops_get()
which succeeds without taking a reference to the hci_vhci module.
When userspace opens any of these debugfs files and later closes
the /dev/vhci file descriptor (triggering vhci_release() and
debugfs file removal), the open debugfs file descriptor remains valid
in userspace. Because the module refcount was not incremented,
the hci_vhci module can be unloaded via delete_module (rmmod hci_vhci).
When the userspace process subsequently closes the debugfs file
descriptor, full_proxy_release() accesses the already unmapped
file_operations structure, resulting in a kernel page fault / oops:
BUG: unable to handle page fault for address: fffffbfff846f18b
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
Oops: Oops: 0000 [#1] SMP KASAN NOPTI
RIP: 0010:full_proxy_release+0x8e/0x140
Call Trace:
<TASK>
__fput+0x39f/0xa60
fput_close_sync+0xff/0x200
__x64_sys_close+0x8c/0xf0
do_syscall_64+0xc3/0x590
entry_SYSCALL_64_after_hwframe+0x76/0x7e
</TASK>
Modules linked in: ... [last unloaded: hci_vhci(E)]
The issue was discovered via manual code audit of
drivers/bluetooth/hci_vhci.c and verified on a Linux 7.3-rc6 test VM
with CONFIG_BT_VHCI=m by keeping a debugfs file open across controller
teardown and module unload.
Set .owner = THIS_MODULE on all four file_operations structures so that
debugfs pins the module until all file descriptors are closed.
Fixes: 2801079119 ("Bluetooth: vhci: Prevent use-after-free by removing debugfs files early")
Cc: stable@vger.kernel.org
Signed-off-by: Bui Viet Dung <dungvn2345@gmail.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
btmtk_isopkt_pad() uses skb_pad(), which frees the skb on failure.
The error is propagated by alloc_mtk_intr_urb() and
btusb_send_frame_mtk() up to hci_send_frame(), which frees
the skb a second time:
err = hdev->send(hdev, skb);
if (err < 0) {
bt_dev_err(hdev, "sending frame failed (%d)", err);
kfree_skb(skb);
return err;
}
Use __skb_put_padto(skb, MTK_ISO_THRESHOLD, false) so that the skb
is left to the caller on error. This also replaces the open-coded
skb_pad() + __skb_put() sequence.
Fixes: ceac1cb025 ("Bluetooth: btusb: mediatek: add ISO data transmission functions")
Signed-off-by: Eric Dumazet <edumazet@kernel.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
bt_dev_err_ratelimited() and bt_dev_warn_ratelimited() pass the format
string to bt_err_ratelimited()/bt_warn_ratelimited() without appending
a newline, unlike bt_dev_err() and bt_dev_warn(), which go through
BT_ERR()/BT_WARN() and add one. Only 2 of the 22 in-tree callers (both
in virtio_bt) put the newline in their own format string.
A printk record without a trailing newline is stored with prb_commit()
instead of prb_final_commit(), and readers of the log buffer (/dev/kmsg,
syslog) do not see it until it is finalized, which only happens when the
next record is reserved. These messages therefore stay invisible until
some unrelated message is printed, and journald, which timestamps a
record when it reads it, logs them with the time of that later message.
This was observed with a MediaTek MT7921 controller (USB 04ca:3802):
when an eSCO link is closed, the host still receives a few SCO packets
for the handle after Disconnection Complete, so hci_scodata_packet()
logs "SCO packet for unknown connection handle". Comparing the record's
kernel timestamp (_SOURCE_MONOTONIC_TIMESTAMP) with the time journald
received it, over one capture:
emitted logged delay
15:36:52.896 15:37:00.214 7.3 s
15:37:03.410 15:39:05.574 122.2 s
15:39:05.574 15:39:12.506 6.9 s
15:39:19.791 15:40:54.109 94.3 s
15:41:22.021 15:41:24.647 2.6 s
Each message showed up together with the next kernel message; the 94 s
one looked as if it had been logged in the middle of a later, healthy
eSCO connection.
bt_dev_err_ratelimited() lost its newline in commit 657cc64647
("Bluetooth: Remove usage of BT_ERR_RATELIMITED macro"), which replaced
BT_ERR_RATELIMITED(), the variant that appended "\n", with a direct call
to bt_err_ratelimited(). bt_dev_warn_ratelimited() never had one.
Append the newline in both macros, as BT_ERR() and BT_WARN() do, and
drop it from the two virtio_bt format strings so that their messages do
not gain an empty line.
Fixes: 36278a5d4d ("Bluetooth: Adding a bt_dev_warn_ratelimited macro.")
Fixes: 657cc64647 ("Bluetooth: Remove usage of BT_ERR_RATELIMITED macro")
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Hitalo Souza <enghitalo@gmail.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
The Bluetooth controller with USB ID 0b05:1825 found on ASUS
systems uses a Qualcomm QCA Rome chipset, but is currently matched
only by the generic Bluetooth USB entry.
Without BTUSB_QCA_ROME, the driver does not load the QCA rampatch and
NVM firmware. BLE scanning also repeatedly reports:
Bluetooth: hci0: unexpected event for opcode 0x2005
Mark the device as BTUSB_QCA_ROME with wideband speech support, in
line with the other QCA Rome USB IDs.
Similar issue but with different device id. After patching bluetooth is
working fine, no unexpected events in log.
Link: https://lore.kernel.org/linux-bluetooth/20260928143655.22223-1-qstrydom0@gmail.com
Tested-on: Qualcomm Atheros QCA6174 SoC integrated in motherboard
ASUS Z170I PRO GAMING, USB device id: 0b05:1825
Signed-off-by: Konstantin Nazarov <qwertyuiopyyy@gmail.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This patch adds the device ID for the bluetooth chip used in the
Nvidia specific Broadcom BCM4356 PCI-E WiFi / UART BT chip.
Startup log:
Bluetooth: hci0: BCM: chip id 122
Bluetooth: hci0: BCM: features 0x0f
Bluetooth: hci0: BCM4356A3
Bluetooth: hci0: BCM4356A3 (001.004.009) build 0000
Bluetooth: hci0: BCM4356A3 'brcm/BCM4356A3.nvidia,p2894-2551-b00.hcd' Patch
Bluetooth: hci0: BCM: features 0x0f
Bluetooth: hci0: BCM4356A3 37.4MHz Class 1.5 Nvidia mDarcy-0108
Bluetooth: hci0: BCM4356A3 (001.004.009) build 0109
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Commit 5ead206361 ("Bluetooth: btrtl: fix RTL8761B/BU broken LE
extended scan") set HCI_QUIRK_BROKEN_EXT_SCAN on every RTL8761B, and
commit ca0583c246 ("Bluetooth: btusb: limit RTL8761B BROKEN_EXT_SCAN
quirk to 0bda:a728") kept it on 0bda:a728 on the assumption that the
USB id separates dongles with broken extended scan from those with a
broken legacy scan path. It does not. An 0bda:a728 unit (RTL8761BUV,
fw 0xdfc6d922) on 6.18.51 fails the same way the UB500 and 0bda:8771
did: LE Set Scan Enable (0x200c) times out with -110 and btusb resets
the device. With the flag removed from the table entry, scanning works
on that unit.
Two dongles with the same USB id need opposite settings, so the device
table cannot key the quirk either. The costs are not symmetric. Without
the quirk, the unit it was written for gets -EBUSY on LE Set Extended
Scan Enable (0x2042) while a connection is up. With it, 0x200c times
out and btusb resets the device on three reported units, two of them in
a re-enumeration loop.
Remove the flag and the table entry. 0bda:a728 matches the generic
Realtek entry again and runs without the quirk, as before v7.2.
Reported-by: Andy Tsvetinskiy <andrew.tsvetinskiy@gmail.com>
Closes: https://lore.kernel.org/all/CAE4bxw+ofDFVx0aTHqCrzns9oP1CRQDm_wzeyHPeMBYOhSpcuA@mail.gmail.com/
Fixes: 5ead206361 ("Bluetooth: btrtl: fix RTL8761B/BU broken LE extended scan")
Fixes: ca0583c246 ("Bluetooth: btusb: limit RTL8761B BROKEN_EXT_SCAN quirk to 0bda:a728")
Cc: stable@vger.kernel.org
Signed-off-by: Junjie Cao <junjie.cao@intel.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
When force_poll_sync is enabled, commit 800fe5ec30 ("Bluetooth:
btusb: Add support for queuing during polling interval") defers ACL
delivery to the RX worker. The event path currently wakes that worker
before delivering the event, so queued ACL data can reach HCI first.
Deliver the event before waking the worker. This preserves the intended
event-first ordering and the event callback's return value.
Fixes: 800fe5ec30 ("Bluetooth: btusb: Add support for queuing during polling interval")
Signed-off-by: Kiran K <kiran.k@intel.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
MSIX_HW_INT_CAUSES is a write-one-to-clear register. Using a
read-modify-write helper writes zero to GP0, leaving the cause uncleared,
and can acknowledge unrelated pending causes through the read value.
Write only the GP0 bit directly, matching the interrupt handler's W1C
acknowledgment convention.
Fixes: 88c6216a52 ("Bluetooth: btintel_pcie: Suspend/Resume: Controller doorbell interrupt handling")
Signed-off-by: Ravindra <ravindra@intel.com>
Tested-by: Sergey Lebedev <lsa.uz@pm.me>
Reviewed-by: Sergey Lebedev <lsa.uz@pm.me>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
The gp0_received flag only reports that the GP0 handler ran. It does not
contain proof that the handler completed the requested D-state transition:
a matched case can leave the state unchanged.
Refresh the boot-stage register before treating the transition as
successful. When the controller is in D0 but the handler did not re-arm the
interface, restore the alive context, reset the IA, restart RX, and
complete the mailbox/alive handshake. Propagate RX setup failures to the PM
caller. Likewise, when the controller is in D3 but the handler did not
record it, restore the alive context so the next transition dispatches
correctly.
Serialize the alive-context claim between the GP0 handler and the
set_dxstate() fallback with irq_lock. Only the path that claims the D0
transition resets the IA and rearms RX, avoiding concurrent updates to the
shared ring state.
Co-developed-by: Ravindra <ravindra@intel.com>
Signed-off-by: Ravindra <ravindra@intel.com>
Signed-off-by: Sergey Lebedev <lsa.uz@pm.me>
Fixes: 88c6216a52 ("Bluetooth: btintel_pcie: Suspend/Resume: Controller doorbell interrupt handling")
Tested-by: Sergey Lebedev <lsa.uz@pm.me>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Fix two issues in the PM suspend/resume path:
1. S3 was handled the same as S0ix, keeping the controller on the
D3hot-style path. That caused resume instability because S3 can
remove power from the controller, unlike s2idle/S0ix. Use
pm_suspend_target_state to distinguish them: D3_HOT for S0ix and
D3_COLD for S3/S4. Add .restore to force FLR-based firmware recovery
after S4 and S3 (PM_SUSPEND_MEM), as power is lost. S0ix resumes via
a normal D0 transition.
2. During hibernation, .freeze() puts the controller into the D3cold
state without any loss of power, and the flow normally continues to
.poweroff(). If hibernation instead fails, .thaw() is called to bring
the controller back up, and the old code routed it through
btintel_pcie_resume(), which forced FLR-based firmware recovery
whenever data->pm_sx_event was PM_EVENT_FREEZE. That check was
incorrect: since the controller's power was never actually removed on
this failed-hibernation path, FLR-based recovery is unnecessary. Remove
pm_sx_event and route .thaw through a normal D0 transition instead;
FLR-based recovery is retained only in .restore, where genuine S4
power loss requires it.
Tested with:
S0ix: sudo sh -c 'echo "+40" > /sys/class/rtc/rtc0/wakealarm' && \
echo freeze | sudo tee /sys/power/state
S3: sudo rtcwake -m mem -s 60
S4: sudo rtcwake -m disk -s 60
Fixes: e57362f491 ("Bluetooth: btintel_pcie: Add support for _suspend() / _resume()")
Assisted-by: GitHub-Copilot:GPT5
Signed-off-by: Ravindra <ravindra@intel.com>
Tested-by: Sergey Lebedev <lsa.uz@pm.me>
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
btintel_pcie returns -16 (EBUSY) during suspend, causing the entire
suspend operation to abort on Intel Lunar Lake hardware. The system
immediately resumes after every suspend attempt:
Bluetooth: hci0: Timeout (200 ms) on alive interrupt for D2 entry, retry count 0
Bluetooth: hci0: Timeout (200 ms) on alive interrupt for D2 entry, retry count 1
Bluetooth: hci0: Timeout (200 ms) on alive interrupt for D2 entry, retry count 2
btintel_pcie 0000:00:14.7: PM: pci_pm_suspend(): btintel_pcie_suspend [btintel_pcie] returns -16
btintel_pcie 0000:00:14.7: PM: dpm_run_callback(): pci_pm_suspend returns -16
btintel_pcie 0000:00:14.7: PM: failed to suspend async: error -16
PM: Some devices failed to suspend, or early wake event detected
btintel_pcie_set_dxstate() falls back to checking the controller state via
btintel_pcie_in_d3/d0() when the alive interrupt is missed. However, these
helpers read boot_stage_cache, which is only updated by the interrupt
handler. As such, if the interrupt was missed, the cache is stale and the
fallback check always fails, exhausting all retries and returning -EBUSY,
causing suspend to abort.
The fix involves re-reading the hardware register before the fallback state
check, consistent with btintel_pcie_resume().
Fixes: 88c6216a52 ("Bluetooth: btintel_pcie: Suspend/Resume: Controller doorbell interrupt handling")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221481
Link: https://lore.kernel.org/linux-bluetooth/20260830151550.44687-1-lsa.uz@pm.me/
Signed-off-by: Vladimir V. Kondratyev <vladimirkondratyev2@gmail.com>
Tested-by: Sergey Lebedev <lsa.uz@pm.me>
Signed-off-by: Sergey Lebedev <lsa.uz@pm.me>
Signed-off-by: Ravindra <ravindra@intel.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Define BTINTEL_CNVI_SCP2_C0 (0xA11) for the Scorpius Peak2 C0 stepping
used on Titan Lake platforms and handle it in btintel_pcie_read_hwexp()
alongside existing Scorpius Peak2 variants.
Signed-off-by: Catherine L <catherine.l@intel.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
The Bluetooth controller with USB ID 0b05:1868 found on ASUS
systems uses a Qualcomm QCA Rome chipset, but is currently matched
only by the generic Bluetooth USB entry.
Without BTUSB_QCA_ROME, the driver does not load the QCA rampatch and
NVM firmware. BLE scanning also repeatedly reports:
Bluetooth: hci0: unexpected event for opcode 0x2005
Mark the device as BTUSB_QCA_ROME with wideband speech support, in
line with the other QCA Rome USB IDs.
With the quirk applied, btusb loads:
qca/rampatch_usb_00000302.bin
qca/nvm_usb_00000302.bin
and the unexpected LE Set Random Address completion events are no
longer observed.
Tested-on: ASUS USB 0b05:1868, QCA Rome 0x302
Signed-off-by: Quentin Strydom <qstrydom0@gmail.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Add support for the Draco Bluetooth core (hardware variant 0x23,
CNVi 0xA30) recognizing the new variant in btintel's version
info TLV parsing, MSFT vendor opcode setup, and combined setup
path, as well as in btintel_pcie hardware exception handling
and PCIe setup path.
Signed-off-by: Sai Teja Aluvala <aluvala.sai.teja@intel.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
The bootloader records init sequence progress and debug info in four
core debug registers, useful for debugging FW download failures.
Add btintel_get_rom_debug_info() to issue BTINTEL_GET_ROM_DEBUG_INFO
(0xfcde) and log these registers, and invoke it from every FW download
failure and timeout path: btintel_download_fw() (legacy .sfi flow) and
btintel_prepare_fw_download_tlv() (TLV flow), before resetting to the
bootloader.
Tested by corrupting the operational firmware file to force a
download timeout; the driver logged the debug registers on each
failure and retry, e.g.:
Bluetooth: hci0: Firmware loading timeout
Bluetooth: Intel get rom debug info: dr0:0x80000001 dr1:0x00000000 dr2:0x00000001 dr3:0x00df0071
Signed-off-by: Ravindra <ravindra@intel.com>
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Allow the driver to include vendor USB-transport-specific source files by:
- renaming btusb.c to btusb_main.c
- making btusb.o a composite object
Used by Qualcomm QCC2072 support.
Signed-off-by: Zijun Hu <zijun.hu@oss.qualcomm.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
To allow a vendor driver to assemble and handle its non-BT frames
from the interrupt endpoint.
Used by Qualcomm QCC2072 support.
Signed-off-by: Zijun Hu <zijun.hu@oss.qualcomm.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
In btmtksdio_fw_pmctrl(), if an early operation fails (like clearing
the mailbox ACK), it jumps to the `out:` label and spuriously prints
"Cannot return ownership to device".
Evaluate the ownership return errors locally to ensure the error log is
only printed if the actual ownership transaction fails.
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
MediaTek controllers may emit a firmware debug event on the ACL channel
using the reserved handle 0x0efd, which shows up in the ACL header as
0x2efd once the start fragment flag is included.
Neither btmtk_usb_recv_acl() nor btmtksdio_recv_acl() recognizes it, so
the packet is passed to the HCI core, which has no connection with that
handle and complains:
Bluetooth: hci0: ACL packet for unknown connection handle 3837
Handle it the same way as the existing firmware debug logging packets and
forward it to the diagnostic channel instead.
Confirmed with MTK internally that this event's wire format is fixed:
firmware always sends it as a single ACL_START packet and never splits
it into a continuation (ACL_CONT, which would show up as 0x1efd). Add a
comment above the switch spelling that out for this and the other
vendor-reserved handles already handled here (0xfc6f, 0x05ff, 0x05fe),
so review tooling doesn't keep flagging the apparent lack of a matching
continuation case.
Verified on MT7922: under the condition that triggers this firmware
debug event, it is now routed to the diag channel instead of reaching
the host as an unknown ACL packet.
Signed-off-by: Chris Lu <chris.lu@mediatek.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
The flag field of a BTMTK_WMT_PATCH_DWNLD packet tells the device where
the packet sits in the download sequence, but both download loops write
the bare values 1, 2 and 3, so the reader has to infer the meaning from
the surrounding conditionals.
Add enum btmtk_wmt_pkt_flag and use it in btmtk_setup_firmware_79xx()
and btmtk_setup_firmware(). No functional change.
The other bare flag values in this driver belong to different WMT
opcodes (BTMTK_WMT_FUNC_CTRL, BTMTK_WMT_RST, BTMTK_WMT_SEMAPHORE and so
on), where the field means something else entirely, so they are left
alone.
Signed-off-by: Chris Lu <chris.lu@mediatek.com>
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Assisted-by: Claude:claude-opus-5
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
The firmware log line in btmtk_setup_firmware_79xx() never says which
file was requested, which matters because btmtk_fw_get_filename() derives
the name from the device id and firmware version at runtime. It reports
the firmware's own hwver field as the HW version, when the device id the
driver read from the chip is the more useful value and is already
available as dev_id. And it prints datetime, a u8[16] with no guaranteed
NUL terminator, with %s.
Log the filename before the image is parsed, so a file that fails
validation still says which file it was, report dev_id as the HW version,
and bound datetime with %.16s.
The datetime change is hardening rather than a fix, hence no Fixes: tag:
every file in linux-firmware terminates the field, and provoking the
over-read needs a malformed file in /lib/firmware.
Log output on MT7922 after the change:
[ 365.245951] Bluetooth: hci0: Loading BT firmware: mediatek/BT_RAM_CODE_MT7922_1_1_hdr.bin
[ 365.245956] Bluetooth: hci0: BT HW ver: 0x7922, SW ver: 0x008a, Build Time: 20260605203811
Signed-off-by: Chris Lu <chris.lu@mediatek.com>
Assisted-by: Claude:claude-opus-5
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
btmtk_setup_firmware_79xx() reads the section count out of the firmware's
global descriptor, then walks a 64-byte section map per section and hands
each section's file-supplied offset and length to the WMT download path.
None of that is checked against fw->size, so a truncated or corrupted
file makes the driver read past the end of request_firmware()'s buffer.
On 32-bit the section count can also wrap the section map size
calculation.
Add btmtk_fw_validate_layout() to check that the header, global
descriptor and section map array all fit, and btmtk_fw_validate_section()
to check one section's offset and length, both written so the size
arithmetic cannot wrap. A section count of zero is rejected as well: it
passes every size check but leaves the download loop with nothing to do,
so the function would report success on hardware it never programmed.
They are helpers rather than open-coded because the MT7928 CBMCU download
path added later needs the same arithmetic.
This is hardening against a corrupted /lib/firmware rather than a bug an
unprivileged user can trigger, hence bluetooth-next and no Fixes: tag.
Well-formed firmware files are unaffected.
Signed-off-by: Chris Lu <chris.lu@mediatek.com>
Assisted-by: Claude:claude-opus-5
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Validate device-supplied debug-region boundaries during mailbox TLV
parsing and convert start/end values to a validated region size. Cap
debug-region sizes to 1 MB to prevent out-of-bounds reads if firmware
reports oversized memory ranges. Skip invalid or oversized regions
prior to coredump capture.
This issue was reported by Claude Mythos.
Fixes: 9ea41cd5a6 ("Bluetooth: btintel_pcie: unified decoder coredump format")
Assisted-by: Copilot:claude-opus-4.7
Signed-off-by: Kiran K <kiran.k@intel.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
ll_setup() busy-waits for 100 ms after asserting the controller enable
GPIO on each firmware download attempt. With retries this can occupy
the CPU for up to 400 ms.
The setup callback runs in sleepable context and already uses msleep(),
gpiod_set_value_cansleep() and synchronous firmware commands. Replace
mdelay(100) with msleep(100) so the CPU can run other work during the
power-up delay. Keep the requested delay and subsequent CTS wait.
Signed-off-by: Xuhua Zhang <zhangxuhua@kylinsec.com.cn>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
h5_unslip_one_byte() calls test_and_clear_bit() for every byte other than
an initial SLIP escape byte, even when H5_RX_ESC is already clear. This
performs an unnecessary atomic read-modify-write on the ordinary-byte
receive path. On x86, it emits a locked btr instruction for each such
byte.
Test H5_RX_ESC first and clear it only when consuming an escaped byte.
Handle an initial SLIP escape byte in the alternative branch. The HCI
UART receive callbacks are serialized by the TTY layer, and H5_RX_ESC
is only changed by receive processing and initialization, so there is
no need to atomically test and clear it in one operation.
Keep set_bit() and clear_bit() atomic because other bits in h5->flags
can be updated by the transmit path concurrently. Escape decoding and
invalid-escape recovery remain unchanged.
Signed-off-by: Xuhua Zhang <zhangxuhua@kylinsec.com.cn>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
bcsp_crc_update() processes each byte as two nibbles, requiring two
dependent table lookups for every header and payload byte when CRC is
enabled.
The existing crc_ccitt_byte() helper implements the same reflected
polynomial with one lookup per byte. Use it instead of the private
nibble-based implementation and select CRC_CCITT for BCSP-only UART
configurations as well. The initial CRC value and final bit reversal
remain unchanged.
This replaces the private 16-entry table with the shared 256-entry table,
trading table size for fewer dependent lookups. An exhaustive comparison
of all 65536 CRC states and 256 input bytes matches both the old code and
a bitwise reference implementation.
Signed-off-by: Xuhua Zhang <zhangxuhua@kylinsec.com.cn>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Add the USB ID 0x14b0:0x047a for the StarTech AV53C1-USB-BLUETOOTH
adapter, a Realtek RTL8761BUE based Bluetooth 5.3 dongle.
Without this entry btusb treats the device as a generic Bluetooth
adapter and never loads the Realtek firmware, leaving the controller on
its ROM firmware. In that state it advertises and scans actively, but
never reports advertisements during passive scanning. LE connections
initiated by the kernel wait for a passive-scan report before issuing
LE Create Connection, so connecting and pairing from BlueZ time out
without any error from the controller.
The same product is also sold with the ID 0x2c0a:0x8761, which is
already supported.
lsusb -v output for the device:
Bus 001 Device 010: ID 14b0:047a StarTech.com Ltd. Bluetooth Radio
Device Descriptor:
bcdUSB 1.10
bDeviceClass 224 Wireless
bDeviceSubClass 1 Radio Frequency
bDeviceProtocol 1 Bluetooth
idVendor 0x14b0 StarTech.com Ltd.
idProduct 0x047a
bcdDevice 2.00
iManufacturer 1 Realtek
iProduct 2 Bluetooth Radio
iSerial 3 00E04C239987
bNumInterfaces 2
Interface Descriptor:
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
Cc: stable@vger.kernel.org
Signed-off-by: Nikolaj Klitlund Børty <nbn@sj.dk>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Replace the legacy TLV-based coredump with a unified INI-format dump
compatible with the iwlwifi decoder so a single decoder can parse
coredumps across all Intel BT PCIe controller variants.
The dump is emitted via dev_coredumpsg() as structured regions built
from firmware-advertised addresses: DRAM monitor buffers (single or
MDBGC multi-buffer), SMEM monitor, exception event buffer, DCCM, SDS,
SDS IOSF, ECL and dump info metadata. Regions are collected only when
firmware advertises a valid address and size, and only collected
regions are advertised in regions_mask.
Add INTEL_CNVX_TOP_DASH() and INTEL_CNVX_TOP_FLAVOR() helpers to
btintel.h for RfIdDash/RfIdFlavor extraction.
Assisted-by: Copilot:gemini-3.6-flash
Signed-off-by: Chandrashekar Devegowda <chandrashekar.devegowda@intel.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Newer Intel BT PCIe variants (Nova Lake SCP2 and PTL FMP2) require
three independent DRAM debug (DBGC) buffer pools instead of the
single pool used by existing controllers.
Factor the per-pool buffer allocation into a common helper and add
a multi-DBGC (MDBGC) setup path that allocates three pools using
the fragment context format. MDBGC is used when the device reports
an MDBGC-capable variant; otherwise the existing single-pool DBGC
path is retained.
Assisted-by: Copilot:claude-opus-4.7 sparse
Signed-off-by: Chandrashekar Devegowda <chandrashekar.devegowda@intel.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Two identical definitions of BTINTEL_PCIE_MAGIC_NUM were present in
btintel_pcie.c, one indented with spaces and one with a tab. Remove the
space-indented duplicate and the surrounding blank lines. Kernel coding
style requires tabs for indentation, so keep the tab-indented copy.
No functional change.
Assisted-by: Copilot:claude-opus-4.7 sparse
Fixes: 6ed8304738 ("Bluetooth: btintel_pcie: Setup buffers for firmware traces")
Signed-off-by: Chandrashekar Devegowda <chandrashekar.devegowda@intel.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Add support for the Synaptics 4384 Bluetooth controller
by adding the corresponding chip IDs.
Tested on the VIM3 platform. Verified that the controller initializes
successfully and that firmware loading and basic Bluetooth operation
work as expected.
The VIM3 is a Khadas single-board computer that I used as the host
platform for testing the BCM4384 Bluetooth controller.
Test log:
Bluetooth: hci0: BCM: chip id 206
Bluetooth: hci0: BCM: features 0x0f
Bluetooth: hci0: BCM4384B0
Bluetooth: hci0: BCM4384B0 (002.001.025) build 0000
Bluetooth: hci0: BCM4384B0 'brcm/BCM4384B0.hcd' Patch
Bluetooth: hci0: BCM: features 0x0f
Bluetooth: hci0: BCM4384B0 AP6684P CN iPA [Version: 1030.1021]
Bluetooth: hci0: BCM4384B0 (002.001.025) build 1021
Bluetooth: hci0: BCM: Using default device address (43:84:b0:00:76:93)
Signed-off-by: Andy Chang <Andy.Chang@synaptics.com>
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
The onboard Realtek RTL8821CE combo card on the ASUS PRIME B550-PLUS
AC-HES presents its Bluetooth function as USB ID 13d3:3556. This ID is
missing from quirks_table, so btusb matches the device only through the
generic Bluetooth class entry in btusb_table and driver_info stays zero.
BTUSB_REALTEK is therefore never set, btrtl never runs, and the
controller keeps executing its on-chip ROM firmware instead of loading
rtl_bt/rtl8821c_fw.bin and rtl_bt/rtl8821c_config.bin.
In that state BLE HID peripherals are unusable. A HHKB Hybrid keyboard
pairs and enumerates as a HID device, then the link drops within 10-30
seconds, repeatedly. The same keyboard is stable on the same host under
other operating systems.
Adding the ID lets btusb run the Realtek setup path:
Bluetooth: hci0: RTL: examining hci_ver=08 hci_rev=000c lmp_ver=08 lmp_subver=8821
Bluetooth: hci0: RTL: rom_version status=0 version=1
Bluetooth: hci0: RTL: loading rtl_bt/rtl8821c_fw.bin
Bluetooth: hci0: RTL: loading rtl_bt/rtl8821c_config.bin
Bluetooth: hci0: RTL: cfg_sz 10, total sz 34926
Bluetooth: hci0: RTL: fw version 0x75b8f098
With the firmware loaded the same keyboard has stayed connected for over
11 hours without a single drop.
Device descriptor:
T: Bus=01 Lev=01 Prnt=01 Port=04 Cnt=02 Dev#= 2 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=13d3 ProdID=3556 Rev=01.10
S: Manufacturer=Realtek
S: Product=Bluetooth Radio
S: SerialNumber=00e04c000001
C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
Signed-off-by: Aritra Das <aritra.rohit2003@gmail.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This adds support for Bulk Serialization Mode introduced in 6.2:
https://www.bluetooth.com/bluetooth-core-6-2-feature-overview/#5-bluetooth-hci-usb-le-isochronous-supporthttps://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/Core-62/out/en/host-controller-interface/usb-transport-layer.html#UUID-c1a65395-29e9-87d3-2981-8bed625d0459
It works by detecting if alternate setting 1 is supported for the
interface and then switches to use it as it serializes all the frames
in a single Bulk endpoint using H4 headers and it considerable more
robust then legacy one while allowing the transport of ISO packets:
'In addition to enabling Bluetooth® LE Audio, the new mode resolves a
persistent race condition in the legacy USB transport layer. In Legacy
Mode, different endpoint types are serviced in a specific order within
a USB frame, which can result in out-of-order delivery of data and
events. For example, a Host might receive a data packet before the
event signaling its arrival. This behavior can disrupt critical
processes such as connection setup, disconnection, and data encryption,
adversely affecting the user experience.'
Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
h4_recv_buf() is currently implemented in hci_h4.c which is only built as
part of the hci_uart module, and only when CONFIG_BT_HCIUART_H4 is
enabled. That makes the H:4 reassembly logic unusable by drivers which do
not depend on hci_uart, e.g. btusb which needs it to implement Bulk
Serialization Mode.
Move the transport agnostic part into the Bluetooth core as
h4_recv_skb(), which takes a struct hci_dev instead of a struct hci_uart,
along with struct h4_recv_pkt and the H4_RECV_* helpers, and keep
h4_recv_buf() as a thin wrapper for the hci_uart protocols.
Since every Bluetooth driver already depends on the bluetooth module this
introduces no new module dependency and no new Kconfig symbol.
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
mt79xx_setup() passes a hardcoded 0 to btmtk_setup_firmware_79xx(),
discarding the device id that btmtksdio_setup() has just read from register
0x70010200. That argument only gates the section filtering for MT6639,
which has no SDIO interface, so this is a no-op on supported hardware and
carries no Fixes: tag.
Pass the value that has already been read, matching the USB path. Declare
dev_id as u32 while at it, since that is what btmtksdio_mtk_reg_read()
writes through the pointer.
Signed-off-by: Chris Lu <chris.lu@mediatek.com>
Assisted-by: Claude:claude-opus-5
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
btmtksdio_setup() derives the firmware filename with
btmtk_fw_get_filename() and then overwrites it with an snprintf() that
open-codes that helper's fallback format. Commit 7f935b21be ("Bluetooth:
btmtk: apply the common btmtk_fw_get_filename") added the helper call
without removing the snprintf() it was meant to replace.
None of the device ids the helper special-cases can appear here: 0x6639,
0x7925 and the flavored 0x7961 belong to parts with no SDIO interface, and
btmtksdio_setup() passes a flavor of 0 accordingly. The helper always falls
through to the snprintf()'s own format, so both produce the same string and
removing it is a no-op.
Remove it anyway, since it silently defeats the helper for any device id
the helper special-cases.
Signed-off-by: Chris Lu <chris.lu@mediatek.com>
Assisted-by: Claude:claude-opus-5
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
The MT7925 Bluetooth USB function can enumerate successfully after a warm
reboot while the WMT function-control command remains unresponsive.
When that command times out, btmtk_usb_setup() currently returns
-ETIMEDOUT without entering the existing MediaTek reset path. The existing
USB reset and recovery machinery is therefore never reached.
For MT7925, call btmtk_reset_sync() when the WMT function-control command
times out. This enters the existing reset path in btusb_mtk_reset(), which
performs the MediaTek subsystem reset and queues a USB device reset.
Runtime tracing on the affected hardware showed the resulting path through
usb_queue_reset_device(), usb_reset_device() and
usb_reset_and_verify_device(). When reset and verification could not
restore the device, the USB core escalated to a logical disconnect and
re-enumeration.
Recovery succeeded in three controlled Windows-to-Linux tests. Runtime
tracing showed the existing USB reset path escalating to logical disconnect
and re-enumeration. In two of those tests, tracing continued through the
subsequent enumeration failures and directly captured
usb_acpi_port_prr_reset(), after which the MT7925 re-enumerated and
Bluetooth recovered.
These tests were performed on top of Chia-Lin Kao's ACPI _PRR hub patch,
which remains a prerequisite for this patch.
A fourth Windows-to-Linux test was then performed with the diagnostic btusb
blacklist removed and btusb binding normally during boot. The WMT timeout
reproduced and Bluetooth recovered automatically without manual
intervention.
Signed-off-by: George Maraveyas <george.0xfff@gmail.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
