From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 651391B4F02 for ; Mon, 20 Jan 2025 14:21:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737382909; cv=none; b=PvTrQWzjvwQL6jvTTX3bslCBhg1M4SRggBkU7ql7YRan3yljaXycGApiGfB40xbDVs9NUV6J3xgp+hluIBNYrE1L5Yd2k+E+SRnH+sV6E6r8DPi5DkQJ8aGL+Lz/0XNNAthUVO35kcS4KehAdm3x4PwQkg4v5qoBxrHRqexiUM4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737382909; c=relaxed/simple; bh=Az6SynehWb3YHdMOWDBRx9rT4GMdrci9soACShJwNiY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=uv7iAREuaCpE2kkWUoq9yJkfZhEx376Cd5sdIFNkD37aj6/ltpmvcRZlfkhC1DOt47plTClWiaQK5SOuB74ZyGOBygUAORyci9KW3+zoTVVLRsAJ6+YxAanNZqXEcxk0W/ahA7UOyJyI508i7rjiaSuK2W3Yb0TvB4tERQkFNgE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=NXZkxySZ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="NXZkxySZ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 35605C4CEDD; Mon, 20 Jan 2025 14:21:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1737382908; bh=Az6SynehWb3YHdMOWDBRx9rT4GMdrci9soACShJwNiY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=NXZkxySZjb3P+/EZFz6uK87vE5uYtFuosXx0Kphr/PvfCIAm0r/zJVgUb6GjV13U6 m8LPF3cSeFen8krcDvzhzt9y63pgy1aMEIeRAZ9TX3YpWkE+NROCIhGe/v8hj9ThS7 SXhpfAPoIl+yJ2Oxlie0LfR8kM2+hnXw1uiXgRHt1L3XoJ4yw6ZxQfF73tjUpQVCmV 3A8FqfUoUrQyrozDHZ1F0/vgTWNVVqijoG0G84IkNfnyv2V1wSQ7cF3acLv9jmXRMj G+uB9nelFuIseLIr+3FX0mrBt6hRy8NmroJDlh0jdc49vU2Bs0dgfYzHEt0TV2G2/l Qn7pbyYJMmcvQ== From: Pratyush Yadav To: Miquel Raynal Cc: Pratyush Yadav , 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: <87jzapsldj.fsf@bootlin.com> (Miquel Raynal's message of "Mon, 20 Jan 2025 13:47:04 +0100") 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> <87jzapsldj.fsf@bootlin.com> Date: Mon, 20 Jan 2025 14:21:46 +0000 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On Mon, Jan 20 2025, Miquel Raynal wrote: > 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. Ah, okay. That all makes sense now. With this explanation, your patches should be doing the right thing. I will do a round of review on the v3 soon, but they looked mostly good when I last took a brief look. -- Regards, Pratyush Yadav