1
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git synced 2025-01-22 07:53:11 -05:00
linux/drivers/mtd/spi-nor
Pratyush Yadav d15638bf76 Revert "mtd: spi-nor: core: replace dummy buswidth from addr to data"
This reverts commit 98d1fb94ce.

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 == 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.

Fixes: 98d1fb94ce ("mtd: spi-nor: core: replace dummy buswidth from addr to data")
Reported-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Closes: https://lore.kernel.org/linux-mtd/3342163.44csPzL39Z@steina-w/
Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Signed-off-by: Pratyush Yadav <pratyush@kernel.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2025-01-15 18:44:23 +01:00
..
controllers mtd: Switch back to struct platform_driver::remove() 2024-10-21 11:58:07 +02:00
atmel.c
core.c Revert "mtd: spi-nor: core: replace dummy buswidth from addr to data" 2025-01-15 18:44:23 +01:00
core.h mtd: spi-nor: core: Allow specifying the byte order in Octal DTR mode 2024-10-02 10:23:56 +03:00
debugfs.c
eon.c
esmt.c
everspin.c mtd: spi-nor: get rid of SPI_NOR_NO_FR 2024-05-27 17:07:15 +02:00
gigadevice.c
intel.c
issi.c
Kconfig
macronix.c mtd: spi-nor: add support for Macronix Octal flash 2024-10-04 10:40:48 +03:00
Makefile mtd: spi-nor: Remove support for Xilinx S3AN flashes 2024-05-27 16:39:21 +02:00
micron-st.c mtd: spi-nor: micron-st: Add n25q064a WP support 2024-09-14 17:56:31 +02:00
otp.c
sfdp.c mtd: spi-nor: sfdp: Get the 8D-8D-8D byte order from BFPT 2024-10-02 10:28:40 +03:00
sfdp.h mtd: spi-nor: sfdp: Get the 8D-8D-8D byte order from BFPT 2024-10-02 10:28:40 +03:00
spansion.c mtd: spi-nor: spansion: Use nor->addr_nbytes in octal DTR mode in RD_ANY_REG_OP 2024-10-29 08:23:00 +00:00
sst.c mtd: spi-nor: sst: Factor out common write operation to sst_nor_write_data() 2024-09-14 17:56:31 +02:00
swp.c
sysfs.c sysfs: treewide: constify attribute callback of bin_is_visible() 2024-11-05 14:00:28 +01:00
winbond.c mtd: spi-nor: winbond: add "w/ and w/o SFDP" comment 2024-11-11 12:26:04 +02:00
xmc.c