Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753702AbZIXSnV (ORCPT ); Thu, 24 Sep 2009 14:43:21 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753644AbZIXSnT (ORCPT ); Thu, 24 Sep 2009 14:43:19 -0400 Received: from e24smtp01.br.ibm.com ([32.104.18.85]:54956 "EHLO e24smtp01.br.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753313AbZIXSnO (ORCPT ); Thu, 24 Sep 2009 14:43:14 -0400 Subject: Re: [PATCH] tpm_tis: TPM_STS_DATA_EXPECT workaround From: Rajiv Andrade To: Seiji Munetoh Cc: akpm@linux-foundation.org, Daniel Walker , Andy Isaacson , jmorris@namei.org, len.brown@intel.com, Alan Cox , Andy Isaacson , linux-kernel@vger.kernel.org, tpmdd-devel@lists.sourceforge.net, dds@google.com, Mimi Zohar , Shahbaz Khan In-Reply-To: References: <1246410255-6839-1-git-send-email-adi@vmware.com> <1246410255-6839-6-git-send-email-adi@vmware.com> <20090701110136.576a1d14@lxorguk.ukuu.org.uk> <1246455920.9140.28.camel@blackbox> <20090720182732.GL6370@hexapodia.org> <1252609714.4837.87.camel@blackbox> <1252612471.4837.107.camel@blackbox> <1252612709.30578.219.camel@desktop> <1252613375.4837.121.camel@blackbox> Content-Type: text/plain Date: Thu, 24 Sep 2009 15:43:01 -0300 Message-Id: <1253817781.8653.3.camel@dyn531367.br.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.26.2 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3408 Lines: 83 This was already tested and, given no more comments on it, finally reviewed. Can it already be merged? Thanks, Rajiv On Sat, 2009-09-12 at 08:34 +0900, Seiji Munetoh wrote: > On Fri, Sep 11, 2009 at 5:09 AM, Rajiv Andrade > wrote: > > Some newer Lenovo models are shipped with a TPM that doesn't seem to set the TPM_STS_DATA_EXPECT status bit > > when sending it a burst of data, so the code understands it as a failure and doesn't proceed sending the chip > > the intended data. In this patch we bypass this bit check in case the itpm module parameter was set. > > > > This patch is based on Andy Isaacson's one: > > > > http://marc.info/?l=linux-kernel&m=124650185023495&w=2 > > > > It was heavily discussed how should we deal with identifying the chip in kernel space, but the required > > patch to do so was NACK'd: > > > > http://marc.info/?l=linux-kernel&m=124650186423711&w=2 > > > > This way we let the user choose using this workaround or not based on his > > observations on this code behavior when trying to use the TPM. > > > > Fixed a checkpatch issue present on the previous patch, thanks to Daniel Walker. > > > > Signed-off-by: Rajiv Andrade > > As far as I know, only the intel tpm has this PNP issue, so I'm fine with it. > > Tested-by: Seiji Munetoh > > > --- > > diff --git a/drivers/char/tpm/tpm_tis.c b/drivers/char/tpm/tpm_tis.c > > index aec1931..c9990db 100644 > > --- a/drivers/char/tpm/tpm_tis.c > > +++ b/drivers/char/tpm/tpm_tis.c > > @@ -257,6 +257,10 @@ out: > > return size; > > } > > > > +static int itpm; > > +module_param(itpm, bool, 0444); > > +MODULE_PARM_DESC(itpm, "Force iTPM workarounds (found on some Lenovo laptops)"); > > + > > /* > > * If interrupts are used (signaled by an irq set in the vendor structure) > > * tpm.c can skip polling for the data to be available as the interrupt is > > @@ -293,7 +297,7 @@ static int tpm_tis_send(struct tpm_chip *chip, u8 *buf, size_t len) > > wait_for_stat(chip, TPM_STS_VALID, chip->vendor.timeout_c, > > &chip->vendor.int_queue); > > status = tpm_tis_status(chip); > > - if ((status & TPM_STS_DATA_EXPECT) == 0) { > > + if (!itpm && (status & TPM_STS_DATA_EXPECT) == 0) { > > rc = -EIO; > > goto out_err; > > } > > @@ -467,6 +471,10 @@ static int tpm_tis_init(struct device *dev, resource_size_t start, > > "1.2 TPM (device-id 0x%X, rev-id %d)\n", > > vendor >> 16, ioread8(chip->vendor.iobase + TPM_RID(0))); > > > > + if (itpm) > > + dev_info(dev, "Intel iTPM workaround enabled\n"); > > + > > + > > /* Figure out the capabilities */ > > intfcaps = > > ioread32(chip->vendor.iobase + > > > > > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/