From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from relay1-d.mail.gandi.net (relay1-d.mail.gandi.net [217.70.183.193]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4D3F11FC8 for ; Mon, 20 Jan 2025 12:47:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.70.183.193 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737377229; cv=none; b=azWGu983rUpOgDXtiZ5LUSmkek3q3EvGF6aTkQWniduvdSfdez5uF+WmHCurGmJj/IkwMDntAjCML9QJrI5lzXCdaUI48YrHT7jyC3qIjs5Sm7M5tz0ay3Jm0FkuZRrbOSYVgBzaIpObCK7O18x8Yh5noeGADHbl1voLWNCkjgI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737377229; c=relaxed/simple; bh=4C98rxGC3kvSwq649WzlHbQe4WkkaIEGcaAhVuuU57E=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=sTC5MtXkDZt8gYGtcXkYuvErX47yn4rp31o1yzfc5Mr6xSdN5HB9Z0OcmE90AYTOq7dcxk4AE7DBbyoIW86sIP4bKBJx4F8C0tUPUlpWSMsd8D+JzaZOt7KqDjey7pE4wQqqlHYk29hs3ZhqRManxE43ohJCv++TuOtAc9B0RL8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com; spf=pass smtp.mailfrom=bootlin.com; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b=iul40Ob8; arc=none smtp.client-ip=217.70.183.193 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bootlin.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b="iul40Ob8" Received: by mail.gandi.net (Postfix) with ESMTPSA id 97BD3240006; Mon, 20 Jan 2025 12:47:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1737377225; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Pybhlp0sJJPGmvMFF+Q4zrcQH0eGqr+y65cHiD+UM64=; b=iul40Ob8F2t57mhP2461QNZoMg30Z8wLSAQLIqZChGLMXlkGkZpdQHoVSooyIZGTHpfQrK Fpd6Ujlh8ry8rcSI7XM5pLMhTMEsYdhl0p8sd0M+f+yy3ILFP3YkUoOlNRjNvvSBkPsoaJ OZXdjYnsUv0P8h4ZKRctB/8HBfry564zFkKjIPem0aXRMEH78u1lct/VFrxzv5C5DqT5jg F3/D55mASFEhn/x2hI6rSRppgnleBRUfmTEtI0Euqy/oTZ8nEtbs5+1rMQ29GKtBxcUSXo tBY7LnBtboXiOOSx6icQ8Jn24/CNz3XVGzYowLOB8rhJ32NFrfMMRHWoX3dUOQ== From: Miquel Raynal To: Pratyush Yadav Cc: Tudor Ambarus , Michael Walle , Richard Weinberger , Vignesh Raghavendra , Thomas Petazzoni , Steam Lin , linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] mtd: spi-nor: winbond: Add support for w25q01jv In-Reply-To: (Pratyush Yadav's message of "Wed, 15 Jan 2025 14:03:23 +0000") References: <20241224-winbond-6-12-rc1-nor-volatile-bit-v1-0-f7c4dff66182@bootlin.com> <20241224-winbond-6-12-rc1-nor-volatile-bit-v1-1-f7c4dff66182@bootlin.com> <871pxp798c.fsf@bootlin.com> <87a5btslfl.fsf@bootlin.com> User-Agent: mu4e 1.12.7; emacs 29.4 Date: Mon, 20 Jan 2025 13:47:04 +0100 Message-ID: <87jzapsldj.fsf@bootlin.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-GND-Sasl: miquel.raynal@bootlin.com Hi 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. Sorry for the confusion, I got myself confused as well. I double checked with Winbond and I think I have the correct explanation now: The WEL bit is volatile, there is no delay when setting it (well, about 10ns, but no specific deviation). On most chips, WEL enables all write operations: * (single/dual/quad) page programs * (sector/block/chip) erases * status register write * erase/program of other internal registers (like security registers) On Winbond, the above applies, but with the usual "Write Enable command (06h)", the status register bits are non-volatile, ie. they are stored in non-volatile cells (which takes time to program and are subject to deviations across dies). Hence, they added another command, called "Write Enable for Volatile Status Register (50h)" which is an addition to the usual "Write Enable command (06h)" which causes: - enabling writes on the status register only (if the WEL bit is not yet set) - using volatile writes for the status register bits (ie. they are using some kind of local cache which update almost immediately). So basically, if you do the following: - status register write - check the status bit with the standard helper - (and quickly after) do anything else on the idle die In this case you could experience a race, but that is not related to the Write Enable command. In general I believe enabling volatile status register writes would not be useful as long as we have the "read the status from all dies" workaround. Let me know if something is still unclear. Thanks, Miqu=C3=A8l