All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jarkko Sakkinen <jarkko@kernel.org>
To: Alexander Wilhelm <alexander.wilhelm@westermo.com>
Cc: Peter Huewe <peterhuewe@gmx.de>, Mark Brown <broonie@kernel.org>,
	linux-integrity@vger.kernel.org, linux-spi@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: tpm: SLM9670 does not work on T1023
Date: Sun, 14 Sep 2025 20:08:48 +0300	[thread overview]
Message-ID: <aMb2oEN7HPeqQjQE@kernel.org> (raw)
In-Reply-To: <aMb2A5KzQJNx3daG@kernel.org>

On Sun, Sep 14, 2025 at 08:06:15PM +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.
> 
> > 
> > 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 :-)

Ugh, no. Probably it is device tree given false data. I recall we have
some ways to override device tree, so find the data sheet for the TPM
and rewrite the ids I suppose.

BR, Jarkko

  reply	other threads:[~2025-09-14 17:08 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-11 13:52 tpm: SLM9670 does not work on T1023 Alexander Wilhelm
2025-09-11 14:26 ` Mark Brown
2025-09-11 14:51   ` Alexander Wilhelm
2025-09-11 15:04     ` Mark Brown
2025-09-14 17:06 ` Jarkko Sakkinen
2025-09-14 17:08   ` Jarkko Sakkinen [this message]
2025-09-15  5:49   ` Alexander Wilhelm

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aMb2oEN7HPeqQjQE@kernel.org \
    --to=jarkko@kernel.org \
    --cc=alexander.wilhelm@westermo.com \
    --cc=broonie@kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=peterhuewe@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.