linux-kernel - [PATCH 1/1] mtd: rawnand: davinci: Add dummy read after sending command

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-next>] [day] [month] [year] [list]

Message-ID: <20240308074609.9056-1-bastien.curutchet@bootlin.com>
Date: Fri,  8 Mar 2024 08:46:09 +0100
From: Bastien Curutchet <bastien.curutchet@...tlin.com>
To: Miquel Raynal <miquel.raynal@...tlin.com>,
	Richard Weinberger <richard@....at>,
	Vignesh Raghavendra <vigneshr@...com>
Cc: linux-mtd@...ts.infradead.org,
	linux-kernel@...r.kernel.org,
	Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
	herver.codina@...tlin.com,
	christophercordahi@...ometrics.ca,
	Bastien Curutchet <bastien.curutchet@...tlin.com>
Subject: [PATCH 1/1] mtd: rawnand: davinci: Add dummy read after sending command

Sometimes, writes fail because the tWB_max is not correctly observed
after sending PAGEPROG. It leads to the R/B pin to be read as in
the "ready" state right after sending the command, thus preventing the
normal tPROG delay to be actually observed. This happens because the
ndelay() that waits for tWB_max starts before the command reaches the
NAND chip.

Add a dummy read when a delay is requested at the end of the executed
instruction to make sure that the sent command is received by the NAND
before starting the short ndelay() (<1us but rounded up to 1us in
practice). This read is done on the control register area because
doing it on the Async Data area would change the NAND's RE pin state.
This is not perfect as the two areas are behind two different
devm_ioremap_resource() and could possibly be located on different
interconnects (I did not find more details). This means either the
additional latency due to the load operation is enough impacting, or it
has the expected behavior of ensuring the write has been received.

This has been tested on two platforms designed off of the
DAVINCI/OMAP-L138. The first uses a Toshiba NAND Flash (TC58NYG2S3EBAI5),
the other a Macronix one (MX30UF4G18AC).

Signed-off-by: Bastien Curutchet <bastien.curutchet@...tlin.com>
---
nandtest utility sometimes fails because of write failures. It is likely
that these failures are due to a non respect of the tPROG delay
after sending PAGEPROG. I could not manage to fully prove this because
adding debugging to the code makes the failure disappear. As these
timings are really tiny, I can't measure them precisely.

 drivers/mtd/nand/raw/davinci_nand.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/raw/davinci_nand.c b/drivers/mtd/nand/raw/davinci_nand.c
index e75d81cf8c21..051deea768db 100644
--- a/drivers/mtd/nand/raw/davinci_nand.c
+++ b/drivers/mtd/nand/raw/davinci_nand.c
@@ -671,8 +671,11 @@ static int davinci_nand_exec_instr(struct davinci_nand_info *info,
 		break;
 	}

-	if (instr->delay_ns)
+	if (instr->delay_ns) {
+		/* Dummy read to be sure that command is sent before ndelay starts */
+		davinci_nand_readl(info, 0);
 		ndelay(instr->delay_ns);
+	}

 	return 0;
 }
-- 
2.43.2