linux-kernel - Re: [PATCH 1/2] mtd: spi-nor: winbond: Add support for w25q01jv

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: <87zfjrlwpc.fsf@bootlin.com>
Date: Wed, 15 Jan 2025 20:10:39 +0100
From: Miquel Raynal <miquel.raynal@...tlin.com>
To: Pratyush Yadav <pratyush@...nel.org>
Cc: Tudor Ambarus <tudor.ambarus@...aro.org>,  Michael Walle
 <mwalle@...nel.org>,  Richard Weinberger <richard@....at>,  Vignesh
 Raghavendra <vigneshr@...com>,  Thomas Petazzoni
 <thomas.petazzoni@...tlin.com>,  Steam Lin <STLin2@...bond.com>,
  linux-mtd@...ts.infradead.org,  linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] mtd: spi-nor: winbond: Add support for w25q01jv

Hello Pratyush,

> Okay, I am confused because you said earlier that:
>
>> The bug that has been experienced followed this sequence:
>> - send the write enable command (non-volatile)
>> - wait for the ready/busy bit, ie. wait for the WEL bit to be set
>>   because it is non-volatile write
>> - active die is ready, (but idle die is not!)
>> - enter 4-byte address mode, only the die that is ready processes the
>>   command.
>
> Which says the WEL bit being set itself is racy. What I understand from
> that is one die is ready to take writes and the other is not. Now when
> you try to write the SR to enable 4B mode, it would only work on the die
> that got the WEL set. The other one ignores it and stays in 3B mode. Do
> I understand this correctly? To fix this you need to wait after the
> write enable, before you initiate the write SR operation.

Actually I think you're right. The thing is, Winbond WEL bit are
non-volatile by default, whereas you were assuming it would be. Maybe
the proper fix is to do both?
- Using the volatile 'write enable'
and
- Making sure we wait after the (other) commands tampering with all dies.

Thanks,
Miquèl