[tpmdd-devel] [PATCH v3 0/2] tpm: add driver for cr50 on SPI

This patchset adds support for H1 Secure Microcontroller running Cr50 firmware. It implements several functions, including TPM-like functionality, and communicates over SPI using the FIFO protocol described in the PTP Spec, section 6. H1 is a proprietary chip that the Chrome OS team is

[tpmdd-devel] [PATCH v3 1/2] tpm: devicetree: document properties for cr50

Add TPM2.0 PTP FIFO compatible SPI interface for chips with Cr50 firmware. Signed-off-by: Andrey Pronin --- .../devicetree/bindings/security/tpm/cr50_spi.txt | 21 + 1 file changed, 21 insertions(+) create mode 100644

[tpmdd-devel] [PATCH v3] tpm: add sysfs attributes for tpm2

Add sysfs attributes in TPM2.0 case for: - TPM_PT_PERMANENT flags - TPM_PT_STARTUP_CLEAR flags - lockout-related properties v2: Dropped adding driver-specific attributes. No legacy links for TPM2 attributes. All attributes created in groups[0]. Added actual attributes for flags and

[tpmdd-devel] [PATCH v3 0/2] tpm: add optional max xfer size check

This patchset introduces an optional maximum transfer size that can be specified by a tpm driver. Setting the max_xfer_size helps to catch the cases when burstcnt is incorrectly reported by the device (e.g. >64 for spi - happened in practice) and gracefully handle such situations. v2: removed

[tpmdd-devel] [PATCH v3 1/2] tpm_tis_core: add optional max xfer size check

If tpm reports a bigger burstcnt than allowed by the physical protocol, set burstcnt to the max allowed value. 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

[tpmdd-devel] [PATCH v3 2/2] tpm_tis_spi: add max xfer size

Reject burstcounts larger than 64 bytes reported by tpm. SPI Hardware Protocol defined in section 6.4 of TCG PTP Spec supports up to 64 bytes of data in a transaction. Signed-off-by: Andrey Pronin --- drivers/char/tpm/tpm_tis_spi.c | 1 + 1 file changed, 1 insertion(+)

Re: [tpmdd-devel] Regarding recently Added TPM2.0 support to the Nuvoton i2c driver

On Wed, Jul 27, 2016 at 10:31:52AM -0600, Jason Gunthorpe wrote: > On Wed, Jul 27, 2016 at 11:05:14AM -0500, George Wilson wrote: > > > > Yes, generally Linux expects DT to be set correctly by the boot > > > firmware. Early firmware needs to know the TPM type anyhow to do the > > > TPM setup, so

Re: [tpmdd-devel] [PATCH v2 0/2] tpm: add driver for cr50 on SPI

Hi Peter, > > This patchset adds support for H1 Secure Microcontroller running > > Cr50 firmware. It implements several functions, including TPM-like > > functionality, and communicates over SPI using the FIFO protocol > > described in the PTP Spec, section 6. > > H1 is a proprietary chip that

Re: [tpmdd-devel] [PATCH v2 1/2] tpm: devicetree: document properties for cr50

On Wed, Jul 20, 2016 at 01:54:22PM -0600, Jason Gunthorpe wrote: > On Wed, Jul 20, 2016 at 12:49:12PM -0700, Andrey Pronin wrote: > > > Sorry, I just updated this patch description in v2 to indicate why they are > > not > > hard-coded, but didn't answer explicitly. As the firmware changes, a >

Re: [tpmdd-devel] [PATCH v2 1/2] tpm: devicetree: document properties for cr50

On Thu, Jul 21, 2016 at 04:03:12PM -0500, Rob Herring wrote: > On Wed, Jul 20, 2016 at 12:49:12PM -0700, Andrey Pronin wrote: > > On Wed, Jul 20, 2016 at 02:03:03PM -0500, Rob Herring wrote: > > > On Tue, Jul 19, 2016 at 08:41:24PM -0700, Andrey Pronin wrote: > > > > Hi Rob, > > > > > As I

Re: [tpmdd-devel] Regarding recently Added TPM2.0 support to the Nuvoton i2c driver

On 07/27/2016 12:24 PM, Jason Gunthorpe wrote: > On Wed, Jul 27, 2016 at 10:30:09AM -0400, Dave Heller wrote: >>> So you might do >>> >>>compatible = "nuvoton,npct650", "nuvoton,npct601" >>> >>> Andrew, is 601 even the right name? >> >> Hi Jason, I'm not sure I'm understanding your answer

Re: [tpmdd-devel] Regarding recently Added TPM2.0 support to the Nuvoton i2c driver

On Wed, Jul 27, 2016 at 11:05:14AM -0500, George Wilson wrote: > > Yes, generally Linux expects DT to be set correctly by the boot > > firmware. Early firmware needs to know the TPM type anyhow to do the > > TPM setup, so this doesn't seem like a realistic scenario. > > A reset is required after

Re: [tpmdd-devel] Regarding recently Added TPM2.0 support to the Nuvoton i2c driver

On Wed, Jul 27, 2016 at 10:30:09AM -0400, Dave Heller wrote: > > So you might do > > > > compatible = "nuvoton,npct650", "nuvoton,npct601" > > > > Andrew, is 601 even the right name? > > Hi Jason, I'm not sure I'm understanding your answer here. Looks like > we will have to add a couple of

Re: [tpmdd-devel] Regarding recently Added TPM2.0 support to the Nuvoton i2c driver

On Tue, Jul 26, 2016 at 03:03:44PM -0600, Jason Gunthorpe wrote: > On Tue, Jul 26, 2016 at 03:39:02PM -0500, George Wilson wrote: > > > Generally speaking probing is somewhat discouraged, currently we only > > > probe for PC platform tis (and even that might be a mistake), all > > > other drivers

Re: [tpmdd-devel] Regarding recently Added TPM2.0 support to the Nuvoton i2c driver

On 07/26/2016 04:17 PM, Jason Gunthorpe wrote: > On Tue, Jul 26, 2016 at 11:44:43PM +0530, Nayna wrote: >> I got these questions while testing some TPM2.0 stuff using the kernel >> code from repo having this patch and am using Nuvoton TPM. >> >> #1. It seems that support is added only for