linux-kernel - Re: [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-prev] [day] [month] [year] [list]

Message-Id: <20240325101904.262591-1-miquel.raynal@bootlin.com>
Date: Mon, 25 Mar 2024 11:19:03 +0100
From: Miquel Raynal <miquel.raynal@...tlin.com>
To: Bastien Curutchet <bastien.curutchet@...tlin.com>,
	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
Subject: Re: [PATCH 1/1] mtd: rawnand: davinci: Add dummy read after sending command

On Fri, 2024-03-08 at 07:46:09 UTC, Bastien Curutchet wrote:
> 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>

Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git nand/next, thanks.

Miquel