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-
[email protected]/#t
Sean
