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 4A70B2BAF7 for ; Wed, 15 Jan 2025 14:03:25 +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=1736949809; cv=none; b=DwqRciSNmCvHep5vct2YpVv9K2Yb5/sQXqC/M1C3+ajiLShGnVIdDmEedz8Vk9uQTwqSR3yxawYgbAfQaMVCT1tffHBAud2pNlDoJjsijfNpX3cHKvxHR3PRUx4x/NcrroCq8JhgSiNm7FvFAL6Q0fKjSfy/214455npxECMbls= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736949809; c=relaxed/simple; bh=b4hQ6NunCke1/CWWrRyXZHunsy0DEoKHZi66BbKVvvY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=BUkT30tbyGWDVKjNNgBp2MZ9iGuj6QLByQt4YbuzuQK40XZbmAgrDy251M01ioxrKRY0Zza085NDnezm+bCI8uUiihHn4HJKBDvq09Gfu9WzlyNU5BkxW7SeBb+vQkuUcM7Z43+yxVWYN6kx1OSHJBMzKjuhkoCxRIQMazHHq0k= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=tLaURzo1; 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="tLaURzo1" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 654CBC4CEDF; Wed, 15 Jan 2025 14:03:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1736949805; bh=b4hQ6NunCke1/CWWrRyXZHunsy0DEoKHZi66BbKVvvY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=tLaURzo178D75fShPt+NuymZ6HvqxR1pM+axBDgFdInpo0PBvBknTJdmy/UGP6VSy 8aZ4ESBtrFb/OIPbT9tes1AOi60zyqtLy+/WxterkOVumzKk4Q3zWxYShTmpEFVl2W Jxc7o8ZER+nqFeSe/uv59+CZMiX+vHFmb43qthMprJ463wcwXiOrR6CgC6vMnIoqjk 9qsrKU2b7YlL00A7DCD4w+Utm7eV00Pr3WwF39Gmpx2emef3k7E1/bUeVUpRtt3zfz vhLdyEXjr1hWoZwCsrdSxOBqrNG8C0oCx7oZZLlZ23p1rvgEblOT6vYAWRzYh8v8A8 GfGtgn7UdZAVA== 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: <87a5btslfl.fsf@bootlin.com> (Miquel Raynal's message of "Tue, 14 Jan 2025 12:07:42 +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> Date: Wed, 15 Jan 2025 14:03:23 +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; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Tue, Jan 14 2025, Miquel Raynal wrote: > Hello Pratyush, > >>> Winbond chips (maybe this is a shared capability?) accepts another >>> command, "Write Enable for Volatile Status Register (50h)", which >>> specifically change the status register bits to use the volatile method. >>> >>> Hence, if the only situation we want to solve is the status register >>> access, then we may just enable this command (this is the third solution >>> I tried to explain in the commit log), but if we think there are other >>> racy situations, this approach is not complete and we must fallback to >>> one of the approaches listed above. >> >> I am not quite sure how you fix the write-enable-being-racy bug with >> your patch. If you look at the code, spi_nor_write_enable() only calls >> the write enable command (06h), and does not call >> spi_nor_wait_till_ready() after that. After the write enable, it >> immediately executes the program or erase operation. So you never >> actually wait for all dies to be ready after a write enable. > > I will double check but my understanding is that the *status register* > write is racy, not the spi_nor_write_enable(). 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. > >> You can see an example in spi_nor_write(). It does: >> >> spi_nor_write_enable() -> spi_nor_write_data() -> >> spi_nor_wait_till_ready() > > What is racy is: act on all dies then check the status of a single die. Your patch fixes all such operations, except write enable IIUC. For operations such as write SR (or any other register) or chip erase, we would call spi_nor_wait_till_ready(), and your patch would make sure all dies are ready. But when write enable itself is racy, then we would need to add a wait after the write enable, which your patch does not do. I am a bit confused right now whether that is an actual problem or I just misread your message. If write enable itself isn't racy, then the v3 series should be good to go. > >> Do you have a consistent reproducer for the race? If so, does the patch >> actually somehow make the race go away? If so, I would be curious to >> know why. > > Not with Linux, it is a problem that has been (consistently) observed > using an rtos. It's been analysed so we know what the issue is and we > want to make sure this cannot happen using Linux. > > Thanks, > Miqu=C3=A8l --=20 Regards, Pratyush Yadav