Hi,
--- 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 = spi_nor_get_protocol_addr_nbits(proto); if (op->dummy.nbytes)
op->dummy.buswidth = spi_nor_get_protocol_addr_nbits(proto);
op->dummy.buswidth = spi_nor_get_protocol_data_nbits(proto);Facing recently a similar issue myself in the SPI NAND world, I believe we should get rid of the notion of bits when it comes to the dummy phase. I would appreciate a clarification like "dummy.cycles" which would typically not require any bus width implications.
I agree. All peripheral drivers convert cycles to bytes, and controller drivers convert them back to cycles. This whole thing should be avoided, especially since it contains some traps with division truncation.
Here is the relevant discussion: https://lore.kernel.org/linux-mtd/f647e713a65f5d3f0f2e3af95c4d0a89@walle.cc/
TLDR: yes, please use the notion of (clock) cycles. But there are some problems to solve first.
Since we are quite late in the cycle, and that changing spi_mem_check_buswidth() might cause all sorts of breakages, I think the best idea currently would be to revert this patch, and resend it with the other changes later.
Tudor, Michael, Miquel, what do you think about this? We are at rc7 but I think we should send out a fixes PR with a revert. If you agree, I will send out a patch and a PR.
Either way I am fine. the -rc cycles are also available for us to settle. But it's true we can bikeshed a little bit, so feel free to revert this patch before sending the MR.
To be clear, since the patch was added in v6.13-rc1 I want to revert it via a fixes pull request to Linus before he releases v6.13 this week. I want to fix it in v6.13, not in v6.14.
Since it's clearly a regression, I'd revert it.
-michael