On Thu, Oct 08, 2026 at 05:56:10PM -0400, Sean Meadows wrote:
> 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.

So the gist why I believe that this might have effect is that every
transmit reverts the state to the initial state. That should erase
any weird state that firmware might be in (usually not that great
quality code).

I think Mario's patch is good overall for the stability. It looks to
me that we are catching some weird state inside firmware where
we don't have direct visibility. Or this is my guess at least.

Br, Jarkko

Reply via email to