linux-kernel - [PATCH] spi: omap2-mcspi: drive SPI_CLK on transfer

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 for Android: free password hash cracker in your pocket

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

Message-Id: <20250912-omap-spi-fix-v1-1-f925b0d27ede@bootlin.com>
Date: Fri, 12 Sep 2025 09:08:58 +0200
From: "Bastien Curutchet (Schneider Electric)" <bastien.curutchet@...tlin.com>
To: Mark Brown <broonie@...nel.org>
Cc: Thomas Petazzoni <thomas.petazzoni@...tlin.com>, 
 Miquèl Raynal <miquel.raynal@...tlin.com>, 
 Pascal Eberhard <pascal.eberhard@...com>, linux-spi@...r.kernel.org, 
 linux-kernel@...r.kernel.org, 
 "Bastien Curutchet (Schneider Electric)" <bastien.curutchet@...tlin.com>
Subject: [PATCH] spi: omap2-mcspi: drive SPI_CLK on transfer_setup()

If the cached contents of the CHCONF register doesn't have the FORCE bit
set, the setup() function failed to set the relevant idle state of the
SPI_CLK pin. In such case, the SPI_CLK's idle state is reached later with
set_cs(), but it's too late for the first SPI transfer which fails since
the CS is asserted before the clock reaching its idle state.

Add a first write in setup() that always sets the FORCE bit.
Keep the current write afterwards to ensure the FORCE bit won't stay in
the cached contents of the CHCONF register unless it's intended.

Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@...tlin.com>
---
Hi all,

I ran into this issue with a mode 3 SPI device. When the omap2-mcspi
driver probes, it sets mode 0 so the CLK is down. Then when the mode 3
SPI device probes, it asks for mode 3 but the clock doesn't go up.
Afterwards, when the first transfer occurs, the CS is asserted
before the clock actually reaches it's high state. This is interpreted
as a clock rising edge by the SPI device that samples one 'fake' bit
making this first transfer fail.
---
 drivers/spi/spi-omap2-mcspi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 6dc58a30804a12d16295a7ffc2edb192e6cc4a54..69c2e9d9be3c380327e26f94e82e05e6357f5384 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -988,6 +988,7 @@ static int omap2_mcspi_setup_transfer(struct spi_device *spi,
 	else
 		l &= ~OMAP2_MCSPI_CHCONF_PHA;
 
+	mcspi_write_chconf0(spi, l | OMAP2_MCSPI_CHCONF_FORCE);
 	mcspi_write_chconf0(spi, l);
 
 	cs->mode = spi->mode;

---
base-commit: 31623e6ce46bcdce751c0d242fbb1502746d1a7c
change-id: 20250911-omap-spi-fix-abfc560444a6

Best regards,
-- 
Bastien Curutchet (Schneider Electric) <bastien.curutchet@...tlin.com>