linux-kernel - Re: [PATCH v2] mtd: spinand: add support for FORESEE F35SQA002G

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: <CAJsYDVLYE1=sAj5Pvni17xQ=4akFCA+UqtuB5RKq77HxL4ux9w@mail.gmail.com>
Date: Wed, 13 Nov 2024 18:10:20 +0800
From: Chuanhong Guo <gch981213@...il.com>
To: Miquel Raynal <miquel.raynal@...tlin.com>
Cc: SkyLake Huang <SkyLake.Huang@...iatek.com>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, 
	"linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>, 
	"mmkurbanov@...utedevices.com" <mmkurbanov@...utedevices.com>, 
	"kernel@...rdevices.ru" <kernel@...rdevices.ru>, "d-gole@...com" <d-gole@...com>, 
	"dev@...herer.org" <dev@...herer.org>, "vigneshr@...com" <vigneshr@...com>, "richard@....at" <richard@....at>
Subject: Re: [PATCH v2] mtd: spinand: add support for FORESEE F35SQA002G

Hello all!

On Wed, Nov 13, 2024 at 5:05 PM Miquel Raynal <miquel.raynal@...tlin.com> wrote:
>
> On 12/11/2024 at 11:25:25 GMT, SkyLake Huang (黃啟澤) <SkyLake.Huang@...iatek.com> wrote:
>
> > On Tue, 2024-11-12 at 11:48 +0100, Miquel Raynal wrote:
> >> External email : Please do not click links or open attachments until
> >> you have verified the sender or the content.
> >>
> >>
> >> Hi Sky,
> >>
> >> On 12/11/2024 at 10:08:31 GMT, SkyLake Huang (黃啟澤) <
> >> SkyLake.Huang@...iatek.com> wrote:
> >>
> >> > Hi Miquel/Martin,
> >> > About this driver, including F35SQA001G/F35SQA002G parts, I'm
> >> > concerned
> >> > that the driver will always use 32H for update_cache operations,
> >> > which
> >> > means it's not compitable with those SPI controller who can't
> >> > transmit
> >> > 2048 bytes (most small-density SPI-NAND's page size nowadays) at
> >> > one
> >> > time.
> >> >
> >> > The following controller's driver seems that they can't transmit
> >> > 2048
> >> > bytes in one transmission:
> >> > - spi-amd.c: 64 bytes (AMD_SPI_MAX_DATA)
> >> > - spi-amlogic-spifc-a1.c: 512 bytes (SPIFC_A1_BUFFER_SIZE)
> >> > - spi-fsl-qspi.c: 1KB
> >> > - spi-hisi-sfc-v3xx.c: 64*6 bytes
> >> > - spi-intel.c: 64 bytes (INTEL_SPI_FIFO_SZ)
> >> > - spi-microchip-core-qspi.c: 256 bytesc (MAX_DATA_CMD_LEN)
> >> > - spi-nxp-fspi.c: TX:1KB, RX: 512B in FIFO mode
> >> > - spi-wpcm-fiu.c: 4B
> >>
> >> I believe most of these drivers are still able to send one page of
> >> data
> >> without toggling the CS (which is what actually matters, I believe).
> >> If
> >> they were broken, they would be broken with all spi memory devices,
> >> not
> >> only Foresee's.
> >>
> > Hi Miquel,
> > I think it's not about toggling the CS?
> >
> > If a SPI controller tries to execute write page and it's capable to
> > send only 1KB in one transmission, it should transmit data in two
> > steps: 1st 34H (random program load x4) and 2nd 34H. However, when
> > F35SQA002G executes 2nd 34H command, it needs to execute 32H first, and

I don't think that's what the datasheet means. I think it needs
02h/32h as the first
command to write page cache, and the subsequent page cache writing can
be done using 84h/34h before the final page program happens. Otherwise the
84h/34h command is just completely broken and useless.
If it actually is broken, we do need additional guards in spinand_write_cache_op
to abort when spi_mem_dirmap_write doesn't return exactly nbytes as requested.

> > it will clear data transmitted by 1st 34H in NAND flash's cache. This
> > will cause data corruption. Other SPI-NANDs doesn't need to execute 32H
> > before 34H.
>
> Is it really what happens? I'd instead expect the spi controller to
> send:
> - 34h
> - 1k data
> - 1k data
> ...
>
> Why should we repeat the command while we are in the I/O phase?

Several SPI-MEM controller don't allow software controlled CS, or for some
other reasons are unable to execute a longer spi-mem op.
spi_mem_dirmap_write returns the actual request size it's able to make,
and spinand_write_to_cache_op use a while loop to split one update_cache
request into multiple ones.

This only works using the Random Program Load instruction (84h/34h)
which preserves the previous written data in the flash data cache.
All current supported flashes are exclusively using 84h/34h as the command
to write the page cache.

Load Program Data(02h/32h) will clear the entire page cache. As a
result, when a request is split as described above, the previous written
data will be cleared, breaking the page cache writing procedure.

We can change write_to_cache_op to use Load Program Data on the
first request. If that doesn't finish writing, use Random Program Load
on subsequent data loading.
-- 
Regards,
Chuanhong Guo