From: Tudor Ambarus <tudor.ambarus@linaro.org>
To: Erez <erezgeva2@gmail.com>, Jaime Liao <jaimeliao@mxic.com.tw>,
leoyu@mxic.com.tw, Alvin Zhou <alvinzhou@mxic.com.tw>,
Julien Su <juliensu@mxic.com.tw>
Cc: Esben Haabendal <esben@geanix.com>,
Erez Geva <erezgeva@nwtime.org>,
linux-mtd@lists.infradead.org,
Pratyush Yadav <pratyush@kernel.org>,
Michael Walle <mwalle@kernel.org>,
linux-kernel@vger.kernel.org,
Miquel Raynal <miquel.raynal@bootlin.com>,
Richard Weinberger <richard@nod.at>,
Vignesh Raghavendra <vigneshr@ti.com>,
devicetree@vger.kernel.org, Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>
Subject: Re: [PATCH v2 3/4] dt-bindings: mtd: macronix,mx25l12833f: add SPI-NOR chip
Date: Wed, 3 Jul 2024 08:12:26 +0100 [thread overview]
Message-ID: <9b45cc73-2251-4085-af95-7ccd00dd6d3b@linaro.org> (raw)
In-Reply-To: <CANeKEMM02-Jvb8Pd0fZJFnRg-hsAW+hckYWm11tZZXNMPSPJ=w@mail.gmail.com>
On 7/3/24 12:16 AM, Erez wrote:
> On Tue, 2 Jul 2024 at 07:00, Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>>
>>
>>
>> On 7/1/24 6:08 PM, Erez wrote:
>>> On Mon, 1 Jul 2024 at 12:15, Tudor Ambarus <tudor.ambarus@linaro.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.
we did. They said it's not ideal, but it's okay.
>
> 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.
is there an extension ID that differentiate the two?
> Esben Haabendal found MX25L3233F which reuses MX25L3205D ID.
> And I found MX25L12833F reuses MX25L12805D ID.
Yes. And we already have a plan for these. We need someone that cares
about them to implement it.
> 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.
>
maybe
> By the way, the chip MX25L2005A part number is 'MX25L2005' without the 'A'.
feel free to propose a patch
>
> 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".
We don't care about the flash name.
If all the flash settings that we care about can be discovered by SFDP
then one won't need to declare a flash entry at all, and instead rely on
the driver to setup the flash settings solely based on the SFDP tables.
See spi-nor-generic handling.
>
> 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
>
>
not sure what you want me to do with these.
Cheers,
ta
next prev parent reply other threads:[~2024-07-03 7:12 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-29 10:39 [PATCH v2 0/4] Add support for SPI-NOR Macronix OTP Erez Geva
2024-06-29 10:39 ` [PATCH v2 1/4] Add generic functions for accessing the SPI-NOR chip Erez Geva
2024-07-01 5:28 ` Tudor Ambarus
2024-06-29 10:39 ` [PATCH v2 2/4] Add support for SPI-NOR Macronix OTP Erez Geva
2024-06-29 10:39 ` [PATCH v2 3/4] dt-bindings: mtd: macronix,mx25l12833f: add SPI-NOR chip Erez Geva
2024-07-01 5:23 ` Tudor Ambarus
[not found] ` <CANeKEMOODBNZA6efh0E0Ga_KaVs5Y3WLcUftRhNwYHhnXO=GNw@mail.gmail.com>
2024-07-01 9:46 ` Erez
2024-07-01 10:15 ` Tudor Ambarus
2024-07-01 10:23 ` Tudor Ambarus
2024-07-01 11:03 ` Erez
2024-07-01 12:53 ` Tudor Ambarus
2024-07-01 16:12 ` Erez
2024-07-01 10:55 ` Erez
2024-07-01 17:08 ` Erez
2024-07-02 5:00 ` Tudor Ambarus
2024-07-02 23:16 ` Erez
2024-07-03 7:12 ` Tudor Ambarus [this message]
2024-07-03 8:23 ` Erez
2024-07-10 14:34 ` Esben Haabendal
2024-07-11 18:57 ` Erez
2024-07-11 19:57 ` Michael Walle
2024-07-11 22:09 ` Erez
2024-07-11 22:13 ` Michael Walle
2024-07-12 5:13 ` Erez
2024-07-12 8:20 ` Esben Haabendal
[not found] ` <CANeKEMPD=nLnor8-oF0t9D8f5D+mLU4XqZ-07avX55BF3TJ8_Q@mail.gmail.com>
2024-08-16 11:29 ` Erez
2024-06-29 10:39 ` [PATCH v2 4/4] Add Macronix SPI-NOR mx25l12833f with OTP Erez Geva
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9b45cc73-2251-4085-af95-7ccd00dd6d3b@linaro.org \
--to=tudor.ambarus@linaro.org \
--cc=alvinzhou@mxic.com.tw \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=erezgeva2@gmail.com \
--cc=erezgeva@nwtime.org \
--cc=esben@geanix.com \
--cc=jaimeliao@mxic.com.tw \
--cc=juliensu@mxic.com.tw \
--cc=krzk+dt@kernel.org \
--cc=leoyu@mxic.com.tw \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=miquel.raynal@bootlin.com \
--cc=mwalle@kernel.org \
--cc=pratyush@kernel.org \
--cc=richard@nod.at \
--cc=robh@kernel.org \
--cc=vigneshr@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).