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
