[PATCH] Bluetooth: btintel_pcie: fix stale cache in set_dxstate fallback check

[PATCH] Bluetooth: btintel_pcie: fix stale cache in set_dxstate fallback check

[Vladimir V. Kondratyev]

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()")

Signed-off-by: Vladimir V. Kondratyev <vladimirkondratyev2@gmail.com>
---
 drivers/bluetooth/btintel_pcie.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/bluetooth/btintel_pcie.c b/drivers/bluetooth/btintel_pcie.c
index fda474406003..7fca8eea6e01 100644
--- a/drivers/bluetooth/btintel_pcie.c
+++ b/drivers/bluetooth/btintel_pcie.c
@@ -2778,9 +2778,13 @@ static int btintel_pcie_set_dxstate(struct btintel_pcie_data *data, u32 dxstate)
 					  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.
+		 * Refresh boot_stage_cache from hardware since it is only
+		 * updated by the interrupt handler, then check if the
+		 * controller reached the expected state and retry the
+		 * operation only if it hasn't.
 		 */
+		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;
-- 
2.54.0

RE: Bluetooth: btintel_pcie: fix stale cache in set_dxstate fallback check

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 882 bytes --]

This is automated email and please do not reply to this email!

Dear submitter,

Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=1091276

---Test result---

Test Summary:
CheckPatch                    PASS      0.69 seconds
GitLint                       PASS      0.30 seconds
SubjectPrefix                 PASS      0.11 seconds
BuildKernel                   PASS      27.57 seconds
CheckAllWarning               PASS      30.23 seconds
CheckSparse                   PASS      28.95 seconds
BuildKernel32                 PASS      27.07 seconds
TestRunnerSetup               PASS      582.94 seconds
IncrementalBuild              PASS      25.20 seconds



https://github.com/bluez/bluetooth-next/pull/155

---
Regards,
Linux Bluetooth

[PATCH] Bluetooth: btintel_pcie: fix stale cache in set_dxstate fallback check

[Vladimir V. Kondratyev]

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()")

Signed-off-by: Vladimir V. Kondratyev <vladimirkondratyev2@gmail.com>
Tested-by: Sergey Lebedev <lsa.uz@pm.me>
---
 drivers/bluetooth/btintel_pcie.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/bluetooth/btintel_pcie.c b/drivers/bluetooth/btintel_pcie.c
index fda474406003..7fca8eea6e01 100644
--- a/drivers/bluetooth/btintel_pcie.c
+++ b/drivers/bluetooth/btintel_pcie.c
@@ -2778,9 +2778,13 @@ static int btintel_pcie_set_dxstate(struct btintel_pcie_data *data, u32 dxstate)
 					  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.
+		 * Refresh boot_stage_cache from hardware since it is only
+		 * updated by the interrupt handler, then check if the
+		 * controller reached the expected state and retry the
+		 * operation only if it hasn't.
 		 */
+		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;
-- 
2.55.0

RE: Bluetooth: btintel_pcie: fix stale cache in set_dxstate fallback check

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 1181 bytes --]

This is automated email and please do not reply to this email!

Dear submitter,

Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=1155660

---Test result---

Test Summary:
CheckPatch                    PASS      1.17 seconds
VerifyFixes                   PASS      0.10 seconds
VerifySignedoff               PASS      0.10 seconds
GitLint                       PASS      0.26 seconds
SubjectPrefix                 PASS      0.09 seconds
BuildKernel                   PASS      25.84 seconds
CheckAllWarning               PASS      28.20 seconds
CheckSparse                   PASS      27.63 seconds
BuildKernel32                 PASS      24.69 seconds
CheckKernelLLVM               SKIP      0.00 seconds
TestRunnerSetup               PASS      457.25 seconds
IncrementalBuild              PASS      23.96 seconds

Details
##############################
Test: CheckKernelLLVM - SKIP
Desc: Build kernel with LLVM + context analysis
Output:
Clang not found


https://github.com/bluez/bluetooth-next/pull/683

---
Regards,
Linux Bluetooth

Re: [PATCH] Bluetooth: btintel_pcie: fix stale cache in set_dxstate fallback check

[Paul Menzel]

[Cc: +Chandrashekar, +Kiran]

Dear Vladimir,


Thank you for your patch.

Am 01.09.26 um 22:37 schrieb Vladimir V. Kondratyev:
> 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.

Can you reproduce this on real hardware?

