Re: [PATCH RFC v2] mtd: spinand: winbond: add support for W25N04LW

From: Dominique Martinet <dominique.martinet@atmark-techno.com>
To: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Richard Weinberger <richard@nod.at>,
	Md Sadre Alam <md.alam@oss.qualcomm.com>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
	Daisuke Mizobuchi <mizo@atmark-techno.com>
Subject: Re: [PATCH RFC v2] mtd: spinand: winbond: add support for W25N04LW
Date: Wed, 12 Aug 2026 17:08:14 +0900	[thread overview]
Message-ID: <anwp7lxvdKOEr3Vw@atmark-techno.com> (raw)
In-Reply-To: <87tsozn63o.fsf@bootlin.com>

Miquel Raynal wrote on Wed, Aug 12, 2026 at 09:35:55AM +0200:
> On 12/08/2026 at 14:04:30 +09, Dominique Martinet <dominique.martinet@atmark-techno.com> wrote:
> 
> > Dominique Martinet wrote on Wed, Aug 12, 2026 at 04:14:02AM +0000:
> >> +	// the W25N04LW chip actually has two free ranges per section:
> >> +	// "User Data I" at (16 * section) + 4, length 12
> >> +	// "User Data II" at (16 * section) + 2, length 2
> >> +	// The later is not ECC protected so this only returns User Data I
> >
> > (will fix to use block comment like the rest of the file + latter typo
> > as per Sashiko comment in v3, after we've reached an agreement on what
> > to do here -- there were no other Sashiko comment)
> 
> I haven't checked the diff yet, but the commit message contains a SoB
> from anther person which is listed first. You must be Author + first SoB or
> you can give someone else authorship + first SoB and take 2nd SoB (which
> means you carried the patch without changing it). If you want to credit
> another person, please have a look at the Co-developed-by wording.

Thanks, will add a Co-developed-by tag for them in v3 after other
discussions are settled

I've also been stressing/torturing the nand a bit and I'm noticing a lot
of ECC errors (regardless of erase cycle count); all ECC errors are
apparently focused on two bits regardless of the sector the error
happened on (bit 0x20 at offset either 0x7e or 0x80 in any sector,
from checking data with nanddump -n and diffing the output)

This error is reliably readable so it happened on write, but
erase+nandwrite properly clears the error, and there's just too many
(~20-40 over 1MB of data, so 2048 512 bytes sectors), so I think that's
worth investigating further before applying even if I don't see what
could possibly cause this in the nand code

(Well, I guess it could also just be how this batch turned out, but I'm
surprised that the errors would always happen on the same two bits...
It didn't happen with the 04KW so hopefully not a SPI bug either...)

I need to wait next week to test on different hardware to rule out a
hardware bug and I'll reach out to our contact at winbond as well

Thanks,
-- 
Dominique

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/