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]

Date: Mon, 1 Jul 2024 13:53:23 +0100
From: Tudor Ambarus <tudor.ambarus@...aro.org>
To: Erez <erezgeva2@...il.com>
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 7/1/24 12:03 PM, Erez wrote:
> On Mon, 1 Jul 2024 at 12:23, Tudor Ambarus <tudor.ambarus@...aro.org> wrote:
>>
>>
>>
>> On 7/1/24 11:15 AM, Tudor Ambarus 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.
>>>
>>
>> And you can then decide which OTP org to use based on whether SFDP is
>> present or not.
> 
> That can work, but sound like a hack.

It's not a hack, we're just doing our best to dynamically identify the
flash.

> Is that really that important to hack?

we push really hard against new compatibles. Users shouldn't care about
what SPI NOR flash is there.

> Just for OTP, that very few use?
> And if in the future Macronix adds a newer one with the same JEDEC ID,
> but a different OTP size?

we'll compare SFDP data and choose based on the differences. This is not
encouraged. Instead ask for unique IDs or choose other flash.

> Macronix does not consult with the Linux Kernel on these matters.
> 

I'm complaining about unique flash IDs for years now. Hopefully vendors
have learnt their lesson. I didn't see new flash designs reusing old IDs.

> Anyhow as I do not have the hardware anymore, I can not do more
> changes and test them.
> 

Be aware that we're not queuing patches without some minimal tests. If
you don't have the hardware, contact mchp and see if they care,
otherwise we're wasting our time. Here are the minimum testing requirements:
https://docs.kernel.org/driver-api/mtd/spi-nor.html#minimum-testing-requirements
For OTP we'll also need some OTP tests.

Cheers,
ta