Message-ID: <ca2c03f7-0769-4b2a-b743-3ebda9e29755@linaro.org>
Date: Mon, 23 Sep 2024 18:52:58 +0100
From: Tudor Ambarus <tudor.ambarus@...aro.org>
To: Erez <erezgeva2@...il.com>
Cc: 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>, Esben Haabendal <esben@...nix.com>
Subject: Re: [PATCH v5 1/5] mtd: spi-nor: core: add manufacturer flags



On 9/23/24 3:51 PM, Erez wrote:
> On Mon, 23 Sept 2024 at 16:18, Tudor Ambarus <tudor.ambarus@...aro.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?

Powered by blists - more mailing lists