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] [thread-next>] [day] [month] [year] [list]
Message-ID: <644b0f0f-9e02-44fb-a0d4-f4018816e156@sirena.org.uk>
Date: Thu, 11 Sep 2025 15:26:38 +0100
From: Mark Brown <broonie@...nel.org>
To: Alexander Wilhelm <alexander.wilhelm@...termo.com>
Cc: Peter Huewe <peterhuewe@....de>, Jarkko Sakkinen <jarkko@...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 Thu, Sep 11, 2025 at 03:52:33PM +0200, Alexander Wilhelm wrote:

> 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.

That sounds like the controller is configured in word mode and is
bouncing chip select after every word it sends.  The Freescale
controllers are fond of implementing and using that, no idea about this
specific one.  I see there's some non-standard DT properties it has
which look like they're related to chip select modes but no idea what
they do.

> 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.

Can you not pinmux the signal from the SoC to a GPIO instead of the SPI
controller?  It's fairly common to do that since controllers often have
regrettably limited or unhelpful chip select features so GPIOs are often
the better choice.  The controller does what it likes with the chip
select signal but it's not actually connected to anything and we do
everything in software.

I'd recommend contacting whoever looks after the relevant controller
driver, though it looks rather abandoned TBH.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