linux-kernel - Re: [PATCH 1/2] mtd: spinand: add support for detection with param page

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] [day] [month] [year] [list]

Date:   Tue, 17 May 2022 09:35:50 +0200
From:   Frieder Schrempf <frieder.schrempf@...tron.de>
To:     Chuanhong Guo <gch981213@...il.com>
Cc:     linux-mtd@...ts.infradead.org,
        Miquel Raynal <miquel.raynal@...tlin.com>,
        Richard Weinberger <richard@....at>,
        Vignesh Raghavendra <vigneshr@...com>,
        Patrice Chotard <patrice.chotard@...s.st.com>,
        Boris Brezillon <boris.brezillon@...labora.com>,
        Christophe Kerello <christophe.kerello@...s.st.com>,
        Mark Brown <broonie@...nel.org>,
        Daniel Palmer <daniel@...f.com>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] mtd: spinand: add support for detection with param
 page

Am 16.05.22 um 16:10 schrieb Chuanhong Guo:
> Hi!
> 
> On Mon, May 16, 2022 at 3:38 PM Frieder Schrempf
> <frieder.schrempf@...tron.de> wrote:
>>
>> Hi Chuanhong,
>>
>> Am 14.04.22 um 16:34 schrieb Chuanhong Guo:
>>> SPI-NAND detection using chip ID isn't always reliable.
>>> Here are two known cases:
>>> 1. ESMT uses JEDEC ID from other vendors. This may collapse with future
>>>    chips.
>>> 2. Winbond W25N01KV uses the exact same JEDEC ID as W25N01GV while
>>>    having completely different chip parameters.
>>
>> I think they share the same first byte of the JEDEC ID, but the second
>> byte actually differs and would allow to differentiate between them, right?
> 
> No. For the 128M version, all 3 bytes are the same between
> W25N01GV and W25N01KV.
> 
>>
>> I have this patchset [1] that I didn't manage to send upstream yet which
>> adds support for the W25N02KV. I added the second ID byte to detect them.
>>
>> Still your approach using the ONFI data is more flexible of course and
>> probably a better way to handle this. I will see if I can find some time
>> to add support for the W25N02KV based on your patches.
> 
> Don't do that. I abandoned this patchset because I later found that
> some early W25N01GV doesn't contain a parameter page at all,
> which means detecting W25N01GV/KV using only the parameter
> page is unreliable.
> I think what Boris proposed earlier in v1 (use parameter page
> just to distinguish the two chips) is the correct way to go.
> 
> BTW I was making this patchset for a potential future ID conflict
> between ESMT and GigaDevice, and I don't actually need to
> deal with the W25N01GV/KV nonsense now, so I don't have a
> plan for send a new version of this atm.

Ok, what a mess. Thanks for the explanations. I will try to send my
original patches for supporting W25N02KV then.