linux-kernel - Re: tpm: SLM9670 does not work on T1023

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aMeo3Woh1guA2YPB@FUE-ALEWI-WINX>
Date: Mon, 15 Sep 2025 07:49:17 +0200
From: Alexander Wilhelm <alexander.wilhelm@...termo.com>
To: Jarkko Sakkinen <jarkko@...nel.org>
Cc: Peter Huewe <peterhuewe@....de>, Mark Brown <broonie@...nel.org>,
        linux-integrity@...r.kernel.org, linux-spi@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: tpm: SLM9670 does not work on T1023

On Sun, Sep 14, 2025 at 08:06:11PM +0300, Jarkko Sakkinen wrote:
> On Thu, Sep 11, 2025 at 03:52:33PM +0200, Alexander Wilhelm wrote:
> > Hello devs,
> > 
> > I'm trying to bring up the SLM9670 TPM 2.0 device connected via SPI on a QorIQ
> > T1023-based board. Pin control is fully configured through the RCW, so I haven't
> > added any additional properties in the device tree. The SPI controller accesses
> > the TPM using `#CS0`.
> > 
> > However, the driver reads an incorrect vendor ID (0x1000000) and hangs during
> > the startup sequence. A logic analyzer shows that the chip select line goes high
> > immediately after transmitting 4 bytes, which, according to various forum
> > discussions, does not comply with the TPM specification. Unfortunately, I
> > haven't found a definitive solution to this issue.
> 
> So, at least the vendor ID is bogus meaning that TPM driver is doing
> right thing.

I think so. When the first transmission occurs, the TPM sets the very last bit
to 1. This seems to be some kind of acknowledgment flag. So when I output a
32-bit value, it appears as 0x01000000. After that, the chip select (#CS) line
goes high. In the next read operation, nothing is written, but the TPM again
returns 0x01000000. This doesn’t look like an incorrect Vendor ID, but rather
another acknowledgment flag.

I’ve looked into the TPM driver code, and it uses a `cs_change` flag to indicate
that chip select should remain active after the last transmission. Some SPI
driver implementations, like `spi-fsl-dspi`, use this flag to configure
additional registers. However, `spi-fsl-espi` I'm using does not use this flag
at all, not in a single line of code. I believe this might be the root of the
issue. By the way, the same TPM works flawlessly on an x86 platform, which uses
a different SPI controller.

I was considering using an alternative GPIO for chip select. But if the code
doesn’t make use of `cs_change` anyway, that probably wouldn’t help, right?

> > Could this be a bug in the `spi-fsl-espi` driver, or is it possibly a hardware
> > limitation of the T1023? I've come across some suggestions that involve using a
> > GPIO as an alternative chip select instead of the one provided by the SPI
> > controller. Can anyone confirm whether this workaround is viable? I’d prefer to
> > avoid a PCB redesign unless it's absolutely necessary.
> 
> My first guess would be that the firmware inside TPM actually does throw
> a broken vendor ID but it is exactly a guess :-)
> 
> I'll follow this, and please cc me also to future threads but right now
> I'm clueless.

Sure, you've been on CC since the very first message.

Best regards
Alexander Wilhelm