linux-kernel - Re: [PATCH v2 1/3] mtd: spi-nor: macronix: Drop the redundant flash info fields

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]

Message-ID: <CAPB_pE+f7QGNaBgWz6OSOmfBAdCoOgnUhCV=KzUR94vWt_pEYA@mail.gmail.com>
Date: Tue, 30 Sep 2025 15:15:39 +0200
From: Maarten Zanders <maarten@...ders.be>
To: Pratyush Yadav <pratyush@...nel.org>
Cc: Cheng Ming Lin <linchengming884@...il.com>, Michael Walle <mwalle@...nel.org>, 
	Tudor Ambarus <tudor.ambarus@...aro.org>, Guenter Roeck <linux@...ck-us.net>, 
	Cheng Ming Lin <chengminglin@...c.com.tw>, miquel.raynal@...tlin.com, richard@....at, 
	vigneshr@...com, linux-mtd@...ts.infradead.org, linux-kernel@...r.kernel.org, 
	alvinzhou@...c.com.tw, leoyu@...c.com.tw
Subject: Re: [PATCH v2 1/3] mtd: spi-nor: macronix: Drop the redundant flash
 info fields

Hi all,

On Tue, Sep 30, 2025 at 2:19 PM Pratyush Yadav <pratyush@...nel.org> wrote:
> > I agree with reverting this patch. When I initially verified it, the
> > devices I had on hand all supported SFDP, so I did not catch this issue.
> > After checking again, I confirm that some older flashes without SFDP are
> > indeed affected.
>
> Do you know if these flashes are used in any devices that are actively
> used and maintained? If so, we should revert. If it is likely they
> aren't actively used, then maybe we just keep things as they are?
> Dunno...

The non-SFDP parts have been obsoleted in 2009-2010 according to
Macronix's PCN's. So they're pretty ancient.

If we choose to keep the patch in, I think we should make it more
consistent and drop support for the smaller flashes without SFDP as
well. The behavior is different in the spi-nor core for SFDP-parsed vs
non-SFDP-parsed cases.
In particular ID's 0xc22016 and 0xc22017 could be handled in the same
way I believe?

Best regards,
Maarten