kernel/git/next/linux-next.git/drivers/bluetooth/btintel_pcie.h, branch master

Bluetooth: btintel_pcie: Route debug traces to WiFi DBGC by default

2026-08-19T16:43:59+00:00

Set dbg_output_mode to 0x06 (BTINTEL_PCIE_WIFI_DBGC) by default so firmware debug traces are forwarded to the WiFi DBGC. In this mode: - Host DBGC fragment/data buffers are NOT allocated. - Context info publishes dbgc_addr/size as 0. Add a small helper btintel_pcie_dbg_to_wifi() driven by a cached dbg_path_cache field in struct btintel_pcie_data, initialized to BTINTEL_PCIE_WIFI_DBGC in probe. Signed-off-by: Kiran K Signed-off-by: Catherine L Signed-off-by: Luiz Augusto von Dentz

Bluetooth: btintel_pcie: sync mbox tlv parsing with GP0 alive interrupt

2026-08-19T16:43:55+00:00

Performing a target access to read the mbox TLV table while the driver is concurrently posting RX buffers to the firmware causes the hardware to return 0 for the target address, resulting in an invalid/empty TLV parse. Add a synchronization handshake between the mbox TLV read operation performed by the mbox worker and the GP0 (alive) MSI-X interrupt (which signals completion of RX buffer posting). The worker now waits for the alive interrupt before initiating the target access, ensuring the hardware returns valid data. Assisted-by: Gemini:gemini-3.1-pro-preview Signed-off-by: Kiran K Signed-off-by: Luiz Augusto von Dentz

Bluetooth: btintel_pcie: parse FW memory addresses via mailbox TLV

2026-08-19T16:43:52+00:00

Implement GP1 mailbox interrupt handling to receive memory region addresses from firmware via a TLV-based protocol. When firmware sends a BUILD_SPECIFIC_RESOURCES_MAPPING mailbox message, the driver reads a TLV table from device memory containing addresses and sizes of debug memory regions (exception dump, DCCM, SDS, ECL, SMEM). This enables the driver to dynamically discover dump region locations instead of using hardcoded addresses, supporting current and future Intel BT PCIe controller variants. Replace per-device hardcoded exception memory address and size constants in btintel_pcie_read_hwexp() with the dynamically populated values from dump_info, making exception dump handling consistent with other dump regions. Key changes: - Rewrite GP1 handler to parse mailbox registers and queue TLV work - Add btintel_parse_mbox_tlv() for parsing FW-provided TLV data - Add mbox_work workqueue for deferred TLV processing - Store parsed region addresses in btintel_pcie_dump_mem_info - Add cnvi_bt field to btintel_data for HW variant identification - Rename fw_git_sha1 to fw_sha for consistency - Remove hardcoded HWEXP address/size macros and use dump_info Assisted-by: GitHub-Copilot:claude-opus-4.7 Signed-off-by: Chandrashekar Devegowda Signed-off-by: Kiran K Signed-off-by: Luiz Augusto von Dentz

Bluetooth: btintel_pcie: split coredump worker into per-trigger works

2026-08-07T16:35:01+00:00

btintel_pcie_coredump_worker() handled three unrelated jobs in one work item: collect a DRAM trace coredump, read the hardware exception event, and read the firmware-trigger event. The worker walked three flag bits at runtime and each interrupt path mutated multiple bits to communicate which sub-jobs the worker should run, which made the ownership rules for those bits hard to reason about and entangled the trigger reason with the in-progress accounting. Replace the single combined worker with three single-purpose ones, each owning exactly one flag: coredump_work -> btintel_pcie_dump_traces() guarded by COREDUMP_INPROGRESS hwexp_work -> btintel_pcie_read_hwexp() guarded by CORE_HALTED (already permanent until re-probe; HWEXP_INPROGRESS is now redundant and removed) fwtrigger_work -> btintel_pcie_dump_fwtrigger_event() guarded by FWTRIGGER_DUMP_INPROGRESS All three workers are queued on a shared ordered workqueue (renamed coredump_workqueue -> dump_workqueue) so a companion event reader (hwexp/fwtrigger) and the coredump always run FIFO. Companion work is queued before coredump_work so dmp_hdr.event_type/event_id are populated by the time dump_traces() consumes them, preserving the original ordering. Introduce btintel_pcie_queue_coredump() to centralize the coredump trigger contract: it is the single writer of COREDUMP_INPROGRESS and of dmp_hdr.trigger_reason, sets both atomically against concurrent triggers, and rolls back the bit if the workqueue is disabled (reset/remove in progress) so a later trigger after re-probe can succeed. All four trigger sites (HWEXP IRQ, FW-trigger IRQ, devcoredump user trigger, resume() D0 error path) go through the helper. Per-work guard bits are now cleared at the tail of each worker rather than in the middle of the combined worker, which closes a subtle race where a duplicate IRQ could observe a cleared bit and requeue while the previous pass was still finalizing dev_coredumpv(). reset_work() and remove() now disable_work_sync() all three workers and, on the FLR-failure path, enable_work() all three to keep their disable counters balanced. The PLDR/FLR-success contract (re-probe re-INIT_WORKs everything with counter 0) is preserved. No functional change to the dump payloads; this is a pure restructuring of the worker dispatch and its synchronization. Signed-off-by: Kiran K Assisted-by: GitHub-Copilot:claude-4.7-opus Signed-off-by: Luiz Augusto von Dentz

