On Fri, Nov 06, 2020 at 08:21:44AM -0800, James Bottomley wrote:
> On Fri, 2020-11-06 at 17:32 +0200, Jarkko Sakkinen wrote:
> > On Fri, Oct 30, 2020 at 02:43:35PM +0200, Jarkko Sakkinen wrote:
> > > On Sat, Oct 24, 2020 at 03:17:18PM +0300, Jarkko Sakkinen wrote:
> > > > On Mon, Oct 19, 2020 at 04:41:35PM -0700, Jerry Snitselaar wrote:
> > > > > James Bottomley @ 2020-10-01 11:09 MST:
> > > > >
> > > > > > There are two problems with our current interrupt probing:
> > > > > > firstly the TPM_CHIP_FLAG_IRQ never gets set initially, so a
> > > > > > check for interrupts is never done. Fix this by setting the
> > > > > > flag before we generate and interrupt for probing. Secondly
> > > > > > our IRQ setup may be ineffective on a TPM without legacy
> > > > > > access cycles becuase according to the TPM Interface
> > > > > > Specification the interrupt registers are only
> > > > > > writeable in the current locality, so issue a
> > > > > > request_locality before setting up the interrupts.
> > > > > >
> > > > > > Signed-off-by: James Bottomley <
> > > > > > James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
> > > > > >
> > > > > > ---
> > > > > >
> > > > > > v2: improved description
> > > > > > ---
> > > > > > drivers/char/tpm/tpm_tis_core.c | 14 ++++++++++++++
> > > > > > 1 file changed, 14 insertions(+)
> > > > > >
> > > > > > diff --git a/drivers/char/tpm/tpm_tis_core.c
> > > > > > b/drivers/char/tpm/tpm_tis_core.c
> > > > > > index 0c07da8cd680..12b657ed3a39 100644
> > > > > > --- a/drivers/char/tpm/tpm_tis_core.c
> > > > > > +++ b/drivers/char/tpm/tpm_tis_core.c
> > > > > > @@ -809,6 +809,19 @@ static int
> > > > > > tpm_tis_probe_irq_single(struct tpm_chip *chip,
> > > > > > }
> > > > > > priv->irq = irq;
> > > > > >
> > > > > > + /*
> > > > > > + * note writes to the interrupt registers are only
> > > > > > effective
> > > > > > + * when the TPM is in the active locality, so we have
> > > > > > to
> > > > > > + * request the locality here to get the interrupt set
> > > > > > up.
> > > > > > + * This request has no corresponding release, because
> > > > > > the
> > > > > > + * locality will be relinquished at the end of the tpm
> > > > > > command
> > > > > > + * that probes the interrupts
> > > > > > + */
> > > > > > + if (request_locality(chip, 0) != 0) {
> > > > > > + dev_err(&chip->dev, "failed to gain locality
> > > > > > for irq probe\n");
> > > > > > + return -EBUSY;
> > > > > > + }
> > > >
> > > > Appreciate the comment a lot, but s/note/Note/
> > >
> > > I tested this with:
> > >
> > > -
> > > https://ark.intel.com/content/www/us/en/ark/products/84861/intel-nuc-kit-nuc5i5myhe.html
> > > dTPM 1.2
> > > -
> > > https://ark.intel.com/content/www/us/en/ark/products/74483/intel-nuc-kit-dc53427hye.html
> > > dTPM 2.0
> > >
> > > I did not get "TPM interrupt not working, polling instead" to klog.
> > > But I neither see tpm0 in /proc/interrupts. What I'm doing wrong?
> >
> > With dTPM2 NUC, I ended up get this when I just pass 'irq=0' to
> > tpm_tis_core_init():
> >
> > [ 0.584421] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0x1A, rev-id
> > 16)
> > [ 0.680417] genirq: Flags mismatch irq 7. 00000008 (tpm0) vs.
> > 00040088 (INT3432:00)
> > [ 0.680448] tpm tpm0: Unable to request irq: 7 for probe
> > [ 0.704416] genirq: Flags mismatch irq 9. 00000000 (tpm0) vs.
> > 00000080 (acpi)
> > [ 0.704444] tpm tpm0: Unable to request irq: 9 for probe
>
> Well this looks normal: you forced the tis subsystem to probe for an
> IRQ even though ACPI says there isn't one and it didn't find one ... so
> ACPI was actually right (for once).
>
> James
True. I wanted to give quick feedback with the results, did not have
time to analyze at that point. Can you do one more round with remarks
fixed that I mentioned (if I recall right they were only about comments
and commit messages, code itself is in great condition), and you can add
my tested-by to each commit?
I'll put this then to my next rc request so that we get this to 5.10.
/Jarkko
