[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160715025026.GA21375@apronin>
Date: Thu, 14 Jul 2016 19:50:26 -0700
From: Andrey Pronin <apronin@...omium.org>
To: Peter Huewe <peterhuewe@....de>
Cc: Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
Marcel Selhorst <tpmdd@...horst.net>,
Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
tpmdd-devel@...ts.sourceforge.net, linux-kernel@...r.kernel.org,
groeck@...omium.org, smbarber@...omium.org, dianders@...omium.org
Subject: Re: [PATCH 0/2] tpm: add driver for cr50 on SPI
On Thu, Jul 14, 2016 at 07:28:55PM -0700, Peter Huewe wrote:
> Am 14. Juli 2016 19:20:16 GMT-07:00, schrieb Andrey Pronin <apronin@...omium.org>:
> >This patchset adds a TCG TPM2.0 PTP FIFO compliant interface for
> >Cr50 chip on SPI.
> >
> >Depends on the following patches by Andrey Pronin
> ><apronin@...omium.org>
> >that add new members to phy_ops in tpm_tis_core:
> > - tpm: support driver-specific sysfs attrs in tpm_tis_core
> > - tpm_tis_core: add optional max xfer size check
> >
> >Andrey Pronin (2):
> > tpm: devicetree: document properties for cr50
> > tpm: add driver for cr50 on SPI
> >
> > .../devicetree/bindings/security/tpm/cr50_spi.txt | 30 ++
> > drivers/char/tpm/Kconfig | 9 +
> > drivers/char/tpm/Makefile | 1 +
> >drivers/char/tpm/cr50_spi.c | 409
> >+++++++++++++++++++++
> > 4 files changed, 449 insertions(+)
> >create mode 100644
> >Documentation/devicetree/bindings/security/tpm/cr50_spi.txt
> > create mode 100644 drivers/char/tpm/cr50_spi.c
>
>
> Hi,
> can you explain a bit more about this device? And why it needs a special driver and cannot be handled by tpm_tis_spi if its tcg compliant?
>
> Peter
> --
> Sent from my mobile
Hi Peter,
Yes, it has a TCG-compliant interface, however, there are several things
specific to this device:
- need to ensure a certain delay between spi transactions, or else
the chip can miss several first bytes.
- if there is no spi activity for this chip, it may go to sleep, and
needs to be waken up before sending further commands.
- it has some vendor-specific registers accessible from spi bus.
All that combined to me seemed to be enough justification to add a
device-specific driver rather than adding vendor-specific code to
tpm_tis_spi in multiple places.
Plus, where it seemed appropriate, I added additional hooks to
tpm_tis_core (device-specific sysfs attributes, capping burstcnt
in case of chip error) to support this chip specifics.
Best regards,
Andrey
Powered by blists - more mailing lists