Re: [PATCH v2 4/5] tpm_tis: fix IRQ probing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux Kernel]     [Linux Kernel Hardening]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux