Re: [PATCH] spi: Handle spi-{tx, rx}-bus-width 0 as SPI_NO_TX/SPI_NO_RX

Alexey Charkov <[email protected]>
Newsgroups org.u-boot-project.lists.u-boot
Message-ID <CAKTNdwHMga0XG1zfgLYirMbVK8iVpWgjyr9x49sQ2ofPNu+w3Q@mail.gmail.com>
Hi Cole,

On Tue, Aug 18, 2026 at 5:15 AM Cole Munz <[email protected]> wrote:
>
> The spi-peripheral-props binding shipped in dts/upstream allows a bus
> width of 0, meaning no RX or TX is possible on this device. The
> switches in spi_slave_of_to_plat() only handle 1/2/4/8, so a width of
> 0 falls through to the default case and warns "spi-rx-bus-width 0 not
> supported" on every boot, even though the devicetree is valid per the
> binding. The fact that the wire is missing is then dropped from
> plat->mode.
>
> Map 0 to new SPI_NO_TX/SPI_NO_RX mode bits, as Linux has done since
> v5.12 ("spi: Add SPI_NO_TX/RX support", mainline d962608ce218).
> Bits 16 and 17 are the first free mode bits.
>
> This comes up on devices with no MISO line at all, such as a
> write-only SPI display described with spi-rx-bus-width = <0>.
>
> Signed-off-by: Cole Munz <[email protected]>
> ---
> Raised as a boot-log warning on Flipper One, whose display has no MISO
> line at all: that pin is reused as the end-of-frame GPIO. Reported at
> flipperdevices/u-boot#33, and sent here rather than to the fork as
> suggested on that issue.
>
> Verified on sandbox at 527115ef6783, with spi-rx-bus-width = <0> added
> to spi.bin@0 in arch/sandbox/dts/test.dts and CONFIG_LOG disabled, so
> warn_non_xpl() reaches the console the way it does on the board.
>
> Before:
>  $ ./u-boot -T -c "sf probe"
>  spi-rx-bus-width 0 not supported
>  spi-rx-bus-width 0 not supported
>  SF: Detected m25p16 with page size 256 Bytes, erase size 64 KiB, 2 MiB
>
> After:
>  $ ./u-boot -T -c "sf probe"
>  SF: Detected m25p16 with page size 256 Bytes, erase size 64 KiB, 2 MiB
>
> It warns twice in sandbox because both the pre- and post-reloc DM scans
> run there; the board logs it once.
>
> ut dm spi_flash, spi_xfer, spi_find, spi_claim_bus, spi_set_wordlen and
> spi_flash_func all pass with the property in place. Nothing consumes the
> new bits yet, matching d962608ce218 in Linux, where the consumers landed
> later.
>
>  drivers/spi/spi-uclass.c | 6 ++++++
>  include/spi.h            | 2 ++
>  2 files changed, 8 insertions(+)

Thanks a lot for the patch! It looks like this has no users in the
current tree, making it an effective no-op (apart from silencing the
warning).

Rockchip's SPI controller could further benefit if those bits were
wired up in the driver, as it can disable the respective FIFOs
altogether when unused. Could you please look into that as well?

Best regards,
Alexey
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.