From: Pratyush Yadav <pratyush@kernel.org>
To: Tudor Ambarus <tudor.ambarus@linaro.org>
Cc: Pratyush Yadav <pratyush@kernel.org>,
Michael Walle <mwalle@kernel.org>,
Miquel Raynal <miquel.raynal@bootlin.com>,
Richard Weinberger <richard@nod.at>,
Vignesh Raghavendra <vigneshr@ti.com>,
Cheng Ming Lin <linchengming884@gmail.com>,
Alexander Stein <alexander.stein@ew.tq-group.com>,
linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org,
alvinzhou@mxic.com.tw, leoyu@mxic.com.tw,
Cheng Ming Lin <chengminglin@mxic.com.tw>
Subject: Re: [PATCH] Revert "mtd: spi-nor: core: replace dummy buswidth from addr to data"
Date: Wed, 15 Jan 2025 10:50:00 +0000 [thread overview]
Message-ID: <mafs0cygo5p2f.fsf@kernel.org> (raw)
In-Reply-To: <878f66c3-83a4-4f83-88d8-ea2917d82d76@linaro.org> (Tudor Ambarus's message of "Wed, 15 Jan 2025 10:29:25 +0000")
On Wed, Jan 15 2025, Tudor Ambarus wrote:
> On 1/15/25 10:16 AM, Pratyush Yadav wrote:
>> This reverts commit 98d1fb94ce75f39febd456d6d3cbbe58b6678795. The commit
>
> "The commit" on a new paragraph please
ACK, will do when applying.
>
>> 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 <alexander.stein@ew.tq-group.com>
>> Closes: https://lore.kernel.org/linux-mtd/3342163.44csPzL39Z@steina-w/
>
> fixes tag please
Hmm, I thought a fixes for a revert might be pointless since we have the
commit hash in the message anyway. I don't have a strong opinion, so
will add the below when applying:
Fixes: 98d1fb94ce75 ("mtd: spi-nor: core: replace dummy buswidth from addr to data")
>
> with that:
> Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Thanks!
--
Regards,
Pratyush Yadav
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: Pratyush Yadav <pratyush@kernel.org>
To: Tudor Ambarus <tudor.ambarus@linaro.org>
Cc: Pratyush Yadav <pratyush@kernel.org>,
Michael Walle <mwalle@kernel.org>,
Miquel Raynal <miquel.raynal@bootlin.com>,
Richard Weinberger <richard@nod.at>,
Vignesh Raghavendra <vigneshr@ti.com>,
Cheng Ming Lin <linchengming884@gmail.com>,
Alexander Stein <alexander.stein@ew.tq-group.com>,
linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org,
alvinzhou@mxic.com.tw, leoyu@mxic.com.tw,
Cheng Ming Lin <chengminglin@mxic.com.tw>
Subject: Re: [PATCH] Revert "mtd: spi-nor: core: replace dummy buswidth from addr to data"
Date: Wed, 15 Jan 2025 10:50:00 +0000 [thread overview]
Message-ID: <mafs0cygo5p2f.fsf@kernel.org> (raw)
In-Reply-To: <878f66c3-83a4-4f83-88d8-ea2917d82d76@linaro.org> (Tudor Ambarus's message of "Wed, 15 Jan 2025 10:29:25 +0000")
On Wed, Jan 15 2025, Tudor Ambarus wrote:
> On 1/15/25 10:16 AM, Pratyush Yadav wrote:
>> This reverts commit 98d1fb94ce75f39febd456d6d3cbbe58b6678795. The commit
>
> "The commit" on a new paragraph please
ACK, will do when applying.
>
>> 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 <alexander.stein@ew.tq-group.com>
>> Closes: https://lore.kernel.org/linux-mtd/3342163.44csPzL39Z@steina-w/
>
> fixes tag please
Hmm, I thought a fixes for a revert might be pointless since we have the
commit hash in the message anyway. I don't have a strong opinion, so
will add the below when applying:
Fixes: 98d1fb94ce75 ("mtd: spi-nor: core: replace dummy buswidth from addr to data")
>
> with that:
> Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Thanks!
--
Regards,
Pratyush Yadav
next prev parent reply other threads:[~2025-01-15 10:50 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-15 10:16 [PATCH] Revert "mtd: spi-nor: core: replace dummy buswidth from addr to data" Pratyush Yadav
2025-01-15 10:16 ` Pratyush Yadav
2025-01-15 10:29 ` Tudor Ambarus
2025-01-15 10:29 ` Tudor Ambarus
2025-01-15 10:50 ` Pratyush Yadav [this message]
2025-01-15 10:50 ` Pratyush Yadav
2025-01-15 11:23 ` Tudor Ambarus
2025-01-15 11:23 ` Tudor Ambarus
2025-01-15 13:25 ` Miquel Raynal
2025-01-15 13:25 ` Miquel Raynal
2025-01-15 10:39 ` Alexander Stein
2025-01-15 10:39 ` Alexander Stein
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=mafs0cygo5p2f.fsf@kernel.org \
--to=pratyush@kernel.org \
--cc=alexander.stein@ew.tq-group.com \
--cc=alvinzhou@mxic.com.tw \
--cc=chengminglin@mxic.com.tw \
--cc=leoyu@mxic.com.tw \
--cc=linchengming884@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=miquel.raynal@bootlin.com \
--cc=mwalle@kernel.org \
--cc=richard@nod.at \
--cc=tudor.ambarus@linaro.org \
--cc=vigneshr@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.