From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx1.tq-group.com (mx1.tq-group.com [93.104.207.81]) (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 D2FC2248BA0 for ; Wed, 15 Jan 2025 10:39:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=93.104.207.81 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736937588; cv=none; b=n/GT/1YBWuhhgpMKShX4s0SkYQAKIMNYfDjuXDJmSFceMJsZssa54TbByOBFe45llTT6eFJ/nHjMRvPQ7FF0MBmrmYXh7R2AvV63V3Fax3ARmv1Gs/oQ4jcyCHzuqWJY0C0vQpuMVuljtds4UKwdtE94aSmTaveFUXLiyThQslY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736937588; c=relaxed/simple; bh=CWJy5DxpyUXeoBO4BswgnyAz2hnlFBhGSINzeeXtGfM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=MrpMYO4spd5do+RaKtXboX50YP+sGk6eFY5dsZ6DFDFVskQBODKQnl85qB90fSsLdxkqbcPanWEokFRIiSC2xDVCyus9QTBFtfqAsaxG5nwAqOdyETeIZzTHeJrs1UVgqnt/Zs07N0vrkSv4WLhIXHcHM7LprMu60RwCDjhMdnw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ew.tq-group.com; spf=pass smtp.mailfrom=ew.tq-group.com; dkim=pass (2048-bit key) header.d=tq-group.com header.i=@tq-group.com header.b=huKTwt3Z; dkim=fail (0-bit key) header.d=ew.tq-group.com header.i=@ew.tq-group.com header.b=KkAuld1L reason="key not found in DNS"; arc=none smtp.client-ip=93.104.207.81 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ew.tq-group.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ew.tq-group.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=tq-group.com header.i=@tq-group.com header.b="huKTwt3Z"; dkim=fail reason="key not found in DNS" (0-bit key) header.d=ew.tq-group.com header.i=@ew.tq-group.com header.b="KkAuld1L" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tq-group.com; i=@tq-group.com; q=dns/txt; s=key1; t=1736937584; x=1768473584; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=J/OWSjf0XNBEykGMNeRNXxNa+eHMYOtoVlDnXA5xfcs=; b=huKTwt3ZPNsSPKpng/LvUGpBCdLb0v6tAUry9UvbqYOUEr6+MMLxzHnR X9GAaArff6nB4tj+PWbV6uQ2iLKO2i8pqtv/3bbM59cu2PY5IO6yxnVUU CC+yvmWAFnvgEOhCOPPlgojTu52hrgTx1PVav1EZhw7Zg3N/pNkgP3IlS +MVrTqQpX4AwFCdTVOTAktZfyTnUQAOkFUtkTu68G15RSYUw4uA723dH8 OKa+gn4rbpzyeKZTuIGRW2PEnZAohvWg7NI6jrM8rzFOCI3YhpdaUmw8z rD0NYzUWnYMkenJ2GD2bZqY5qSLUseQUmfmu2iN7f/9sCHcj0HkBQzFzG g==; X-CSE-ConnectionGUID: sHz1iQjmR+WNHDLuc1DEHA== X-CSE-MsgGUID: 6dS5h6sJT46CgKNhRlgYfw== X-IronPort-AV: E=Sophos;i="6.12,317,1728943200"; d="scan'208";a="41063859" Received: from vmailcow01.tq-net.de ([10.150.86.48]) by mx1.tq-group.com with ESMTP; 15 Jan 2025 11:39:37 +0100 X-CheckPoint: {67879069-1F-C6D8D88D-F91F9E6B} X-MAIL-CPID: 13FDA1A27EC9483961BD22B522224BCE_2 X-Control-Analysis: str=0001.0A682F18.67879069.00C5,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0 Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 835D516878B; Wed, 15 Jan 2025 11:39:23 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ew.tq-group.com; s=dkim; t=1736937573; 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=J/OWSjf0XNBEykGMNeRNXxNa+eHMYOtoVlDnXA5xfcs=; b=KkAuld1L2bu8S873gMPOTmV6cCjM0jHawBkHxkA+vJ8l5yTWxvsPwHU1IF9hYltoi4pdIx pLqUE7erXU8yTwHkFv1z01vuI+x1tpp55sY2khy2jHAblEpowW2pH8GYPJI6TmSfoBqV3N WeVsXRI0ATRMPq0bfnMZBjdsYKc4IpcRC2fwry7p0kTALeLnlyNf5hMERBc8EF1ggWTN2Q WRNRaz8VEUNfxln3DBGehd5w9BI0fmbCX3hbcPLIiZ2dwdhcA7/+NjS6V2KxQvOcOG//Ro Eb8i6JInRDqDDLfUXbQ5Iivb+H7xC2BhFqmBpwtJ4fIYyDtyAw+CtYYTfFy0sw== From: Alexander Stein To: Tudor Ambarus , Pratyush Yadav , Michael Walle , Miquel Raynal , Richard Weinberger , Vignesh Raghavendra , Cheng Ming Lin , Pratyush Yadav Cc: linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org, alvinzhou@mxic.com.tw, leoyu@mxic.com.tw, Cheng Ming Lin Subject: Re: [PATCH] Revert "mtd: spi-nor: core: replace dummy buswidth from addr to data" Date: Wed, 15 Jan 2025 11:39:24 +0100 Message-ID: <2016480.usQuhbGJ8B@steina-w> Organization: TQ-Systems GmbH In-Reply-To: <20250115101659.55882-1-pratyush@kernel.org> References: <20250115101659.55882-1-pratyush@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-Last-TLS-Session-Version: TLSv1.3 Am Mittwoch, 15. Januar 2025, 11:16:52 CET schrieb Pratyush Yadav: > This reverts commit 98d1fb94ce75f39febd456d6d3cbbe58b6678795. The commit > uses data nbits instead of addr nbits for dummy phase. This causes a > regression for all boards where spi-tx-bus-width is smaller than > spi-rx-bus-width. It is a common pattern for boards to have > spi-tx-bus-width =3D=3D 1 and spi-rx-bus-width > 1. The regression causes > all reads with a dummy phase to become unavailable for such boards, > leading to a usually slower 0-dummy-cycle read being selected. >=20 > Most controllers' supports_op hooks call spi_mem_default_supports_op(). > In spi_mem_default_supports_op(), spi_mem_check_buswidth() is called to > check if the buswidths for the op can actually be supported by the > board's wiring. This wiring information comes from (among other things) > the spi-{tx,rx}-bus-width DT properties. Based on these properties, > SPI_TX_* or SPI_RX_* flags are set by of_spi_parse_dt(). > spi_mem_check_buswidth() then uses these flags to make the decision > whether an op can be supported by the board's wiring (in a way, > indirectly checking against spi-{rx,tx}-bus-width). >=20 > Now the tricky bit here is that spi_mem_check_buswidth() does: >=20 > if (op->dummy.nbytes && > spi_check_buswidth_req(mem, op->dummy.buswidth, true)) > return false; >=20 > The true argument to spi_check_buswidth_req() means the op is treated as > a TX op. For a board that has say 1-bit TX and 4-bit RX, a 4-bit dummy > TX is considered as unsupported, and the op gets rejected. >=20 > The commit being reverted uses the data buswidth for dummy buswidth. So > for reads, the RX buswidth gets used for the dummy phase, uncovering > this issue. In reality, a dummy phase is neither RX nor TX. As the name > suggests, these are just dummy cycles that send or receive no data, and > thus don't really need to have any buswidth at all. >=20 > Ideally, dummy phases should not be checked against the board's wiring > capabilities at all, and should only be sanity-checked for having a sane > buswidth value. Since we are now at rc7 and such a change might > introduce many unexpected bugs, revert the commit for now. It can be > sent out later along with the spi_mem_check_buswidth() fix. >=20 > Reported-by: Alexander Stein > Closes: https://lore.kernel.org/linux-mtd/3342163.44csPzL39Z@steina-w/ > Signed-off-by: Pratyush Yadav > --- >=20 > I have only compile-tested this patch. Alexander, if you can send your Te= sted-by > it would be great! Sure, thanks also for the great and lengthy explanation. Tested-by: Alexander Stein > Miquel, since the bug was introduced in v6.13-rc1, I want to have this pa= tch go > in v6.13. So you would have to send Linus a pull request before he likely > releases it this Sunday. How do you want to take the patch? Do you want t= o apply > it directly to mtd/fixes or should I send out a pull request from a > spi-nor/fixes branch? >=20 > drivers/mtd/spi-nor/core.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) >=20 > diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c > index 66949d9f0cc5a..b6f374ded390a 100644 > --- a/drivers/mtd/spi-nor/core.c > +++ b/drivers/mtd/spi-nor/core.c > @@ -89,7 +89,7 @@ void spi_nor_spimem_setup_op(const struct spi_nor *nor, > op->addr.buswidth =3D spi_nor_get_protocol_addr_nbits(proto); > =20 > if (op->dummy.nbytes) > - op->dummy.buswidth =3D spi_nor_get_protocol_data_nbits(proto); > + op->dummy.buswidth =3D spi_nor_get_protocol_addr_nbits(proto); > =20 > if (op->data.nbytes) > op->data.buswidth =3D spi_nor_get_protocol_data_nbits(proto); >=20 =2D-=20 TQ-Systems GmbH | M=FChlstra=DFe 2, Gut Delling | 82229 Seefeld, Germany Amtsgericht M=FCnchen, HRB 105018 Gesch=E4ftsf=FChrer: Detlef Schneider, R=FCdiger Stahl, Stefan Schneider http://www.tq-group.com/