linux-kernel - Re: [PATCH nand/next] mtd: nand: spi: Use write_cache first and then update

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: <871pymtab3.fsf@bootlin.com>
Date: Thu, 05 Dec 2024 16:32:32 +0100
From: Miquel Raynal <miquel.raynal@...tlin.com>
To: Sky Huang <SkyLake.Huang@...iatek.com>
Cc: Matthias Brugger <matthias.bgg@...il.com>,  AngeloGioacchino Del Regno
 <angelogioacchino.delregno@...labora.com>,  Richard Weinberger
 <richard@....at>,  Vignesh Raghavendra <vigneshr@...com>,  Daniel Golle
 <daniel@...rotopia.org>,  Chia-Lin Kao <acelan.kao@...onical.com>,  "Cheng
 Ming Lin" <chengminglin@...c.com.tw>,  Christophe JAILLET
 <christophe.jaillet@...adoo.fr>,  Pratyush Yadav <pratyush@...nel.org>,
  <linux-kernel@...r.kernel.org>,  <linux-mtd@...ts.infradead.org>,
  <linux-arm-kernel@...ts.infradead.org>,
  <linux-mediatek@...ts.infradead.org>,  Steven Liu
 <Steven.Liu@...iatek.com>
Subject: Re: [PATCH nand/next] mtd: nand: spi: Use write_cache first and
 then update_cache in write operation

Hello,

On 19/11/2024 at 17:39:49 +08, Sky Huang <SkyLake.Huang@...iatek.com> wrote:

> From: Sky Huang <skylake.huang@...iatek.com>
>
> According to discussion with Miquel Raynal <miquel.raynal@...tlin.com>
> and Chuanhong Guo <gch981213@...il.com> on FORESEE F35SQA002G patch,
> Chuanhong recommmends that we can use the following sequence in
> spinand_write_to_cache_op():
>
> x1 mode:
> 02H(program data load) -> 84H(random program data load) -> 84H ...
>
> x4 mode:
> 32H(program data load x4) -> 34H(random program data load x4) -> 34H ...
>
> 02H or 32H commands will clear cache buffer on SPI-NAND and load
> data to it. For those SPI controllers which can't finish transmission
> in single step, 84H or 34H will be triggered for the rest data.
>
> We observe that some current SPI-NANDs, including FORESEE F35SQA001G and
> F35SQA002G, must use 02H or 32H to reset cache buffer in flash before
> using 84H or 34H. Or users may encounter program failure issue. This issue
> is not always reproducible, but it may occur and cause system instability.
>
> This sequence should work on all SPI-NANDs nowadays. I also check with
> Foresee that the sequence can solve the above program failure issue.
>
> On my test platform (MT7988), SPI driver is drivers/spi/spi-mt65xx.c.
> And I limit MTK_SPI_IPM_PACKET_SIZE to SZ_1K to simulate lightweight SPI
> controller which can only transmit 1024 bytes.
>
> The test step is the following:
> - mtd erase /dev/mtd2
> - dd if=/dev/zero bs=2048 count=1 | tr '\0' '\xA5' > output.bin
> - mtd write output.bin /dev/mtd2
>
> Before applying this patch, write operation uses only 34H(update_cache):
> [78.937720] OP code: 0x34, addr val: 0x0, data nbytes: 1020, data 1st byte: 0xa5
> [78.945297] OP code: 0x34, addr val: 0x3fc, data nbytes: 1020, data 1st byte: 0xa5
> [78.954251] OP code: 0x34, addr val: 0x7f8, data nbytes: 72, data 1st byte: 0xa5
> [78.962966] OP code: 0x10, addr val: 0x300
> [78.968816] OP code: 0x34, addr val: 0x0, data nbytes: 1020, data 1st byte: 0xff
> [78.977233] OP code: 0x34, addr val: 0x3fc, data nbytes: 1020, data 1st byte: 0xff
> [78.985124] OP code: 0x34, addr val: 0x7f8, data nbytes: 72, data 1st byte: 0xff
> [78.992527] OP code: 0x10, addr val: 0x301
> [78.996981] OP code: 0x34, addr val: 0x0, data nbytes: 1020, data 1st byte: 0xff
> [79.004416] OP code: 0x34, addr val: 0x3fc, data nbytes: 1020, data 1st byte: 0xff
> [79.012031] OP code: 0x34, addr val: 0x7f8, data nbytes: 72, data 1st byte: 0xff
> [79.019435] OP code: 0x10, addr val: 0x302

I am sorry but above you said that we should not perform:

    0x32, 0x32, 0x32...

because the second time it would clear the cache again. And here
you tell us that actually the core already handles that by performing
instead:

    0x34, 0x34, 0x34...

So what is the problem?

Or maybe I misunderstood the issue, but I think Chuanhong raised an
issue that is already solved? Isn't it?

Thanks,
Miquèl