linux-kernel - Re: [RFC PATCH nand/next 0/4] mtd: nand: spi: Add CASN page support

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: <9880b3b2f71afd1b020c393fd5d4c0c5673df187.camel@mediatek.com>
Date: Wed, 20 Nov 2024 07:24:28 +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>,
	"linux-mediatek@...ts.infradead.org" <linux-mediatek@...ts.infradead.org>,
	"acelan.kao@...onical.com" <acelan.kao@...onical.com>,
	"chengminglin@...c.com.tw" <chengminglin@...c.com.tw>,
	"mika.westerberg@...ux.intel.com" <mika.westerberg@...ux.intel.com>,
	"linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>,
	Steven Liu (劉人豪) <steven.liu@...iatek.com>,
	"matthias.bgg@...il.com" <matthias.bgg@...il.com>, "daniel@...rotopia.org"
	<daniel@...rotopia.org>, "vigneshr@...com" <vigneshr@...com>,
	AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
	"richard@....at" <richard@....at>
Subject: Re: [RFC PATCH nand/next 0/4] mtd: nand: spi: Add CASN page support

On Mon, 2024-11-18 at 11:53 +0100, Miquel Raynal wrote:
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
> 
> 
> On 20/10/2024 at 21:27:18 +08, Sky Huang <SkyLake.Huang@...iatek.com>
> wrote:
> 
> > From: "Sky Huang" <skylake.huang@...iatek.com>
> > 
> > Hi, this is Qi-Ze Huang(Sky Huang) from MediaTek. On our router
> > platforms
> > chips, we have to quality lots of SPI-NAND devices and are eager
> > for
> > a standard so that we don't need to maintain trivial flash ID table
> > anymore. I also noticed a talk in 2019 Embedded Linux Conference,
> > Memory Technology Devices: what's new, which mentioned "ONFI for
> > SPI-NANDs? Maybe, maybe not".
> > 
> > So earlier this year, I proposed a bold idea, CASN page (Common
> > Attributes
> > for SPI-NAND). I worked together with top 3 SPI-NAND market share
> > flash
> > vendors and other vendors to integrate CASN page on their SPI-NAND
> > devices
> > including but not limited to:
> > [ESMT]
> > F50L1G41LB
> > F50L2G41KA
> > 
> > [Etron]
> > EM73C044VCF-H
> > EM73D044VCO-H
> > EM73E044VCE-H
> > EM73F044VCA-H
> > 
> > [GigaDevice]
> > GD5F1GM7UE
> > GD5F1GQ5UEYIG
> > GD5F2GM7UE
> > GD5F2GQ5UEYIG
> > GD5F4GM8UE
> > GD5F4GQ6UEYIG
> > 
> > [Macronix (MXIC)]
> > MX35LF1GE4ABZ4IG
> > 
> > [Winbond]
> > W25N01GV
> > W25N01KV
> > W25N02KV
> > W25N04KV
> > 
> > A document of CASN is hosted on github(
> > https://urldefense.com/v3/__https://github.com/mtk-openwrt/__;!!CTRNKA9wMg0ARbw!j_TES7dJ_An-9wtyQqWgGBE9ovPnUA-tDNlZ-pGpUdYv4gphzW4v54Fal8i_nLwSmPAzK9ApgSBG1XQ_mREdTS0ZwrBWRA$
> > doc/blob/main/CASN%20Page%20Introduction.pdf) So I'll try to keep
> > it
> > simple here.
> > 
> > With CASN page, we don't need to maintain SPI-NAND flash ID table
> > anymore.
> > Currently, it's integrated in 3.3V SPI-NANDs of small density and
> > it's not
> > JEDEC standard yet. But it should be able to handle 1.8V and can be
> > easily
> > integrated by flash vendors.
> > 
> > I believe this idea and implementation have room for improvement.
> > Hope to
> > hear you open source community's comments soon.
> 
> I think this is a bright initiative. I'd welcome some standardisation
> on
> the discovery indeed.
> 
> But to be really useful, I believe this table must be really
> complete,
> otherwise ID's will remain. For instance SDR/DDR modes are not
> entirely
> defined as we already have mixed modes. There is also no information
> about what maximum frequencies can be used with each operation. 

Maximum frequencies are limited by SPI controller's max freq now, I
guess?

> As
> another example, there is no read retry information.
What will retry information look like?

> Nor anything about
> the fact that the on-die ECC engine might not be disabled.
As far as I know, only SkyHigh's SPI-NAND's ECC engine can't be
disabled since its on-die ECC engine contains randomizer.

There are some reserved fields. We can handle above requirements in
CASN V1.2 or V2. But may I ask what's the purpose of involving above
information in CASN? Are there any practical application scenarios?

> 
> Overall I think this is an interesting initiative but I would like it
> to
> be more advanced.
Agree.

> Is there a plan on getting this standardized through
> eg. a JEDEC spec?
> 
> Thanks,
> Miquèl
Yes. We're working on it. But it will take some time. Your opinions
mean a lot to CASN page standardisation.

BRs,
Sky