From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752933AbcGTCeu (ORCPT ); Tue, 19 Jul 2016 22:34:50 -0400 Received: from mail-pf0-f174.google.com ([209.85.192.174]:33549 "EHLO mail-pf0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752512AbcGTCeY (ORCPT ); Tue, 19 Jul 2016 22:34:24 -0400 From: Andrey Pronin To: Jarkko Sakkinen Cc: Peter Huewe , Marcel Selhorst , Jason Gunthorpe , tpmdd-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org, Christophe Ricard , Andrey Pronin Subject: [PATCH v2 1/2] tpm_tis_core: add optional max xfer size check Date: Tue, 19 Jul 2016 19:34:19 -0700 Message-Id: X-Mailer: git-send-email 2.8.0.rc3.226.g39d4020 In-Reply-To: References: <1468546745-14646-1-git-send-email-apronin@chromium.org> In-Reply-To: References: <1468546745-14646-1-git-send-email-apronin@chromium.org> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org If tpm reports a bigger burstcnt than allowed by the physical protocol, re-query the burstcnt and correct, if needed, if still too large. In practice, seen in case of xfer issues (e.g. in spi interface case, lost header causing flow control issues and wrong values returned on read from TPM_STS). Without catching, causes the physical layer to reject xfer, while is easily preventable by re-querying TPM_STS. Signed-off-by: Andrey Pronin --- drivers/char/tpm/tpm_tis_core.c | 18 ++++++++++++++++-- drivers/char/tpm/tpm_tis_core.h | 1 + 2 files changed, 17 insertions(+), 2 deletions(-) diff --git a/drivers/char/tpm/tpm_tis_core.c b/drivers/char/tpm/tpm_tis_core.c index d66f51b..ffc1acb 100644 --- a/drivers/char/tpm/tpm_tis_core.c +++ b/drivers/char/tpm/tpm_tis_core.c @@ -158,6 +158,7 @@ static int get_burstcount(struct tpm_chip *chip) unsigned long stop; int burstcnt, rc; u32 value; + bool retry_burstcnt = false; /* wait for burstcount */ /* which timeout value, spec has 2 answers (c & d) */ @@ -168,8 +169,21 @@ static int get_burstcount(struct tpm_chip *chip) return rc; burstcnt = (value >> 8) & 0xFFFF; - if (burstcnt) - return burstcnt; + if (burstcnt) { + /* If burstcnt is larger than max allowed xfer + * size, retry once - may be a glitch. Return + * max_xfer_size on the 2nd try to avoid being + * stuck forever. + */ + if ((priv->phy_ops->max_xfer_size == 0) || + (burstcnt <= priv->phy_ops->max_xfer_size)) + return burstcnt; + if (retry_burstcnt) + return priv->phy_ops->max_xfer_size; + dev_warn(&chip->dev, + "Bad burstcnt read: %d\n", burstcnt); + retry_burstcnt = true; + } msleep(TPM_TIMEOUT); } while (time_before(jiffies, stop)); return -EBUSY; diff --git a/drivers/char/tpm/tpm_tis_core.h b/drivers/char/tpm/tpm_tis_core.h index 9191aab..58e8b14 100644 --- a/drivers/char/tpm/tpm_tis_core.h +++ b/drivers/char/tpm/tpm_tis_core.h @@ -102,6 +102,7 @@ struct tpm_tis_phy_ops { int (*read16)(struct tpm_tis_data *data, u32 addr, u16 *result); int (*read32)(struct tpm_tis_data *data, u32 addr, u32 *result); int (*write32)(struct tpm_tis_data *data, u32 addr, u32 src); + u16 max_xfer_size; }; static inline int tpm_tis_read_bytes(struct tpm_tis_data *data, u32 addr, -- 2.6.6 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrey Pronin Subject: [PATCH v2 1/2] tpm_tis_core: add optional max xfer size check Date: Tue, 19 Jul 2016 19:34:19 -0700 Message-ID: References: <1468546745-14646-1-git-send-email-apronin@chromium.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: In-Reply-To: References: <1468546745-14646-1-git-send-email-apronin-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tpmdd-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: Jarkko Sakkinen Cc: Christophe Ricard , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: tpmdd-devel@lists.sourceforge.net If tpm reports a bigger burstcnt than allowed by the physical protocol, re-query the burstcnt and correct, if needed, if still too large. In practice, seen in case of xfer issues (e.g. in spi interface case, lost header causing flow control issues and wrong values returned on read from TPM_STS). Without catching, causes the physical layer to reject xfer, while is easily preventable by re-querying TPM_STS. Signed-off-by: Andrey Pronin --- drivers/char/tpm/tpm_tis_core.c | 18 ++++++++++++++++-- drivers/char/tpm/tpm_tis_core.h | 1 + 2 files changed, 17 insertions(+), 2 deletions(-) diff --git a/drivers/char/tpm/tpm_tis_core.c b/drivers/char/tpm/tpm_tis_core.c index d66f51b..ffc1acb 100644 --- a/drivers/char/tpm/tpm_tis_core.c +++ b/drivers/char/tpm/tpm_tis_core.c @@ -158,6 +158,7 @@ static int get_burstcount(struct tpm_chip *chip) unsigned long stop; int burstcnt, rc; u32 value; + bool retry_burstcnt = false; /* wait for burstcount */ /* which timeout value, spec has 2 answers (c & d) */ @@ -168,8 +169,21 @@ static int get_burstcount(struct tpm_chip *chip) return rc; burstcnt = (value >> 8) & 0xFFFF; - if (burstcnt) - return burstcnt; + if (burstcnt) { + /* If burstcnt is larger than max allowed xfer + * size, retry once - may be a glitch. Return + * max_xfer_size on the 2nd try to avoid being + * stuck forever. + */ + if ((priv->phy_ops->max_xfer_size == 0) || + (burstcnt <= priv->phy_ops->max_xfer_size)) + return burstcnt; + if (retry_burstcnt) + return priv->phy_ops->max_xfer_size; + dev_warn(&chip->dev, + "Bad burstcnt read: %d\n", burstcnt); + retry_burstcnt = true; + } msleep(TPM_TIMEOUT); } while (time_before(jiffies, stop)); return -EBUSY; diff --git a/drivers/char/tpm/tpm_tis_core.h b/drivers/char/tpm/tpm_tis_core.h index 9191aab..58e8b14 100644 --- a/drivers/char/tpm/tpm_tis_core.h +++ b/drivers/char/tpm/tpm_tis_core.h @@ -102,6 +102,7 @@ struct tpm_tis_phy_ops { int (*read16)(struct tpm_tis_data *data, u32 addr, u16 *result); int (*read32)(struct tpm_tis_data *data, u32 addr, u32 *result); int (*write32)(struct tpm_tis_data *data, u32 addr, u32 src); + u16 max_xfer_size; }; static inline int tpm_tis_read_bytes(struct tpm_tis_data *data, u32 addr, -- 2.6.6 ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports.http://sdm.link/zohodev2dev