Re: Patch "tpm_tis: reserve chip for duration of tpm_tis_core_init" has been added to the 5.4-stable tree

[Dan Williams]

On Sat, Dec 28, 2019 at 9:17 AM Dan Williams <dan.j.williams@xxxxxxxxx> wrote:
>
> On Sat, Dec 28, 2019 at 7:15 AM Jarkko Sakkinen
> <jarkko.sakkinen@xxxxxxxxxxxxxxx> wrote:
> >
> > On Fri, Dec 27, 2019 at 08:11:50AM +0200, Jarkko Sakkinen wrote:
> > > Dan, please also test the branch and tell if other patches are needed.
> > > I'm a bit blind with this as I don't have direct access to the faulting
> > > hardware. Thanks. [*]
> > >
> > > [*] https://lkml.org/lkml/2019/12/27/12
> >
> > Given that:
> >
> > 1. I cannot reproduce the bug locally.
> > 2. Neither of the patches have any appropriate tags (tested-by and
> >    reviewed-by). [*]
> >
> > I'm sorry but how am I expected to include these patches?
>
> Thanks for the branch, I'll get it tested on the failing hardware.
> Might be a few days due to holiday lag.

This looked like the wrong revert to me, and testing confirms that
this does not fix the problem.

As I mentioned in the original report [1] the commit that bisect flagged was:

    5b359c7c4372 tpm_tis_core: Turn on the TPM before probing IRQ's

That commit moved tpm_chip_start() before irq probing. Commit
21df4a8b6018 "tpm_tis: reserve chip for duration of tpm_tis_core_init"
does not appear to change anything in that regard.

Perhaps this hardware has always had broken interrupts and needs to be
quirked off? I'm trying an experiment with tpm_tis_core.interrupts=0
workaround.


[1]: https://lore.kernel.org/linux-integrity/CAA9_cmeLnHK4y+usQaWo72nUG3RNsripuZnS-koY4XTRC+mwJA@xxxxxxxxxxxxxx/