From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) (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 8B3531D63EF for ; Wed, 15 Jan 2025 19:10:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.70.183.196 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736968245; cv=none; b=cYru8SQae7UeJKnf7nkhI7ZQ4s74tLe4VEhHO4Lw6TyiLOAA0cp4lPPrQKh4E1E6F9z1nkl6HbgjPwRQ9ioPQCOe0k1QpEz1r0RuLaCJsPIpkUMrViqtgvij/A/bBFoU00LIXkTYiD7YwIpa0rJlTunVKbO8doEwmYXNuQVTF5w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736968245; c=relaxed/simple; bh=yEuYeVWWXVgGMn2Juq2V8jl0q9wLYpgIOFfGrZNKlwM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=RMPpF8vGtWklyqWsxdfsTNHbVnPDcDoBqwFuKQGYmwQyI0Xjl0ErIGDG3xTJFEFliqge9MubpLSAsBbCBWLyNLnjgIYGqz52kCv4hrk3kSHzrRkcFwd+g/IUz/FkOvcvJMr1DNsDk+dAStarc8QVg26t3R9N14+R6igK4XwQl0U= 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=dYW3fNqc; arc=none smtp.client-ip=217.70.183.196 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="dYW3fNqc" Received: by mail.gandi.net (Postfix) with ESMTPSA id 9B0B8E0008; Wed, 15 Jan 2025 19:10:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1736968241; 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=Lgg79FAUQ3apwglQPr9QuwItHd0jkyUfYOTHfbHRuMk=; b=dYW3fNqcQAO7L28FMjnZEpKLztgO40DTmoX0CmXkXWeQYGhBSzwtQ8tqV/eCbHbiuQBX42 ksQdrBwswuqCm54kIOXJxolbfDYEOq1nz9v4nkUgkIdFLkjr6GmNrPhaLeNKD/H0/yVrQG TbDgelA0SEw7ypOiFtnpUdJT8PzXkYhZ83X3eS0UeKm7E0miDB1DFPDTzhn7PzE5HaKhAk rFtZNkN3x4yR53WmXiZxmjRmpBLqxTnMWeQSnmaCqcOhK5vGJ2go6/ThZW6mI1ic6rLCxH 1Q3mbgJJkkpJ5lZfxFr5fvXuQutkfWv4ngmlfJ85be9JwYAeKbMjDiixZXtrPg== 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: Wed, 15 Jan 2025 20:10:39 +0100 Message-ID: <87zfjrlwpc.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 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=C3=A8l