> 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()")
> 
> Signed-off-by: Vladimir V. Kondratyev <vladimirkondratyev2@gmail.com>
> Tested-by: Sergey Lebedev <lsa.uz@pm.me>
> ---
>   drivers/bluetooth/btintel_pcie.c | 8 ++++++--
>   1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/bluetooth/btintel_pcie.c b/drivers/bluetooth/btintel_pcie.c
> index fda474406003..7fca8eea6e01 100644
> --- a/drivers/bluetooth/btintel_pcie.c
> +++ b/drivers/bluetooth/btintel_pcie.c
> @@ -2778,9 +2778,13 @@ static int btintel_pcie_set_dxstate(struct btintel_pcie_data *data, u32 dxstate)
>   					  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.
> +		 * Refresh boot_stage_cache from hardware since it is only
> +		 * updated by the interrupt handler, then check if the
> +		 * controller reached the expected state and retry the
> +		 * operation only if it hasn't.

Re-flow for less lines?

>   		 */
> +		data->boot_stage_cache = btintel_pcie_rd_reg32(data,
> +							       BTINTEL_PCIE_CSR_BOOT_STAGE_REG);

To me it sounds strange, that a register name *boot stage* should change 
after the boot. ;-)

>   		if (dxstate == BTINTEL_PCIE_STATE_D0) {
>   			if (btintel_pcie_in_d0(data))
>   				return 0;


Kind regards,

Paul

Re: [PATCH] Bluetooth: btintel_pcie: fix stale cache in set_dxstate fallback check

[Sergey Lebedev]

Paul,

Two of your three points I can answer from the hardware, since the
Tested-by on this patch is mine.

> Can you reproduce this on real hardware?

Yes. Surface Pro 11 (Intel, Lunar Lake), Intel BE201, 8086:a876 rev 10.
It first appeared in ordinary use, not in a test:

  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 returns -16
  PM: Some devices failed to suspend, or early wake event detected

One device returning -EBUSY aborts the whole system suspend, so the
machine does not sleep at all.

I have to be honest about the rate rather than useful: it failed on 2 of
the 3 suspends I attempted before installing a workaround, and later, on
a newer kernel with the workaround removed, it succeeded 7 times out of 7
with no btintel_pcie change in between. So the spontaneous failure is not
something I can produce on demand.

What I could do was exercise the exact path deterministically. I built
the driver out of tree with one debug-only parameter that returns from
btintel_pcie_msix_gp0_handler() before the boot_stage_cache refresh, and
only while alive_intr_ctxt is BTINTEL_PCIE_D0. That leaves the cache
stale and gp0_received false — precisely the state a genuinely missed
alive interrupt leaves behind — while the controller still reaches D3.

Without the patch, that reproduces the production failure exactly: three
timeouts, -EBUSY, suspend aborted. With the patch and nothing else
changed: one timeout, the re-read observes D3, set_dxstate() returns 0,
and the system suspends and resumes normally.

Full method and logs are in my earlier message on this thread,
Message-ID <20260830151550.44687-1-lsa.uz@pm.me>.

> To me it sounds strange, that a register name *boot stage* should
> change after the boot. ;-)

It is a fair reaction to the name, but the register genuinely carries
live power state. From the driver's own header:

  #define BTINTEL_PCIE_CSR_BOOT_STAGE_D3_STATE_READY  (BIT(24))

and both helpers test that one bit and nothing else:

  static bool btintel_pcie_in_d3(struct btintel_pcie_data *data)
  {
      return data->boot_stage_cache & BTINTEL_PCIE_CSR_BOOT_STAGE_D3_STATE_READY;
  }

  static bool btintel_pcie_in_d0(struct btintel_pcie_data *data)
  {
      return !(data->boot_stage_cache & BTINTEL_PCIE_CSR_BOOT_STAGE_D3_STATE_READY);
  }

So bit 24 is updated by the controller on every D-state transition, long
after boot. The name describes the register's original purpose rather
than everything Intel later put in it. btintel_pcie_resume() already
re-reads it for exactly this reason, which is what makes the patch's
change consistent rather than novel.

The re-flow is Vladimir's call and I have no opinion on it. If a v3 comes
out of this, I still have the hardware and the test fixture and will
re-run both halves against it.

Thanks,
Sergey

Re: [PATCH] Bluetooth: btintel_pcie: fix stale cache in set_dxstate fallback check

[Paul Menzel]

Dear Sergey,


Thank you for your immediate response.

Am 02.09.26 um 09:24 schrieb Sergey Lebedev:

> Two of your three points I can answer from the hardware, since the
> Tested-by on this patch is mine.
> 
>> Can you reproduce this on real hardware?
> 
> Yes. Surface Pro 11 (Intel, Lunar Lake), Intel BE201, 8086:a876 rev 10.
> It first appeared in ordinary use, not in a test:
> 
>    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 returns -16
>    PM: Some devices failed to suspend, or early wake event detected
> 
> One device returning -EBUSY aborts the whole system suspend, so the
> machine does not sleep at all.
> 
> I have to be honest about the rate rather than useful: it failed on 2 of
> the 3 suspends I attempted before installing a workaround, and later, on
> a newer kernel with the workaround removed, it succeeded 7 times out of 7
> with no btintel_pcie change in between. So the spontaneous failure is not
> something I can produce on demand.
> 
> What I could do was exercise the exact path deterministically. I built
> the driver out of tree with one debug-only parameter that returns from
> btintel_pcie_msix_gp0_handler() before the boot_stage_cache refresh, and
> only while alive_intr_ctxt is BTINTEL_PCIE_D0. That leaves the cache
> stale and gp0_received false — precisely the state a genuinely missed
> alive interrupt leaves behind — while the controller still reaches D3.
> 
> Without the patch, that reproduces the production failure exactly: three
> timeouts, -EBUSY, suspend aborted. With the patch and nothing else
> changed: one timeout, the re-read observes D3, set_dxstate() returns 0,
> and the system suspends and resumes normally.
> 
> Full method and logs are in my earlier message on this thread,
> Message-ID <20260830151550.44687-1-lsa.uz@pm.me>.

It’d be great if the thread could be referenced via Link: tag, and also 
the problem summarized in the commit message including the log messages.

>> To me it sounds strange, that a register name *boot stage* should
>> change after the boot. ;-)
> 
> It is a fair reaction to the name, but the register genuinely carries
> live power state. From the driver's own header:
> 
>    #define BTINTEL_PCIE_CSR_BOOT_STAGE_D3_STATE_READY  (BIT(24))
> 
> and both helpers test that one bit and nothing else:
> 
>    static bool btintel_pcie_in_d3(struct btintel_pcie_data *data)
>    {
>        return data->boot_stage_cache & BTINTEL_PCIE_CSR_BOOT_STAGE_D3_STATE_READY;
>    }
> 
>    static bool btintel_pcie_in_d0(struct btintel_pcie_data *data)
>    {
>        return !(data->boot_stage_cache & BTINTEL_PCIE_CSR_BOOT_STAGE_D3_STATE_READY);
>    }
> 
> So bit 24 is updated by the controller on every D-state transition, long
> after boot. The name describes the register's original purpose rather
> than everything Intel later put in it. btintel_pcie_resume() already
> re-reads it for exactly this reason, which is what makes the patch's
> change consistent rather than novel.

Maybe a comment could be added above the macro definition.

> The re-flow is Vladimir's call and I have no opinion on it. If a v3 comes
> out of this, I still have the hardware and the test fixture and will
> re-run both halves against it.

Awesome.

Also note, gemini/gemini-3.1-pro-preview found the same issue in a 
different review [1].


Kind regards,

Paul


[1]: 
https://sashiko.dev/#/patchset/20260902042840.2432862-1-ravindra%40intel.com

Re: [PATCH] Bluetooth: btintel_pcie: fix stale cache in set_dxstate fallback check

[Sergey Lebedev]

Paul,

Thank you for the pointer — it was the useful part of your mail.

Ravindra's patch changes the same function, and the two turn out to fix
different halves of one failure: his makes a *late* alive interrupt count
by moving the flag out of the retry loop, while Vladimir's makes a
*missing* one survivable, because the fallback check still reads the
stale boot_stage_cache. The hunks also sit on adjacent lines, so whichever
lands second will need a rebase.

I have followed that up in Ravindra's thread rather than here, since it
concerns his patch:

  Message-ID <20260902091021.20160-1-lsa.uz@pm.me>

There I report what our test fixture does under each patch, and offer to
assemble the two as a series if both authors would rather have it that way.

Your other two points — the Link: tag with a fuller commit message, and a
comment above the macro definition — are Vladimir's to act on, and I have
no opinion to add beyond agreeing they would help.

Thanks,
Sergey

[PATCH v3] Bluetooth: btintel_pcie: fix stale cache in set_dxstate fallback check

[Vladimir V. Kondratyev]

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 fda474406003..e13631e94214 100644
--- a/drivers/bluetooth/btintel_pcie.c
+++ b/drivers/bluetooth/btintel_pcie.c
@@ -2777,10 +2777,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 2db85f71b2f8..f287d1ff8e27 100644
--- a/drivers/bluetooth/btintel_pcie.h
+++ b/drivers/bluetooth/btintel_pcie.h
@@ -53,6 +53,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))
 
 /* Registers for MSI-X */
-- 
2.55.0

Re: [PATCH v3] Bluetooth: btintel_pcie: fix stale cache in set_dxstate fallback check

[Paul Menzel]

Dear Vladimir,


Thank you for the third patch iteration.

