Re: [PATCH 1/4] tpm_tis: Clean up locality release

[Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>]

On Wed, Sep 30, 2020 at 04:03:25PM -0700, James Bottomley wrote:
> On Wed, 2020-09-30 at 14:19 -0700, Jerry Snitselaar wrote:
> > James Bottomley @ 2020-09-29 15:32 MST:
> > 
> > > The current release locality code seems to be based on the
> > > misunderstanding that the TPM interrupts when a locality is
> > > released: it doesn't, only when the locality is acquired.
> > > 
> > > Furthermore, there seems to be no point in waiting for the locality
> > > to be released.  All it does is penalize the last TPM
> > > user.  However, if there's no next TPM user, this is a pointless
> > > wait and if there is
> > > a
> > > next TPM user, they'll pay the penalty waiting for the new locality
> > > (or possibly not if it's the same as the old locality).
> > > 
> > > Fix the code by making release_locality as simple write to release
> > > with no waiting for completion.
> [...]
> > My recollection is that this was added because there were some chips
> > that took so long to release locality that a subsequent
> > request_locality call was seeing the locality as already active,
> > moving on, and then the locality was getting released out from under
> > the user.
> 
> Well, I could simply dump the interrupt code, which can never work and
> we could always poll.

Side-topic: What is the benefit of using int's in a TPM driver anyway? I
have never had any interest to dive into this with tpm_crb because I
don't have the answer.

*Perhaps* in some smallest form factor battery run devices you could get
some gain in run-time power saving but usually in such situations you
use something similar to TEE to do a measured boot.

/Jarkko