From: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
To: Scot Doyle <lkml14@scotdoyle.com>
Cc: Peter Huewe <peterhuewe@gmx.de>,
Ashley Lai <ashley@ashleylai.com>,
Marcel Selhorst <tpmdd@selhorst.net>,
Stefan Berger <stefanb@linux.vnet.ibm.com>,
tpmdd-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] tpm_tis: Verify ACPI-specified interrupt
Date: Fri, 22 Aug 2014 14:32:41 -0600 [thread overview]
Message-ID: <20140822203241.GB1733@obsidianresearch.com> (raw)
In-Reply-To: <alpine.LNX.2.11.1408221924070.1046@localhost.localdomain>
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
next prev parent reply other threads:[~2014-08-22 20:32 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-22 0:58 Scot Doyle
2014-08-22 16:06 ` Jason Gunthorpe
2014-08-22 20:17 ` Scot Doyle
2014-08-22 20:32 ` Jason Gunthorpe [this message]
2014-08-22 22:48 ` Peter Hüwe
2014-08-25 6:38 ` Scot Doyle
2014-08-25 18:24 ` Jason Gunthorpe
2014-08-27 4:31 ` [RFC PATCH v2] tpm_tis: verify interrupt during init Scot Doyle
2014-08-27 17:31 ` Jason Gunthorpe
2014-08-27 21:32 ` [RFC PATCH v3] " Scot Doyle
2014-08-27 21:47 ` Jason Gunthorpe
2014-08-28 0:35 ` Scot Doyle
2014-08-28 16:53 ` Jason Gunthorpe
2014-08-29 23:59 ` [RFC PATCH v4] " Scot Doyle
2014-08-30 17:49 ` Jason Gunthorpe
2014-08-30 23:23 ` [RFC PATCH v5] " Scot Doyle
2014-09-02 17:20 ` Jason Gunthorpe
2014-09-02 20:22 ` [RFC PATCH v6] " Scot Doyle
2014-09-08 22:02 ` Jason Gunthorpe
2014-09-09 2:13 ` [PATCH v7] " Scot Doyle
2014-09-09 3:12 ` Scot Doyle
2014-09-11 0:50 ` [RFC PATCH v8] " Scot Doyle
2014-09-16 23:36 ` Scot Doyle
2014-09-22 17:13 ` Jason Gunthorpe
2014-09-22 19:01 ` Peter Hüwe
2014-10-19 20:08 ` Scot Doyle
2014-09-23 2:44 ` Scot Doyle
2014-09-23 2:51 ` [PATCH v9] " Scot Doyle
2014-09-23 11:55 ` Scot Doyle
2014-09-23 17:12 ` [tpmdd-devel] " Stefan Berger
2014-09-24 19:38 ` Scot Doyle
2014-09-24 19:41 ` Stefan Berger
2014-09-24 22:41 ` [PATCH v10] " Scot Doyle
2014-09-29 17:24 ` Jason Gunthorpe
2014-11-30 14:24 ` Peter Hüwe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140822203241.GB1733@obsidianresearch.com \
--to=jgunthorpe@obsidianresearch.com \
--cc=ashley@ashleylai.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lkml14@scotdoyle.com \
--cc=peterhuewe@gmx.de \
--cc=stefanb@linux.vnet.ibm.com \
--cc=tpmdd-devel@lists.sourceforge.net \
--cc=tpmdd@selhorst.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®