Am 03.09.26 um 16:29 schrieb Vladimir V. Kondratyev:
> 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 fda474406003..e13631e94214 100644
> --- a/drivers/bluetooth/btintel_pcie.c
> +++ b/drivers/bluetooth/btintel_pcie.c
> @@ -2777,10 +2777,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 2db85f71b2f8..f287d1ff8e27 100644
> --- a/drivers/bluetooth/btintel_pcie.h
> +++ b/drivers/bluetooth/btintel_pcie.h
> @@ -53,6 +53,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))
>   
>   /* Registers for MSI-X */

Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>


Kind regards,

Paul

RE: [v3] Bluetooth: btintel_pcie: fix stale cache in set_dxstate fallback check

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 565 bytes --]

This is an automated email and please do not reply to this email.

Dear Submitter,

Thank you for submitting the patches to the linux bluetooth mailing list.
While preparing the CI tests, the patches you submitted couldn't be applied to the current HEAD of the repository.

----- Output -----

error: patch failed: drivers/bluetooth/btintel_pcie.h:53
error: drivers/bluetooth/btintel_pcie.h: patch does not apply
hint: Use 'git am --show-current-patch' to see the failed patch

Please resolve the issue and submit the patches again.


---
Regards,
Linux Bluetooth

[PATCH v3] Bluetooth: btintel_pcie: fix stale cache in set_dxstate fallback check

[Vladimir V. Kondratyev]

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

Re: [PATCH v3] Bluetooth: btintel_pcie: fix stale cache in set_dxstate fallback check

[Sergey Lebedev]

Vladimir, Paul,

Thank you for the quick turnaround, and for putting the D-state note in the
header — it says in one line what took me a paragraph.

Two things about v3, since my Tested-by rides on it.

The tag still holds for this revision, and not only by inspection. Between
the revision I tested and v3, the only changes are the comment wording in
btintel_pcie.c and the new comment in btintel_pcie.h. Built out of tree
from the same 7.0.0 driver, both revisions produce a .text section of
21048 bytes with the same MD5, and btintel_pcie_set_dxstate disassembles
to the same 116 instructions; only debug sections differ, by 8 bytes, from
the shifted line numbers. So the object code I exercised on the hardware
is the object code v3 produces.

The CI failure in this thread is against the 14:29 posting, whose header
hunk was cut at line 53. The 15:35 resend applies cleanly to
bluetooth-next at 6696072ffe07 — checked with git apply, and it produces
the diffstat the patch declares. As of 17:15 UTC the resend has had no CI
reply, where the earlier posting had one within eighteen minutes, so it
may be worth confirming it was picked up as a new revision.

Sergey

RE: [v3] Bluetooth: btintel_pcie: fix stale cache in set_dxstate fallback check

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 2635 bytes --]

This is automated email and please do not reply to this email!

Dear submitter,

Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=1157226

---Test result---

Test Summary:
CheckPatch                    FAIL      0.97 seconds
VerifyFixes                   PASS      0.13 seconds
VerifySignedoff               PASS      0.13 seconds
GitLint                       FAIL      0.34 seconds
SubjectPrefix                 PASS      0.13 seconds
BuildKernel                   PASS      26.99 seconds
CheckAllWarning               PASS      29.40 seconds
CheckSparse                   PASS      28.36 seconds
BuildKernel32                 PASS      25.69 seconds
CheckKernelLLVM               SKIP      0.00 seconds
TestRunnerSetup               PASS      474.96 seconds
IncrementalBuild              PASS      24.73 seconds

Details
##############################
Test: CheckPatch - FAIL
Desc: Run checkpatch.pl script
Output:
[v3] Bluetooth: btintel_pcie: fix stale cache in set_dxstate fallback check
WARNING: Prefer a maximum 75 chars per line (possible unwrapped commit description?)
#113: 
operation to abort on Intel Lunar Lake hardware. The system immediately resumes

total: 0 errors, 1 warnings, 22 lines checked

NOTE: For some of the reported defects, checkpatch may be able to
      mechanically convert to the typical style using --fix or --fix-inplace.

/github/workspace/src/patch/14788135.patch has style problems, please review.

NOTE: Ignored message types: UNKNOWN_COMMIT_ID

NOTE: If any of the errors are false positives, please report
      them to the maintainer, see CHECKPATCH in MAINTAINERS.


##############################
Test: GitLint - FAIL
Desc: Run gitlint
Output:
[v3] Bluetooth: btintel_pcie: fix stale cache in set_dxstate fallback check

6: B1 Line exceeds max length (82>80): "  Bluetooth: hci0: Timeout (200 ms) on alive interrupt for D2 entry, retry count 0"
7: B1 Line exceeds max length (82>80): "  Bluetooth: hci0: Timeout (200 ms) on alive interrupt for D2 entry, retry count 1"
8: B1 Line exceeds max length (82>80): "  Bluetooth: hci0: Timeout (200 ms) on alive interrupt for D2 entry, retry count 2"
9: B1 Line exceeds max length (98>80): "  btintel_pcie 0000:00:14.7: PM: pci_pm_suspend(): btintel_pcie_suspend [btintel_pcie] returns -16"
##############################
Test: CheckKernelLLVM - SKIP
Desc: Build kernel with LLVM + context analysis
Output:
Clang not found


https://github.com/bluez/bluetooth-next/pull/697

---
Regards,
Linux Bluetooth

Re: [v3] Bluetooth: btintel_pcie: fix stale cache in set_dxstate fallback check

[Paul Menzel]

Am 03.09.26 um 20:40 schrieb bluez.test.bot@gmail.com:
> This is automated email and please do not reply to this email!
> 
> Dear submitter,
> 
> Thank you for submitting the patches to the linux bluetooth mailing list.
> This is a CI test results with your patch series:
> PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=1157226
> 
> ---Test result---
> 
> Test Summary:
> CheckPatch                    FAIL      0.97 seconds
> VerifyFixes                   PASS      0.13 seconds
> VerifySignedoff               PASS      0.13 seconds
> GitLint                       FAIL      0.34 seconds
> SubjectPrefix                 PASS      0.13 seconds
> BuildKernel                   PASS      26.99 seconds
> CheckAllWarning               PASS      29.40 seconds
> CheckSparse                   PASS      28.36 seconds
> BuildKernel32                 PASS      25.69 seconds
> CheckKernelLLVM               SKIP      0.00 seconds
> TestRunnerSetup               PASS      474.96 seconds
> IncrementalBuild              PASS      24.73 seconds
> 
> Details
> ##############################
> Test: CheckPatch - FAIL
> Desc: Run checkpatch.pl script
> Output:
> [v3] Bluetooth: btintel_pcie: fix stale cache in set_dxstate fallback check
> WARNING: Prefer a maximum 75 chars per line (possible unwrapped commit description?)
> #113:
> operation to abort on Intel Lunar Lake hardware. The system immediately resumes

`scripts/checkpatch.pl` ignores lines that start with the “timestamp”.

```
# Check for line lengths > 75 in commit log, warn once
                 if ($in_commit_log && !$commit_log_long_line &&
                     length($line) > 75 &&
                     !($line =~ /^\s*[a-zA-Z0-9_\/\.]+\s+\|\s+\d+/ ||
                                         # file delta changes
                       $line =~ /^\s*(?:[\w\.\-\+]*\/)++[\w\.\-\+]+:/ ||
                                         # filename then :
                       $line =~ 
/^\s*(?:Fixes:|https?:|$link_tags_search|$signature_tags)/i ||
                                         # A Fixes:, link or signature 
tag line
                       $commit_log_possible_stack_dump)) {
                         WARN("COMMIT_LOG_LONG_LINE",
                              "Prefer a maximum 75 chars per line 
(possible unwrapped commit description?)\n" . $herecurr);
                         $commit_log_long_line = 1;
                 }
```

[…]

> ##############################
> Test: GitLint - FAIL
> Desc: Run gitlint
> Output:
> [v3] Bluetooth: btintel_pcie: fix stale cache in set_dxstate fallback check
> 
> 6: B1 Line exceeds max length (82>80): "  Bluetooth: hci0: Timeout (200 ms) on alive interrupt for D2 entry, retry count 0"
> 7: B1 Line exceeds max length (82>80): "  Bluetooth: hci0: Timeout (200 ms) on alive interrupt for D2 entry, retry count 1"
> 8: B1 Line exceeds max length (82>80): "  Bluetooth: hci0: Timeout (200 ms) on alive interrupt for D2 entry, retry count 2"
> 9: B1 Line exceeds max length (98>80): "  btintel_pcie 0000:00:14.7: PM: pci_pm_suspend(): btintel_pcie_suspend [btintel_pcie] returns -16"

I believe the configuration in the BlueZ git archive [1] is used. No 
idea, how other commits with pasted lines entered the tree.


Kind regards,

Paul


[1]: https://github.com/bluez/bluez/blob/master/.gitlint

[PATCH v4] Bluetooth: btintel_pcie: fix stale cache in set_dxstate fallback check

[Vladimir V. Kondratyev]

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

Re: [PATCH v4] Bluetooth: btintel_pcie: fix stale cache in set_dxstate fallback check

[Sergey Lebedev]

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

RE: [PATCH v4] Bluetooth: btintel_pcie: fix stale cache in set_dxstate fallback check

[K, Kiran]

+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

RE: [v4] Bluetooth: btintel_pcie: fix stale cache in set_dxstate fallback check

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 1181 bytes --]

This is automated email and please do not reply to this email!

