On Tue, 2020-05-26 at 12:39 -0700, Tadeusz Struk wrote:
> On 5/26/20 12:14 PM, James Bottomley wrote:
> > + /* atomic tpm command send and result receive. We only
> > hold the ops
> > + * lock during this period so that the tpm can be
> > unregistered even if
> > + * the char dev is held open.
> > + */
> > + if (tpm_try_get_ops(priv->chip)) {
> > + ret = -EPIPE;
> > + goto out;
> > + }
> > +
>
> Hi James,
> This won't help if the message is read by an async tcti.
Why not? It moves the ops get underneath the async path, so it's now
all done in the direct read or the async read. That seems to be more
efficient.
> If the problem lies in the chip get locality code, perhaps this
> could help to debug the root-cause instead of masking it out in the
> upper layer code:
I don't think there is a root cause other than a TIS TPM is getting
annoyed by us cycling localities too rapidly because we don't do an
actual TPM operation between request and relinquish. Since the first
request/relinquish seems unnecessary for the async case, moving the ops
get eliminates the problem.
James
