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. However, there also appears to be a bug in our locality requesting code. We write the request and wait for the grant, but a grant should be signalled by not only the ACCESS_ACTIVE_LOCALITY being 1 but also the ACCESS_REQUEST_USE going to 0. As you say, if we're slow to relinquish, ACCESS_ACTIVE_LOCALITY could already be 1 and we'd think we were granted, but ACCESS_REQUEST_USE should stay 1 until the TPM actually grants the next request. If I code up a fix is there any chance you still have access to a problem TPM? Mine all seem to grant and release localities fairly instantaneously. James
