Re: [PATCH] tpm_tis: Verify ACPI-specified interrupt

From: Peter Hüwe
Date: Fri Aug 22 2014 - 18:48:29 EST


CC: Luigi, he works at Google and is responsible for the TPMs in
Chromebooks ;)

Thanks,
Peter

Am Freitag, 22. August 2014, 22:32:41 schrieb Jason Gunthorpe:
> On Fri, Aug 22, 2014 at 08:17:27PM +0000, Scot Doyle wrote:
> > On Fri, 22 Aug 2014, Jason Gunthorpe wrote:
> > > On Fri, Aug 22, 2014 at 12:58:41AM +0000, Scot Doyle wrote:
> > >> Some machines, such as the Acer C720 and Toshiba CB35, have
TPMs
> > >> that do not use interrupts while also having an ACPI TPM
entry
> > >
> > > How do these machines work in Windows?
> >
> > I don't know. Since they're Chromebooks (booted in legacy mode
running
> > SeaBIOS instead of depthcharge or whatever ChromeOS uses), I
think
> > they're mostly used to run Linux.
>
> I remain somewhat confused - there have already been TPM patches
for
> Chromebooks from Google - presumably the TPM actually does work
> fine. Make sure you are using a Linux with the ATMEL timeout fix,
that
> is particularly applicable to Chromebooks IIRC.
>
> And again, the driver uses interrupts when booting, so I'm
somewhat
> confused what the problem is. I wouldn't think the driver would
> successfully attach if interrupts were enabled but the interrupt
> didn't work? Can you elaborate on what is going on during boot
with
> the interrupt, and the boot time GET_DURATIONS and TPM_STARTUP
> sequences?
>
> Perhaps the driver is timing out all commands and going ahead and
> attaching anyhow? If this is the case I think we'd get a good
result
> if we just fixed that and had the driver simply not attach. Then
your
> resume will not be broken.
>
> > > I'd be more comfortable with some kind of ACPI black list or
patch or
> > > something? What is normal for handling broken ACPI?
> >
> > I would be more comfortable with this general approach as well.
However,
> > I've had to submit several patches for individual Chromebooks
related to
> > backlight control since the VBT also is misconfigured. Would it
be
> > possible to find a blacklist mechanism that didn't require
identifying
> > each Chromebook separately, since they seem to have this issue
on an
> > ongoing basis?
>
> So, if you are booting the Chromebook in some weird way, is this
a
> problem that can be addressed by patching SeaBIOS instead of the
> kernel? The internet says the SeaBIOS payload is replaceable on
the
> Chromebook.
>
> Can it fix the ACPI tables to be correct before lauching Linux?
>
> > A more general approach might be to verify the ACPI interrupt
for
> > systems matching the first three identifiers.
>
> Testing the interrupt and failing driver attach if it doesn't
work
> seems very reasonable to me, I would view that as a bug fix in
the driver.
>
> Jason

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/