Dear submitter,

Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=1157358

---Test result---

Test Summary:
CheckPatch                    PASS      0.98 seconds
VerifyFixes                   PASS      0.14 seconds
VerifySignedoff               PASS      0.14 seconds
GitLint                       PASS      0.34 seconds
SubjectPrefix                 PASS      0.13 seconds
BuildKernel                   PASS      26.26 seconds
CheckAllWarning               PASS      28.62 seconds
CheckSparse                   PASS      27.10 seconds
BuildKernel32                 PASS      24.99 seconds
CheckKernelLLVM               SKIP      0.00 seconds
TestRunnerSetup               PASS      461.42 seconds
IncrementalBuild              PASS      24.42 seconds

Details
##############################
Test: CheckKernelLLVM - SKIP
Desc: Build kernel with LLVM + context analysis
Output:
Clang not found


https://github.com/bluez/bluetooth-next/pull/699

---
Regards,
Linux Bluetooth

Re: [PATCH v4] Bluetooth: btintel_pcie: fix stale cache in set_dxstate fallback check

[Sergey Lebedev]

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

Re: [PATCH v4] Bluetooth: btintel_pcie: fix stale cache in set_dxstate fallback check

[patchwork-bot+bluetooth]

Hello:

This patch was applied to bluetooth/bluetooth-next.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:

On Thu,  3 Sep 2026 21:22:38 +0200 you wrote:
> 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
> 
> [...]

Here is the summary with links:
  - [v4] Bluetooth: btintel_pcie: fix stale cache in set_dxstate fallback check
    https://git.kernel.org/bluetooth/bluetooth-next/c/20dfccf8d854

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html

Re: btintel_pcie: hibernation intermittently aborted by -EBUSY from D3 entry timeout

[Sergey Lebedev]

Ferenc,

Two patches already on this list address exactly your signature, and they
fix different halves of it. Both are reviewed and neither has been applied
yet, so testing them is useful rather than redundant.

Your path is btintel_pcie_hibernate() -> btintel_pcie_suspend_late(
PMSG_HIBERNATE) -> btintel_pcie_set_dxstate(D3_COLD). After each 200 ms
timeout that function does not give up blindly: it falls back to asking
whether the controller reached the state anyway, because the alive
interrupt is known to go missing. The fallback is btintel_pcie_in_d3(),
which reads data->boot_stage_cache and not the register.

And boot_stage_cache is refreshed in exactly one place on this path: the
alive interrupt handler. So the fallback that exists to survive a missed
interrupt is disabled by the very miss it exists for - it re-reads a value
last written before the transition, three times, and returns -EBUSY after
the image is already on disk.

  Vladimir V. Kondratyev, v4 - re-read BOOT_STAGE_REG before the fallback
  check, so a genuinely missed interrupt becomes survivable:
  https://lore.kernel.org/linux-bluetooth/20260903192245.135310-2-vladimirkondratyev2@gmail.com/

  Ravindra (Intel), v2 - move data->gp0_received = false out of the retry
  loop, so an interrupt that arrives late is not discarded by the next
  iteration:
  https://lore.kernel.org/linux-bluetooth/20260902042840.2432862-1-ravindra@intel.com/

I reproduced your exact three-retry signature deterministically on a
Surface Pro 11 (Lunar Lake, BE201 8086:a876) by dropping the alive
interrupt on demand, and measured the two patches per hunk: with only
Ravindra's, the missed-interrupt case still fails as unpatched; with only
Vladimir's, it passes. They do not interfere. I have also seen the failure
happen on its own, injection disabled, once in six s2idle cycles.

So my guess is Vladimir's patch alone will fix your hibernation, and it
would be worth knowing. If it does not, that is more interesting still:
it would mean your controller genuinely never reaches D3, which is a
different bug from this one and worth reporting as such.

If you do test it, a Tested-by would carry real weight. Everything above
is one machine, one controller, one firmware - which I have said in every
message I have sent on this - and yours is Panther Lake with 8086:e476, a
different generation. The two patches are being combined into a single
series, so there is a window in which a second machine can still be part
of it.

Your report: 22771256-6dcb-4ab9-ae77-3a88480e7d21@lengyelf.eu

Sergey

Re: [PATCH v4] Bluetooth: btintel_pcie: fix stale cache in set_dxstate fallback check

[Ferenc Lengyel]

Hello,

I reported the intermittent hibernation abort in 
<22771256-6dcb-4ab9-ae77-3a88480e7d21@lengyelf.eu>, and Sergey asked 
whether v4 alone fixes it on my hardware. It does not. Applying v4 
together with Ravindra's "[PATCH v2] Bluetooth: btintel_pcie: fix PM 
flow for S0ix, S3 and S4" does. Details below, including a correction to 
my original report.

