linux-kernel - Re: [regression] jetson-tk1: spi do not probe anymore

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: <aBfsJpId0Jrcz228@finisterre.sirena.org.uk>
Date: Mon, 5 May 2025 07:37:26 +0900
From: Mark Brown <broonie@...nel.org>
To: Corentin Labbe <clabbe.montjoie@...il.com>
Cc: ldewangan@...dia.com, thierry.reding@...il.com, jonathanh@...dia.com,
	linux-spi@...r.kernel.org, linux-tegra@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Alexandru Ardelean <alexandru.ardelean@...log.com>
Subject: Re: [regression] jetson-tk1: spi do not probe anymore

On Sun, May 04, 2025 at 01:23:29PM +0200, Corentin Labbe wrote:

> On my jetson-tk1, SPI do not probe anymore:
> [    1.330681] spi spi1.0: Invalid delay unit 2, should be SPI_DELAY_UNIT_SCK
> [    1.335185] spi-tegra114 7000da00.spi: can't setup spi1.0, status -22
> [    1.341643] spi_master spi1: spi_device register error /spi@...0da00/flash@0
> [    1.348637] spi_master spi1: Failed to create SPI device for /spi@...0da00/flash@0
> I tested 6.14.7
> The SPI probed perfectly in 4.17.14

That's a pretty big jump in versions...

> I tried to debug a bit, and the driver requires units to be SPI_DELAY_UNIT_SCK, but it seems there is no way to set it.
> Removing the "return -EINVAL" in tegra_spi_set_hw_cs_timing() lead to a successfull probe and the flash device appear.
> But I agree, it is not a correct fix:)
> 
> Since only the test made it fail, I think the driver is bad since commit 810593668468 ("spi: tegra114: change format for `spi_set_cs_timing()` function")

Adding Alexandru who wrote that commit.  Assuming the delays came from
DT (I'm not actually finding them, I didn't look too hard though) and
are therefore in units of wall clock time I think we need to add a
conversion helper for the units which the driver can use to convert to
whatever units it actually wants to use, we do need to accept units of
wall clock time given the generic binding there.  That gets a bit
annoying if the bus speed changes, though that's quite infrequent in
practice.

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