From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2A9141DB130 for ; Wed, 15 Jan 2025 10:29:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736936972; cv=none; b=LbnpiK4Jjnrlv+vHH5YkHDItp2/w0Fe7LjkfdZMQvsKnBOkHQN3T/X+mRk37DTDJhVtPIoOsMS6/dmqSXMthMKfgG8SXmmIipJAqEM4XyT/175hB9mG/pvIqp512x7dC3igAdhdJWf1veZ8bLHESKTd2iRgp03BzUvzZh5K1Jn0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736936972; c=relaxed/simple; bh=bam3HRrhDyiRK1U7psGdWiyFMEjXSQD3rspHSqC64+c=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=SAdXeb/2IU5fg+zVarKskUT0iiKn5ZY0GABvD8O5QOoO1YeHIhCWNR9BCaOhYZ+QGcb6neB91xwQNjE5Rj66zrbgvrA1wwmUkHYh9IPua0kH/HUX1p5cITRi+8OEkuqNOxOEFHKy2MK+BMYrhk/5l4XuOMrouIMdxY3l11+Hliw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=O8+HEm8S; arc=none smtp.client-ip=209.85.128.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="O8+HEm8S" Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-4361e89b6daso46427175e9.3 for ; Wed, 15 Jan 2025 02:29:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1736936968; x=1737541768; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=8rS+H2/za+FOVeRQ6Rz949kNFZx5Z22FhhMvelNCIdo=; b=O8+HEm8SLZjJbQEO12T4gkwLu/du1zptLD2Pr5gQzgke5iZ/k6MEAoy67bCdX3iXGL nGJzyyQCdOLZEUFoI8BQqBIQi8sU3yJVetjv6kFxubpnWBUHShadPB3xV4tmb8JburlP 0GJyqItkZn9B2v7ZUiYHRQVwzg7Y31cHdL82B5kDr6YuzQ/ZojzXlXOEiDruRT9iMmS6 hV0msRA5qU1G5Cf77r/It4X2ddTB8jwIoZt2kbs9x8/9n8UzEhLPCXvYGs9qxmotRE+C bt20QmJ2st2JXGjt0fYcb+9E9NbNDd8zDdVBViL8jb4zp3FBqPpdyhfM5LiUf5XKM8Fz AemA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736936968; x=1737541768; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=8rS+H2/za+FOVeRQ6Rz949kNFZx5Z22FhhMvelNCIdo=; b=vhhQFaHVms9E5mQcHZvg6rW70cwHUESbUGWiSbDL8eutNudq2Jq2OiJXwa5S3ufnpx u7JDpBF7UvLlYHvgs7Bxtll0k/DDPYI4Z8VQlWDMFMWh+zxGBWXASkR+i5ou7ikZST94 lSYdBpgXJT0F1UxOeHcFL61unXcV8TogeFRvRdnQy0tupvf11Idy0XG2qw0FI/3jxL9X ED/MZbpdFwcSxWqKR3AXuY6o7MfoARiWPrZxcWS4EWHA6bpdZ6zlkgNWd8hOTWm8NaaB tHtficJFCpMn7JAmzWVrvaSwGPJIZWAWdL4zueeoYF3du//2YoU/lqpXqTP3FQBKuezQ 0a1A== X-Gm-Message-State: AOJu0YwWcaytwkGWQeJDJeADBpTdbJprgbWGO1Z9MK9ybi9s42thzdW/ 51HwoRRz7/4SGM93uLv5DBGJw+aQHDSLtMTL5zjjroPA46yVlj+obPtKGe3hxSQ= X-Gm-Gg: ASbGncs4CbhqOLJg1gZmQKrTvjHw54GHkiTwsVl8WxkUiNRGck4rH1p1dX9IaKMwjX6 PKlCsVVUE3+4bWlPhQLje/B2XWDjRILqy5NqJaCQu+EALRz8YjEeAg/reMdiyTyqEGwkUmbTN+T PKnpExoPJma0AbBxs+KF1oJpUOGMDoLlfS97zqLkbK9WukqtHDH2bkkao/Ubcwaft6mF/uWSt1z ekNomoyRgdL9ooyKyUc4D8ShI+j5sGsFty0GMpKDuy75eMn9M/udIBnOJpamXrrag== X-Google-Smtp-Source: AGHT+IEPkLdf+dQmwl7MNLODWTed7iWs5WSFxMkynpNCoh2uYyinNWX8qgFAA3QGzhF+SGJs6gR26Q== X-Received: by 2002:a05:600c:a01:b0:434:9c1b:b36a with SMTP id 5b1f17b1804b1-436e269715amr248623345e9.13.1736936968248; Wed, 15 Jan 2025 02:29:28 -0800 (PST) Received: from [192.168.0.14] ([188.26.60.120]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-437c0f02c07sm32455025e9.0.2025.01.15.02.29.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 15 Jan 2025 02:29:27 -0800 (PST) Message-ID: <878f66c3-83a4-4f83-88d8-ea2917d82d76@linaro.org> Date: Wed, 15 Jan 2025 10:29:25 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] Revert "mtd: spi-nor: core: replace dummy buswidth from addr to data" To: Pratyush Yadav , Michael Walle , Miquel Raynal , Richard Weinberger , Vignesh Raghavendra , Cheng Ming Lin , Alexander Stein Cc: linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org, alvinzhou@mxic.com.tw, leoyu@mxic.com.tw, Cheng Ming Lin References: <20250115101659.55882-1-pratyush@kernel.org> Content-Language: en-US From: Tudor Ambarus In-Reply-To: <20250115101659.55882-1-pratyush@kernel.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 1/15/25 10:16 AM, Pratyush Yadav wrote: > This reverts commit 98d1fb94ce75f39febd456d6d3cbbe58b6678795. The commit "The commit" on a new paragraph please > 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 == 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. > > 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). > > Now the tricky bit here is that spi_mem_check_buswidth() does: > > if (op->dummy.nbytes && > spi_check_buswidth_req(mem, op->dummy.buswidth, true)) > return false; > > 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. > > 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. > > 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. > > Reported-by: Alexander Stein > Closes: https://lore.kernel.org/linux-mtd/3342163.44csPzL39Z@steina-w/ fixes tag please with that: Reviewed-by: Tudor Ambarus