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: <12f4d28f3efb7fe319ec919df92145c4ad24da01.camel@mediatek.com>
Date: Tue, 12 Nov 2024 11:25:25 +0000
From: SkyLake Huang (黃啟澤)
	<SkyLake.Huang@...iatek.com>
To: "miquel.raynal@...tlin.com" <miquel.raynal@...tlin.com>
CC: "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>, "gch981213@...il.com"
	<gch981213@...il.com>, "vigneshr@...com" <vigneshr@...com>, "richard@....at"
	<richard@....at>
Subject: Re: [PATCH v2] mtd: spinand: add support for FORESEE F35SQA002G

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
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.

> > I guess we need to add some check to make sure that F35SQA series
> > work
> > only with those SPI controllers who can transmit more than 2048
> > bytes(NAND page size) at one time?
> 
> There is already a supports_op() hook for that, I believe we are
> fine. If however you experience errors, please report them and we'll
> look for a solution.
> 
> Thanks,
> Miquèl

We can block 32H update_cache opcode in supports_op() hook for those
light SPI controllers(transmittion cap. < 2048 Bytes)? Not sure if
there's a better solution.

Indeed, most SPI controllers support DMA transmission(>2048 Bytes) now,
including our MTK filogic platform. If this doesn't bother other FIFO-
only SPI controllers, I'll take it.

BRs,
Sky