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

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

Bluetooth: btintel_pcie: Align shared DMA memory to 128 bytes

2026-04-13T13:19:42+00:00

Align each descriptor/index/context region to 128 bytes before calculating the total DMA pool size. This ensures the memory layout shared with firmware meets the 128-byte alignment requirement. The DMA pool alignment is also set to 128 bytes to match the firmware expectation for all shared structures. Signed-off-by: Kiran K Signed-off-by: Luiz Augusto von Dentz

Bluetooth: btintel_pcie: Suspend/Resume: Controller doorbell interrupt handling

2025-12-01T21:00:07+00:00

Due to a hardware bug during suspend/resume, the controller may miss a doorbell interrupt. To address this, a retry mechanism has been added to inform the controller before reporting a failure. Test case: - run suspend and resume cycles. Signed-off-by: Ravindra Signed-off-by: Kiran K Signed-off-by: Luiz Augusto von Dentz

Bluetooth: btintel_pcie: Support for S4 (Hibernate)

2025-12-01T21:00:07+00:00

During S4 (hibernate), the Bluetooth device loses power. Upon resume, the driver performs the following actions: 1. Unregisters hdev 2. Calls function level reset 3. Registers hdev Test case: - run command sudo rtcwake -m disk -s 60 Signed-off-by: Ravindra Signed-off-by: Kiran K Signed-off-by: Luiz Augusto von Dentz