linux-kernel - Re: [PATCH v2 3/4] dt-bindings: mtd: macronix,mx25l12833f: add SPI-NOR chip

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: <CANeKEMM02-Jvb8Pd0fZJFnRg-hsAW+hckYWm11tZZXNMPSPJ=w@mail.gmail.com>
Date: Wed, 3 Jul 2024 01:16:34 +0200
From: Erez <erezgeva2@...il.com>
To: Tudor Ambarus <tudor.ambarus@...aro.org>
Cc: Esben Haabendal <esben@...nix.com>, Erez Geva <erezgeva@...ime.org>, linux-mtd@...ts.infradead.org, 
	Pratyush Yadav <pratyush@...nel.org>, Michael Walle <mwalle@...nel.org>, linux-kernel@...r.kernel.org, 
	Miquel Raynal <miquel.raynal@...tlin.com>, Richard Weinberger <richard@....at>, 
	Vignesh Raghavendra <vigneshr@...com>, devicetree@...r.kernel.org, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>
Subject: Re: [PATCH v2 3/4] dt-bindings: mtd: macronix,mx25l12833f: add
 SPI-NOR chip

On Tue, 2 Jul 2024 at 07:00, Tudor Ambarus <tudor.ambarus@...aro.org> wrote:
>
>
>
> On 7/1/24 6:08 PM, Erez wrote:
> > On Mon, 1 Jul 2024 at 12:15, Tudor Ambarus <tudor.ambarus@...aro.org> wrote:
> >>
> >>
> >>
> >> On 7/1/24 10:46 AM, Erez wrote:
> >>> When using mx25l12805d, we do not read SFDP.
> >>> As it uses the no-SFDP flags.
> >>> When using mx25l12833f hardware with mx25l12805d driver, it did not
> >>> try to read the SFDP.
> >>> Yet mx25l12833f does have SFDP, when I remove the no-SFDP flags, the
> >>> driver fetch the SFDP.
> >>>
> >>> Secondly SFDP does not contain OTP information.
> >>>
> >>> mx25l12805d has two OTP regions of 128 KiB and 384 KiB (yes asymmetric).
> >>> While mx25l12833f has two OTP regions of 512 KiB.
> >>>
> >>> How do we handle it?
> >>
> >> You would first try to parse SFDP and initialize the flash based on
> >> SFDP. If there's no SFDP then you fallback to the flags declared at
> >> flash declaration. Esben had a try recently, see [1]. I don't know if
> >> there's any progress in that direction.
> >>
> >> Also, you haven't mentioned anything about the testing. Do you have the
> >> flash?
> >>
> >> [1]
> >> https://lore.kernel.org/linux-mtd/20240603-macronix-mx25l3205d-fixups-v2-0-ff98da26835c@geanix.com/
> >
> > Looking at "mtd: spi-nor: macronix: workaround for device id re-use"
> > I guess it can be applied to all Macronix devices.
>
> No, no, we're going to do it individually just where it's needed.
> Issuing unsupported commands is not that great.

Would be nice if we could ask Macronix directly.

Looking on their web site and reading some spec. and status reports.
Using the IDs with  'no_sfdp_flags' in drivers/mtd/spi-nor/macronix.c
I did not search for new chips reusing IDs of chips at end of life.
But we found 3 already:
MX25U51245G appears in the table with the same ID as MX66U51235F.
Esben Haabendal found MX25L3233F which reuses  MX25L3205D ID.
And I found MX25L12833F reuses MX25L12805D ID.
Chips that are not in end of life do support SFDP, at least the new
versions of the chips according to their spec.
It seems quite systematic.

By the way, the chip MX25L2005A part number is 'MX25L2005' without the 'A'.

We can support Macronix chips that are not in the table, just by
reading the SFDP.
In that case we can name them like "mx-szNN".

The table below uses fixed width characters.

ID      Part.         Size              Status          SFDP status
according to spec.
                                                        New chip with
SFDP for EOL
c22012  MX25L2005(A)  SZ_256K =  2Mb    EOL             MX25L2006E
c22532  MX25U2033E    SZ_256K =  2Mb    EOL
c22013  MX25L4005A    SZ_512K =  4Mb    EOL
c22533  MX25U4035     SZ_512K =  4Mb    EOL
c22534  MX25U8035     SZ_1M   =  8Mb    EOL
c22016  MX25L3205D    SZ_4M   =  32Mb   EOL             MX25L3233F
c29e16  MX25L3255E    SZ_4M   =  32Mb   EOL
c22017  MX25L6405D    SZ_8M   =  64Mb   EOL
c22018  MX25L12805D   SZ_16M  =  128Mb  EOL             MX25L12833F
c22538  MX25U12835F   SZ_16M  =  128Mb  EOL
c2253a  MX66U51235F   SZ_64M  =  512Mb  EOL             MX25U51245G
c22010  MX25L512E     SZ_64K  =  512Kb  NO_REC          Have-SFDP!
c22015  MX25L1606E    SZ_2M   =  16Mb   NO_REC          Have-SFDP!
c22536  MX25U3235F    SZ_4M   =  32Mb   NO_REC          Have-SFDP!
c22816  MX25R3235F    SZ_4M   =  32Mb   NO_REC          Have-SFDP!
c22537  MX25U6435F    SZ_8M   =  64Mb   NO_REC          Have-SFDP!
c22019  MX25L25635E   SZ_32M  =  256Mb  NO_REC          Have-SFDP!
c22539  MX25U25635F   SZ_32M  =  256Mb  NO_REC          Have-SFDP!
c2201a  MX66L51235F   SZ_64M  =  512Mb  NO_REC          Have-SFDP!
c2261b  MX66L1G55G    SZ_128M =  1Gb    NO_REC          Spec. is not public
c22314  MX25V8035F    SZ_1M   =  8Mb    PROD            Have-SFDP!
c22815  MX25R1635F    SZ_2M   =  16Mb   PROD            Have-SFDP!
c2201b  MX66L1G45G    SZ_128M =  1Gb    PROD            Have-SFDP!
c2253c  MX66U2G45G    SZ_256M =  2Gb    PROD            Have-SFDP!
c2253a  MX25U51245G   SZ_64M  =  512Mb  PROD            Have-SFDP!

EOL     End of Life
PROD    Normal Production
NO_REC  Not recommend for new design


Erez





>
> > Adding something like the following in macronix_nor_default_init():
> >
> > if (info>no_sfdp_flags)
> >     info>no_sfdp_flags |= SPI_NOR_TRY_SFDP
> >
> > It seems Macronix did many reuse of IDs.
> > I saw it with "mx25l12833f" reusing "mx25l12805d".
> > And Esben saw it with MX25L3233F reusing "MX25L3205D".
> >
> > The only thing I notice is the flash using the same size.
> > A sort of "backward" compatible.
> >
> > Erez