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: e57362f4911b ("Bluetooth: btintel_pcie: Add support for _suspend() / _resume()")
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>
---
 drivers/bluetooth/btintel_pcie.c | 8 +++++---
 drivers/bluetooth/btintel_pcie.h | 1 +
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/bluetooth/btintel_pcie.c b/drivers/bluetooth/btintel_pcie.c
index 30923eaabed7..44ad31a5d7ed 100644
--- a/drivers/bluetooth/btintel_pcie.c
+++ b/drivers/bluetooth/btintel_pcie.c
@@ -3538,10 +3538,12 @@ static int btintel_pcie_set_dxstate(struct btintel_pcie_data *data, u32 dxstate)
 					  BTINTEL_PCIE_CSR_MSIX_HW_INT_CAUSES,
 					  BTINTEL_PCIE_MSIX_HW_INT_CAUSES_GP0);
 
-		/* A hardware bug may cause the alive interrupt to be missed.
-		 * Check if the controller reached the expected state and retry
-		 * the operation only if it hasn't.
+		/* A hardware bug may cause the alive interrupt to be missed. Refresh
+		 * boot_stage_cache from hardware, since only the interrupt handler
+		 * updates it. Finally retry only if the state check still fails.
 		 */
+		data->boot_stage_cache = btintel_pcie_rd_reg32(data,
+							       BTINTEL_PCIE_CSR_BOOT_STAGE_REG);
 		if (dxstate == BTINTEL_PCIE_STATE_D0) {
 			if (btintel_pcie_in_d0(data))
 				return 0;
diff --git a/drivers/bluetooth/btintel_pcie.h b/drivers/bluetooth/btintel_pcie.h
index 9baa214d9bbe..a7f4e590af5e 100644
--- a/drivers/bluetooth/btintel_pcie.h
+++ b/drivers/bluetooth/btintel_pcie.h
@@ -51,6 +51,7 @@
 #define BTINTEL_PCIE_CSR_BOOT_STAGE_DEVICE_HALTED	(BIT(14))
 #define BTINTEL_PCIE_CSR_BOOT_STAGE_MAC_ACCESS_ON	(BIT(16))
 #define BTINTEL_PCIE_CSR_BOOT_STAGE_ALIVE		(BIT(23))
+/* Reflects live D-state. Updated by hardware on every D-state transition. */
 #define BTINTEL_PCIE_CSR_BOOT_STAGE_D3_STATE_READY	(BIT(24))
 
 #define BTINTEL_PCIE_CSR_DOORBELL_MBOX_READ_CONFIRM	(BIT(4))
-- 
2.55.0

For anyone arriving here later: this patch is now 1/2 of a two-patch series,
posted today.

  https://lore.kernel.org/linux-bluetooth/20260909123416.71919-1-lsa.uz@pm.me/

The code is untouched. The only change is my Signed-off-by beneath Vladimir's,
as the person passing it on. 2/2 is Ravindra's PM-flow patch rebased on top,
with his agreement, and the cover letter explains why the two belong together:
each of them leaves a real failure behind when applied alone, and that is now
shown on two machines and two controller generations.

Vladimir, I have not heard from you since I said this would go out unless you
objected, and I am not reading that as agreement. It is your patch. If you
would rather post the series yourself, or not at all, say so and I will
withdraw it.

I am deliberately not marking this posting superseded in patchwork - that is
yours or the maintainer's call, not mine.

Sergey

Vladimir, Paul, Chandrashekar, Kiran,

Nothing here asks for a change to v4 — it is right and my Tested-by stands. This
is the measurement behind a question I put to the list on 2026-09-02 and could
not support with numbers at the time.

The question was whether BTINTEL_PCIE_CSR_BOOT_STAGE_REG should be polled for the
target D-state, with the alive interrupt demoted to an early exit, rather than the
other way round. So I timed both against the same zero — the write in
btintel_pcie_wr_sleep_cntrl() — on Surface Pro 11 (Lunar Lake), Intel BE201,
8086:a876 rev 10, kernel 7.0.0-30, s2idle. A measurement build polls the register
every 100 us and records when bit 24 reaches the target and when gp0_received
becomes true. Four suspend/resume cycles, eight transitions:

  dxstate  register (us)              interrupt (us)
  D3       1517  1027  1085  1111     1670  1171  1085  1112
  D0       1630  1521  1676  1701     1630  1646  1676  1701

The register reaches the target state in **1.0 to 1.7 ms** and is **never later
than the interrupt**. In four of the eight it is the same 100 us sample; in two
it leads by 125 and 153 us. Against that, the current path budgets 200 ms per
attempt and three attempts — up to 600 ms per transition, twice per suspend cycle.

That is the whole of my case, and its limits are worth stating plainly. One
machine, one controller, one firmware. The poll itself is PCIe traffic and could
be perturbing what it measures, though it would have to be perturbing it in the
direction that flatters the register. And a settle time is not a guarantee: an
interrupt exists partly so the driver need not assume a bound.

But if the bound holds on Intel's own hardware, polling would delete the
stale-cache class of bug rather than catch it, and POLL_INTERVAL_US is already
declared in btintel_pcie.h and unused.

I have not written that patch, because it is your subsystem and my coverage is
one machine. What I do have is the hardware, a fixture that drops the alive
interrupt on demand, and the per-hunk method already used in this thread. So if
an RFC would be useful rather than noise, I will write one and report it the same
way — measured per hunk, with the failure injected and with it disabled. If you
would rather it came from someone with the full range of controllers, that is a
perfectly good answer and I will leave it here.

Sergey

+Mahalingeshwara, Ravindra

Hi Sergey,

Thanks a lot for your thorough testing, detailed analysis, and insightful
measurement data. Your Tested-by for v4 is much appreciated.

Good catch on POLL_INTERVAL_US in btintel_pcie.h. Currently, waiting for the
alive interrupt is the flow defined for all Intel Bluetooth PCIe products, as
interrupt-driven notifications are designed to avoid active polling on the
PCIe bus during state transitions.

We will discuss your observations and data internally with our Systems team to
evaluate if any adjustments can be approved for future enhancements.

Thanks again,
Kiran

>Subject: Re: [PATCH v4] Bluetooth: btintel_pcie: fix stale cache in set_dxstate
>fallback check
>
>Vladimir, Paul, Chandrashekar, Kiran,
>
>Nothing here asks for a change to v4 — it is right and my Tested-by stands. This
>is the measurement behind a question I put to the list on 2026-09-02 and
>could not support with numbers at the time.
>
>The question was whether BTINTEL_PCIE_CSR_BOOT_STAGE_REG should be
>polled for the target D-state, with the alive interrupt demoted to an early exit,
>rather than the other way round. So I timed both against the same zero — the
>write in
>btintel_pcie_wr_sleep_cntrl() — on Surface Pro 11 (Lunar Lake), Intel BE201,
>8086:a876 rev 10, kernel 7.0.0-30, s2idle. A measurement build polls the
>register every 100 us and records when bit 24 reaches the target and when
>gp0_received becomes true. Four suspend/resume cycles, eight transitions:
>
>  dxstate  register (us)              interrupt (us)
>  D3       1517  1027  1085  1111     1670  1171  1085  1112
>  D0       1630  1521  1676  1701     1630  1646  1676  1701
>
>The register reaches the target state in **1.0 to 1.7 ms** and is **never later
>than the interrupt**. In four of the eight it is the same 100 us sample; in two it
>leads by 125 and 153 us. Against that, the current path budgets 200 ms per
>attempt and three attempts — up to 600 ms per transition, twice per suspend
>cycle.
>
>That is the whole of my case, and its limits are worth stating plainly. One
>machine, one controller, one firmware. The poll itself is PCIe traffic and could
>be perturbing what it measures, though it would have to be perturbing it in the
>direction that flatters the register. And a settle time is not a guarantee: an
>interrupt exists partly so the driver need not assume a bound.
>
>But if the bound holds on Intel's own hardware, polling would delete the stale-
>cache class of bug rather than catch it, and POLL_INTERVAL_US is already
>declared in btintel_pcie.h and unused.
>
>I have not written that patch, because it is your subsystem and my coverage is
>one machine. What I do have is the hardware, a fixture that drops the alive
>interrupt on demand, and the per-hunk method already used in this thread. So
>if an RFC would be useful rather than noise, I will write one and report it the
>same way — measured per hunk, with the failure injected and with it disabled.
>If you would rather it came from someone with the full range of controllers,
>that is a perfectly good answer and I will leave it here.
>
>Sergey