Bluetooth: btintel_pcie: Separate coredump work from RX work

2026-06-11T18:24:42+00:00

Sharing a single workqueue between coredump processing and RX delays evacuation of RX events while a coredump is in progress. The firmware's RX buffers can overflow during that window, leading to dropped events. The issue was observed in HID use cases where HID reports arrive in bursts and quickly fill the RX path while a coredump is being collected. Move coredump processing to a dedicated ordered coredump_workqueue with its own coredump_work, so coredumps run independently of RX. All four coredump trigger sources (FW assert, HW exception, user sysfs trigger, and resume-error detection) are switched to this new workqueue. Ordering serialises concurrent triggers without blocking RX. Signed-off-by: Ravindra Signed-off-by: Kiran K Signed-off-by: Luiz Augusto von Dentz

Bluetooth: btintel_pcie: Load IOSF debug regs by controller variant

2026-06-11T18:24:41+00:00

Load the IOSF DBGC base address based on the controller hardware variant when reading DRAM buffers during a trace dump. Scorpius Peak family controllers (SCP/SCP2/SCP2F) use a different DBGC base address (0xf0d5d500) than Blazar family controllers (BZRI/BZRIW, 0xf3800300). Fixes: 07e6bddb54b4 ("Bluetooth: btintel_pcie: Add support for device coredump") Signed-off-by: Sai Teja Aluvala Signed-off-by: Kiran K Signed-off-by: Luiz Augusto von Dentz

Bluetooth: btintel_pcie: Add support for smart trigger dump

2026-06-11T18:24:41+00:00

Based on the debug configuration, firmware can raise MSI-X interrupt with firmware trigger cause bit set on specific events like Disconnection, Connection Timeout, Page Timeout etc. Upon receiving an MSI-X interrupt with the firmware trigger cause bit set, the driver performs the following actions: 1. Reads Device Memory: Retrieves data from the device memory, constructs an HCI diagnostic event, and sends it to the monitor. This event includes details about the trigger, such as connection timeout or page timeout. 2. Dumps Device Coredump: Generates a coredump containing firmware traces for further analysis. The coredump can be retrieved using: $ cat /sys/class/devcoredump/devcd*/data > /tmp/btintel_coredump.bin HCI traces: = Vendor Diagnostic (len 12) a5 a5 a5 a5 01 03 00 23 00 01 00 00 Signed-off-by: Kiran K Signed-off-by: Luiz Augusto von Dentz

Bluetooth: btintel_pcie: Support Product level reset

2026-06-11T18:24:37+00:00

When driver encounters a TOP exception, ACPI methods will be called for Product level reset since Wifi and BT share the same TOP. BT driver will first reprobe the wifi driver and then reprobe BT. Signed-off-by: Chandrashekar Devegowda Signed-off-by: Venkat Rao Bagalkote Signed-off-by: Luiz Augusto von Dentz

Bluetooth: btintel_pcie: Fix incorrect MAC access programming

2026-05-20T20:35:47+00:00

btintel_pcie_get_mac_access() and btintel_pcie_release_mac_access() were programming STOP_MAC_ACCESS_DIS and XTAL_CLK_REQ in addition to the MAC_ACCESS_REQ handshake. These bits are not part of the host MAC-access handshake on the supported parts; the driver was programming them incorrectly. Drop the writes so the register update contains only the bits the controller actually consumes. Fixes: b9465e6670a2 ("Bluetooth: btintel_pcie: Read hardware exception data") Signed-off-by: Kiran K Signed-off-by: Luiz Augusto von Dentz

Bluetooth: btintel_pcie: treat boot stage bit 12 as warning

2026-05-06T20:21:34+00:00

CSR boot stage register bit 12 is documented as a device warning, not a fatal error. Rename the bit definition accordingly and stop including it in btintel_pcie_in_error(). This keeps warning-only boot stage values from being classified as errors while preserving abort-handler state as the actual error condition. Fixes: 190377500fde ("Bluetooth: btintel_pcie: Dump debug registers on error") Signed-off-by: Kiran K Signed-off-by: Sai Teja Aluvala Signed-off-by: Luiz Augusto von Dentz