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

Bluetooth: btintel_pcie: Add vendor_reset PCI sysfs for PLDR

2026-08-07T19:38:31+00:00

Add a read-write sysfs entry at /sys/bus/pci/devices//vendor_reset to allow userspace to trigger PLDR (Product Level Device Reset). Reading the attribute displays supported reset types. Writing integer 0 triggers PLDR. Any other input is rejected with -EINVAL and a warning log. Signed-off-by: Chandrashekar Devegowda Signed-off-by: Luiz Augusto von Dentz

Bluetooth: btintel_pcie: Remove unreachable break after goto

2026-08-07T19:38:30+00:00

In the switch-case block for hardware variant detection, the default case has an unreachable 'break' statement following 'goto exit_error'. Remove the dead code. Signed-off-by: Chen Changcheng Signed-off-by: Luiz Augusto von Dentz

Bluetooth: btintel_pcie: serialize reset_type with RECOVERY_IN_PROGRESS

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

The reset path had two concurrency holes. Both are reachable in practice when btintel_pcie_hw_error() is invoked from the HCI rx path while another reset is being requested or is already in flight. 1. data->reset_type was a plain shared field. The hw_error path wrote it BEFORE the test_and_set_bit(RECOVERY_IN_PROGRESS) guard inside btintel_pcie_reset(), so a second hw_error could clobber the type chosen by an earlier in-flight request: CPU0 (reset_work) CPU1 (hw_error #2) dev_data->reset_type = PLDR T2: read reset_type dev_data->reset_type = FLR reset() test_and_set sees 1 -> drops, but type already clobbered The hdev->reset callback (.reset = btintel_pcie_reset, invoked via the sysfs reset attribute /sys/class/bluetooth/hciX/reset and from hci_cmd_timeout()) compounded this by not writing reset_type at all -- it inherited whatever value a previous hw_error / resume() had left, which could be PLDR. 2. btintel_pcie_dump_debug_registers() was called unconditionally at the top of hw_error(). When reset_work was already running pci_try_reset_function(), the BT MMIO window can read all-1s or trigger AER for the duration of the FLR, polluting the debug dump with no useful information. Refactor the reset path to make RECOVERY_IN_PROGRESS the sole serializer for both the type write and the work scheduling: - Replace btintel_pcie_reset(hdev) with btintel_pcie_request_reset(data, type). The helper takes the desired reset variant as a parameter and writes data->reset_type only after winning test_and_set_bit(); losers return without touching the field, so concurrent triggers can no longer clobber an in-flight reset's type. reset_work()'s read of reset_type is now ordered after the bit transition via schedule_work()'s memory barrier. - Add a thin btintel_pcie_hci_reset() wrapper for the hdev->reset callback (invoked via the sysfs reset attribute /sys/class/bluetooth/hciX/reset and from hci_cmd_timeout()) that always requests FLR explicitly, so these paths no longer inherit stale state from prior error events. - Add an early test_bit(RECOVERY_IN_PROGRESS) gate at the top of hw_error() so dump_debug_registers() and the recovery-counter bookkeeping are skipped when a reset is already in flight; the authoritative test_and_set lives in request_reset() and races cleanly against any caller that passes the optimistic check. - Convert the two resume() reset sites (FREEZE/HIBERNATE and the D0-error path) to request_reset(data, FLR), removing the redundant manual reset_type writes. Assisted-by: GitHub-Copilot:claude-4.7-opus 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: Refactor FLR to use device_reprobe()

2026-07-06T14:46:58+00:00

The FLR branch in btintel_pcie_reset_work() open-coded the entire re-init sequence: btintel_pcie_release_hdev() (hci_unregister_dev + hci_free_dev), pci_try_reset_function(), enable_interrupts / config_msix / enable_bt / reset_ia / start_rx, then btintel_pcie_setup_hdev() (hci_alloc_dev_priv + hci_register_dev). Every probe() init step had to be kept in sync with this second copy in the reset path, and any failure mid-sequence left state to unwind by hand. The PLDR path already delegates teardown and re-init to the PCI core via device_reprobe(): .remove() destroys data through devres and unregisters hdev, then .probe() rebuilds everything from scratch. Apply the same model to FLR. Introduce btintel_pcie_perform_flr() mirroring perform_pldr(). It runs pci_try_reset_function() (required to avoid the device_lock ABBA against btintel_pcie_remove(), which calls disable_work_sync(&reset_work) while holding device_lock) followed by device_reprobe(). On success, data is destroyed and a fresh probe re-INIT_WORKs coredump_work with disable count 0, so enable_work() must not be called; on failure, data is still alive and the caller balances the earlier disable_work_sync(). The contract is documented on the helper and reiterated at the reset_work() call site. reset_work() shrinks to interrupt/worker drain, dispatch on reset_type, and the single asymmetry between the two paths. The out_enable label, the manual unregister/register pair, and the forward declaration of btintel_pcie_setup_hdev() are dropped. No intended functional change; FLR and PLDR now share one teardown contract. Fixes: 256ab9520d15 ("Bluetooth: btintel_pcie: Support Function level reset") Assisted-by: GitHub-Copilot:claude-4.7-opus Signed-off-by: Kiran K 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 50 ms delay before MAC init on BlazarIW

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

On BlazarIW, fast restart cycles fail because the D0 entry to MAC init does not complete in time. As a result, MAC initialization does not proceed and the controller fails to transition past the ROM boot stage. Add a 50 ms delay (worst case as per HW analysis) before doing MAC init in btintel_pcie_enable_bt() so the shared hardware reset flow has time to complete. The delay is gated on the BlazarIW PCI device id 0x4D76 so other Intel BT PCIe controllers are unaffected. 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