Re: [BUG] tpm_crb/Intel PTT: Late S3/S5/Reboot ACPI power management deadlock

[Sean Meadows <Hellfire@unspacy.com>]

On 10/8/26 16:00, Mario Limonciello wrote:
>> The patch I pointed out this in bugzilla but the patch I had in mind
>> is:
>> 
>> "tpm: Call cmd_ready/go_idle for each command transmission"
>> 
>> Link: https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux- 
>> tpmdd.git/commit/?id=9154aa6c4b789d23e59d599c330cab2c4e915401
>> 
>> The reason is that the commit message highlight a bit similar issues
>> as reported in the bug.
>> 
>> Note commit IDs do change in my master branch so best is to look it
>> up from:
>> 
>> https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux- tpmdd.git/
>> log/
>> 
>> Right another reason is that then the driver always the TPM in the
>> state as it is when the driver starts.
>> 
>> I'm not sure about Windows but neither disregard it as sometimes we
>> do pick behavior basing it on how Window does it. I'd still try
>> Mario's patch at first.

Checking my notes, I cherry-picked commit 
19931faa1d75fb858d86aaf5b0e79d34a2379094, which I understood to be v3 of 
the patch.

Assuming I made a mistake there, I've started from scratch and applied 
commit 9154aa6c4b789d23e59d599c330cab2c4e915401 instead, which should be v6.

Once the compile and install are complete, it will take at least a 
couple of days of testing to determine whether it prevents the corrupted 
state.

> FWIW the issue my patch fixed manifested at bootup; but I definitely agree
> with Jarkko's hypothesis that it could apply to other TPM implementations
> and at different times.
> 
> When you tested Adam's patch I would like to point out it only 
> automatically applies to one board: "TUF GAMING B460M-PLUS".
> 
> If that doesn't match your board you would need to set 
> tpm.sleep_locality_preserve=1 for it to apply.
> 
> If you're sure my patch alone isn't enough to fix it you might try 
> combining patches and setting that.

When I ported Mr. Alves's patch forward, I altered it to enable globally 
rather than targeting a specific board, so I was cognizant of that 
hardware-matching pitfall. After booting, I also verified via `cat 
/sys/...` that the parameter was live.

That said, I am not entirely confident that Mr. Alves's patch is the 
correct path forward. Even he discovered that it merely extended the 
time until failure:

https://lore.kernel.org/all/
CAHwaaX8bWOFW2bi6tKpxgf2Cp_vKg5Eqhq618VEur98s+OmD=A@mail.gmail.com/

His last message on the topic indicated he was heading in a different
direction—stating he would submit a separate patch if it bore fruit. As
far as I can tell, that follow-up patch never materialized, though I
cannot say whether he simply got busy or if it ultimately failed to
solve the problem:

https://lore.kernel.org/all/CAHwaaX-
j37rq4+DCNSRAgPmeQmrYZiX2sLv4ugBjPJSj9LPxcg@mail.gmail.com/#t

Sean