Hardware and software: Lenovo ThinkPad X9-15p (21VV004FHV), BIOS 
N4QET35W 1.14. Intel Panther Lake CNVi Bluetooth, 8086:e476 at 
0000:00:14.7, firmware 42-26.26 (ibt-00a0-01a1-iml.sfi then 
ibt-00a0-01a1-pci.sfi, timestamp 2026.26 build 94250). Kernel 
7.2.3-1-cachyos; drivers/bluetooth/btintel_pcie.{c,h} are byte-identical 
to upstream v7.2. Note this is a different generation from Sergey's 
Lunar Lake BE201 8086:a876.

First, a correction to my original report. I wrote that all three 
retries timed out "AND the poll also reported the controller was not in 
D3", and concluded the device genuinely did not reach D3. That inference 
was unfounded, for exactly the reason v4 exists: btintel_pcie_in_d3() 
reads data->boot_stage_cache, which on that path is only written by the 
alive interrupt handler, so after a missed interrupt it reports a value 
from before the transition. Sergey identified this. Please disregard 
that part of the report.

Results, using systemctl hibernate. The two patched arms are from a 
single boot on 7.2.3; the stock baseline is my original A/B test on 
7.2.2, where the driver files are identical:

    stock, 7.2.2                   3 aborts in 10 cycles
    stock, module unloaded         0 aborts in 10 cycles
    v4 alone, 7.2.3                2 aborts in 5 cycles
    v4 + Ravindra's v2, 7.2.3      0 aborts in 10 cycles

The v4 arm reproduced the original failure unchanged: all three retry 
counts, then -EBUSY, with the image already written.

To find out why, I built v4 with one extra bt_dev_warn immediately after 
the patch's register re-read, printing retry, boot_stage and in_d3. On a 
failing cycle it gives:

    Bluetooth: hci0: INSTR: after re-read, retry 0, boot_stage 
0x20db0001, in_d3 0
    Bluetooth: hci0: INSTR: after re-read, retry 1, boot_stage 
0x20db0001, in_d3 0
    Bluetooth: hci0: INSTR: after re-read, retry 2, boot_stage 
0x20db0001, in_d3 0

So the re-read is working and returning a live value: it is not 
0x00000000 or 0xffffffff, MAC_ACCESS_ON (bit 16) and ALIVE (bit 23) are 
set, and none of DEVICE_WARNING, ABORT_HANDLER or DEVICE_HALTED is set. 
The controller is reachable. But D3_STATE_READY (bit 24) is clear, 
identically across all three retries roughly 600 ms apart.

What 0x20db0001 is becomes clear with dynamic debug enabled on 
btintel_pcie_msix_gp0_handler, which prints the boot stage per alive 
context:

    Alive context: rom            0x20db0001    ROM set, IML and OPFW clear
    Alive context: intel_reset1   0xa0db0003    ROM, IML set
    Alive context: intel_reset1   0xa0db000f    ROM, IML, OPFW set
    Alive context: intel_reset2   0xa0db0007    ROM, IML, OPFW set
    Alive context: hci_reset      0xa0db0047    ROM, IML, OPFW set
    Alive context: d0             0x61710007    ROM, IML, OPFW and 
D3_STATE_READY set

The last row is the context in which the driver is waiting to leave D3, 
so it is also an example of D3_STATE_READY actually being set. The value 
seen at the failing D3 entry is byte-identical to the ROM-stage value. 
The controller has no firmware loaded at the moment .poweroff asks it to 
enter D3, and a ROM-stage controller does not complete the D3 handshake. 
That is a separate fault from the stale cache, which is why v4 alone 
cannot help here.

The reason it is in ROM is the driver's own .thaw callback, and the log 
ordering on a failing cycle shows it directly:

    PM: hibernation: Preallocating image memory
    PM: hibernation: Allocated 12776628 kbytes in 1.48 seconds (8632.85 
MB/s)
    printk: Suspending console(s) (use no_console_suspend to debug)
    PM: hibernation: Normal pages needed: 3179962 + 1024, available 
pages: 5078484
    btintel_pcie 0000:00:14.7: resetting
    btintel_pcie 0000:00:14.7: reset done
    Bluetooth: BT reprobe failed for BDF:0000:00:14.7
    PM: hibernation: Wrote 10837272 kbytes in 8.88 seconds (1220.41 MB/s)
    PM: Image size after compression: 3781433 kbytes
    PM: Image saving done
    printk: Suspending console(s) (use no_console_suspend to debug)
    Bluetooth: hci0: Timeout (200 ms) on alive interrupt for D3 entry, 
retry count 0
    Bluetooth: hci0: Timeout (200 ms) on alive interrupt for D3 entry, 
