From: Tudor Ambarus <tudor.ambarus@linaro.org>
To: Erez <erezgeva2@gmail.com>
Cc: 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>,
Esben Haabendal <esben@geanix.com>
Subject: Re: [PATCH v5 1/5] mtd: spi-nor: core: add manufacturer flags
Date: Mon, 23 Sep 2024 18:52:58 +0100 [thread overview]
Message-ID: <ca2c03f7-0769-4b2a-b743-3ebda9e29755@linaro.org> (raw)
In-Reply-To: <CANeKEMNKF5WtVgzxbMnLFsqRHNOz=+gD-if8aBqsWwjgDvz3GA@mail.gmail.com>
On 9/23/24 3:51 PM, Erez wrote:
> On Mon, 23 Sept 2024 at 16:18, Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
cut
>>> After reading a lot of Mactronix datasheets, I suggest also reading
>>> all SFDP to all Mactronix chips.
>>
>> Why? It seems too invasive. Generally it is not recommended to issue
>> unsupported commands to flashes. Change just the flash that you use and
>> can test.
>
> It is not, All Mactronix chips in the last 15 years have SFDP.
This is false. I worked with an octal macronix flash that didn't define
SFDP tables, mx66something.
> The chips in the manufacturer compatibility table are all obsolete.
> Mactronix reuse the JEDEC IDs. There is no point pretending these are
> the same chips.
>
If macronix doesn't care about backward compatibility, we/I do, and we
can't break it.
>> cut
>>
>>>> Which flash do you have at hand, both, none, just one of them?
>>>
>>> When I started working on the OTP code, I used MX25L12833F.
>>> But later I left the company.
>>> So I use my beaglebone black and connect it to a MX25L3233F.
>>
>> I understand mx25l12805d and mx25l12833f share the same ID. How is
>> mx25l3233f related, does it share the same ID as the previous two?
>
> They are not. I just replaced the company hardware with a different one.
> You ask me to report the hardware I use for testing.
So MX25L3233F does not share the same ID as MX25L12833F and mx25l12805d?
Then why do we talk about ID reuse?
>
> The patch covers the one I use with beaglebone black.
> I just mentioned the OTP callbacks are per manufacturer.
> But if a new chip in the future would require different callbacks,
> then just add them.
> My patch is using a single chip, the one I send the testing with.
> beaglebone black + MX25L3233F.
Sounds good.
cut
>> I said new compatibility will be introduced as a last resort only if we
>> can't differentiate the flashes at run-time. You haven't proved me yet
>> that this is the case.
>
> Then you do not read my explanation.
What explanation? I've read your cover letter, commit message and I
didn't understood what you're trying to achieve.
> Do you wish me to send the Macronix datasheet of the 4 chips?
No, I need just a paragraph where you explain what are the challenges
and how you want to address them.
>
>>
>>> You ask if it is possible to deduce it from JEDEC ID and SFDP,
>>> I answer that this is not possible, at least in some cases..
>>
>> I'm interested just about your case, not all the possible cases.
>
> Actually it is the MX25L3233F and its previous chips.
Which previous chips? Do you have any such chip at hand? If not, why are
we talking about collisions?
> Anyway, I will not submit a broken solution.
> Whether you like the idea or not.
>
Fine by me.
cut
>>>>> I told you we can not "guess" OTP settings based on JEDEC ID and SFDP existence.
>>>>
>>>> When? And more importantly, why?
>>>
>>> I send you example of 3/4 chips that using JEDEC ID and SFDP existence
>>> is not enough.
>>
>> Why? Do they have the exact SFDP tables? Prove me, drop them all.
>> Any bit that differs in the SFDP tables is enough to differentiate the
>> flavors of flashes. Vendor tables included ;)
>
> Because the SFDP is not related to OTP in any way.
> You are planning to decide OTP parameters on non relevant information.
> If you wish to implement such a broken feature, you are welcomed.
> I'll pass.
Ideally we have a single jedec,spi-nor compatible. If there are flash ID
collisions we try very hard to differentiate the flashes at run-time.
New compatibles are introduced only if we can't differentiate the flavor
at runtime (be it by parsing SFDP or some other way).
cut
>>>> And I think I already said that you can differentiate between the two
>>>> based on SFDP presence. mx25l12833f has SFDP, thus when SFDP present use
>>>> the mx25l12833f-OTP configuration. When SFDP is not presence one may add
>>>> support for the mx25l12805d-OTP configuration.
>>>
>>> No, we have 3 chips.
>>> 2 are using the same JEDEC ID and both using SFDP, yet they use a different OTP.
>>
>> Which ones are these?
>>
>> I guess mx25l12805d is non-SFDP. Then mx25l12833f and mx25l3233f define
>> some SFDP tables. Do mx25l12833f and mx25l3233f have the same OTP
>> organization?
>
> No, that is the point.
>
? Do you care to explain?
cut
>
>>>
>>>>
>>>> Is there any case that I miss?
>>>
>>> According to your reply, I would say pretty much most.
>>
>> This is again inappropriate ... I will read your next email as well, but
>> I'm not going to tolerate such replies anymore.
>
> I agree on this one.
> Seems you are looking for something I do not agree on.
Michael disagrees with OTP being specified in DT too. We both already
suggested how to deal with flash ID collisions but you keep ignoring us ...
> This is not because I oppose probing,
> this is because you ask for indirect probing, against Macronix own
> recommendation.
What did macronix exactly recommend? Did they say that we shouldn't
interrogate the SFDP data in order to differentiate the flashes at
run-time? If yes, why is that?
next prev parent reply other threads:[~2024-09-23 17:53 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-20 18:12 [PATCH v5 0/5] Add support for SPI-NOR Macronix OTP Erez Geva
2024-09-20 18:12 ` [PATCH v5 1/5] mtd: spi-nor: core: add manufacturer flags Erez Geva
2024-09-23 6:04 ` Tudor Ambarus
2024-09-23 10:31 ` Erez
2024-09-23 10:46 ` Michael Walle
2024-09-23 13:25 ` Erez
2024-09-23 16:19 ` Michael Walle
2024-09-23 16:31 ` Erez
2024-09-23 18:04 ` Tudor Ambarus
2024-09-23 18:21 ` Tudor Ambarus
2024-09-26 7:46 ` Esben Haabendal
2024-09-26 11:08 ` Erez
2024-09-26 11:37 ` Esben Haabendal
2024-09-26 13:16 ` Erez
2024-09-23 12:07 ` Tudor Ambarus
2024-09-23 13:01 ` Erez
2024-09-23 14:18 ` Tudor Ambarus
2024-09-23 14:51 ` Erez
2024-09-23 17:52 ` Tudor Ambarus [this message]
2024-09-23 19:30 ` Erez
2024-09-23 21:41 ` Erez
2024-09-24 6:04 ` Tudor Ambarus
2024-09-24 6:01 ` Tudor Ambarus
2024-09-20 18:12 ` [PATCH v5 2/5] mtd: spi-nor: core: add generic functions Erez Geva
2024-09-20 18:12 ` [PATCH v5 3/5] dt-bindings: mtd: spi-nor: add OTP parameters Erez Geva
2024-09-22 20:40 ` Krzysztof Kozlowski
2024-09-23 9:21 ` Erez
2024-09-23 15:42 ` Krzysztof Kozlowski
2024-09-23 15:49 ` Erez
2024-09-20 18:12 ` [PATCH v5 4/5] mtd: spi-nor: macronix: add support for OTP Erez Geva
2024-09-20 18:12 ` [PATCH v5 5/5] mtd: spi-nor: macronix: add manufacturer flags 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=ca2c03f7-0769-4b2a-b743-3ebda9e29755@linaro.org \
--to=tudor.ambarus@linaro.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=erezgeva2@gmail.com \
--cc=erezgeva@nwtime.org \
--cc=esben@geanix.com \
--cc=krzk+dt@kernel.org \
--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
all inboxes | Powered by JetHome®