RE: [PATCH 2/2] Bluetooth: btintel_pcie: fix PM flow for S0ix, S3 and S4

[Ravindra]

Hi Sergey,

Thank you for running the full bench and for confirming the results.

The additional D3 branch was intended to cover exactly the resume hole you
identified: when the handler's D0 case runs before the controller reaches D3,
the context can remain D0 and the resume guard can incorrectly skip re-arming
RX. Recording D3 from the verified hardware state ensures the next D0
transition performs the required re-arm.

Your results also confirm the other parts of patch 3: missed GP0 handling,
the D3-to-D0 fallback, retry-flag reset, and preservation of the normal S4
freeze/thaw and restore flows. It is good to see HCI recover successfully in
all of those cases.

Thanks again for the detailed testing. I'll include your `Tested-by:` and
`Reviewed-by:` tags for patch 4.

Best Regards,
Ravindra

> Subject: Re: [PATCH 2/2] Bluetooth: btintel_pcie: fix PM flow for S0ix, S3 and
> S4
> 
> Ravindra,
> 
> Thank you - all four are in. I checked them in the code, with v4 applied from
> lore onto 671d566d3c3b and onto e40edfa04, where it lands identically.
> 
> Your D3 branch also closes a hole in what I proposed: if the handler's D0 case
> runs before the controller reaches D3, it breaks without recording D3, the
> context stays D0, and the guard in the D0 branch then skips the re-arm on
> resume. The bench shows it with and without your branch.
> 
> Bench: Surface Pro 11, BE201 8086:a876, the driver at bluetooth-next
> e40edfa04 against the same plus v4, one instrumented build each. "HCI ok"
> is Read Local Version returning status 0 after the cycle.
> 
>   first gp0 on D3 entry dropped, as a missed interrupt (1/4's case)
>     stock  timeouts at retries 0, 1 and 2, -EBUSY, suspend aborted,
>            HCI fails
>     v4     one timeout, D3 recorded from the register, HCI ok (2 of 2)
> 
>   handler's D0 case forced to break on suspend
>     v4 without the D3 branch   resume skips the re-arm, HCI fails
>     v4                         D3 recorded, handler re-arms on resume,
>                                HCI ok (2 of 2)
> 
>   handler's D3 case forced to break on resume
>     stock  success reported with ctxt 6 (D3), then hw exception, FLR,
>            0x0c01 tx timeout
>     v4     re-armed to ctxt 5 (D0) either way the race falls: handler
>            before the wait, 2.2 ms; during it, 208 ms; HCI ok (2 of 2)
> 
>   state check forced to fail three times on suspend
>     v4     waits=3, none skipped, 413 ms, -EBUSY as forced
> 
>   plain s2idle
>     v4     D3 in 1.5-1.6 ms, D0 in 1.5-1.7 ms, HCI ok (3 of 3)
> 
>   S4, in the kernel's suspend and test_resume hibernation modes
>     stock  .thaw goes through FLR
>     v4     .freeze: D3_COLD in 1.5-1.8 ms
>            .thaw: D0 in 1.6 ms, HCI ok after (2 of 2)
>            .restore: FLR, firmware reloaded, HCI ok (2 of 2)
> 
> S4 ran on the bench kernel, since the distribution kernel refuses it under
> Secure Boot lockdown, and without cutting power, so .poweroff is not
> covered. The firmware offers no S3.
> 
> After the FLR in .restore the log says "BT reprobe failed", on stock too; the
> device probes again about a second later and works.
> 
> Tested-by for 4/4 follows in its own thread.
> 
> Sergey