retry count 1
    Bluetooth: hci0: Timeout (200 ms) on alive interrupt for D3 entry, 
retry count 2
    btintel_pcie 0000:00:14.7: PM: pci_pm_poweroff(): 
btintel_pcie_hibernate [btintel_pcie] returns -16
    btintel_pcie 0000:00:14.7: PM: dpm_run_callback(): 
pci_pm_poweroff.llvm.16961064922821440386 returns -16
    btintel_pcie 0000:00:14.7: PM: failed to hibernate async: error -16
    PM: hibernation: Wakeup event detected during hibernation, rolling back.

hibernation_snapshot() runs .freeze, creates the image, then runs .thaw. 
btintel_pcie_suspend_late() has just recorded pm_sx_event = 
PM_EVENT_FREEZE, and pm_ops has .thaw = btintel_pcie_resume, so the thaw 
takes this branch:

      if (data->pm_sx_event == PM_EVENT_FREEZE ||
          data->pm_sx_event == PM_EVENT_HIBERNATE) {
          set_bit(BTINTEL_PCIE_CORE_HALTED, &data->flags);
          data->reset_type = BTINTEL_PCIE_IOSF_PRR_FLR;
          btintel_pcie_reset(data->hdev);
          return 0;
      }

The FLR drops the controller to ROM. No "Firmware loaded in ... usecs" 
line follows before the image write completes, so the firmware had not 
been reloaded by the time .poweroff asked a ROM-stage controller to 
enter D3 roughly nine seconds later. I have not established why the 
reload does not complete in that window; the freezer still being engaged 
during .thaw seems the likeliest reason, but I have not confirmed it. 
The "BT reprobe failed" line is not itself a failure marker, 
incidentally: it appears on every resume here, including ones that 
succeed. The comment above that branch justifies the reset by saying S4 
erases the loaded firmware, which is true on .restore, after power was 
actually cut, but on .thaw no power has been lost and the image has not 
even been written yet.

Ravindra's v2 removes exactly this: .thaw gets its own callback taking a 
normal D0 transition, and the FLR stays on .restore and S3 resume, which 
matches what he described on-list on 2026-09-08. With both patches 
applied I get 10 consecutive clean hibernations where v4 alone gave 2 
aborts in 5 in the same boot.

Caveats, so the numbers are not read as stronger than they are. Ten 
clean cycles against a roughly one-in-three prior failure rate is about 
a 2 percent outcome by chance; Fisher's exact test against my own 
controls (5 aborts in 15 before, 0 in 10 after) gives p ~= 0.06. It is 
consistent and it matches the mechanism, but it is not a large sample.

I could not observe the .thaw phase directly on a passing cycle. On a 
successful hibernation the restored ring buffer stops at the snapshot 
point, so everything after it, including the .thaw callback, the image 
write and the .poweroff D3 entry, is discarded. Worth flagging for 
anyone trying to test this: pm_test is not a way around that either. In 
hibernation_snapshot(), create_image() never runs on the TEST_DEVICES 
path, so in_suspend stays 0 and dpm_resume() is called with PMSG_RESTORE 
rather than PMSG_THAW, which means pm_test exercises .restore and says 
nothing about .thaw.

I am happy to run more cycles, or any other instrumentation that would help.

For the combination as tested, both patches applied together:

Assisted-by: Claude:claude-opus-5
Tested-by: Ferenc Lengyel <dev@lengyelf.eu>

v4 is correct and worth keeping on its own account: the stale cache is 
real, and fixing it is what let the second fault become visible. I would 
rather not give it a bare Tested-by on this thread, though, since on 
this hardware v4 alone does not fix the reported bug.

Regards,
Ferenc Lengyel

Re: [PATCH v4] Bluetooth: btintel_pcie: fix stale cache in set_dxstate fallback check

[Sergey Lebedev]

Ferenc,

I owe you a plain acknowledgement: I told you my guess was that v4 alone would
fix your hibernation, and it did not. You checked instead of taking my word for
it, then instrumented the re-read and found the actual second fault - .thaw
running an FLR that leaves the controller in ROM when .poweroff asks it for D3
nine seconds later. That is the mechanism, and it is not one I would have got
to from this machine, where the failure is on s2idle and looks nothing like it.

The series went out yesterday with both patches:

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

Your Tested-by is on 2/2 and deliberately not on 1/2, which is how you asked
for it: a tag on patch N means the tree with 1..N applied, so 2/2 is the one
that carries "the pair, tested". Your Assisted-by went with it, in your order.
Your own caveat about ten cycles against a one-in-three rate - Fisher p ~ 0.06 -
is quoted in the cover letter in your words rather than summarised away.

Nothing needed from you. If the maintainers ask for more cycles I will say so
here rather than assume you are available.

Sergey