The DesignWare SPI controller can act as a host or a target; the
choice between the two is set in hardware and cannot be changed by
software. When configured in target mode, the controller has a much
reduced set of capabilities. It only has a single chip-select input and
can only run standard SPI mode (no dual, quad, or octal mode). Despite
this, the overall logic of doing an SPI transfer and the register layout
is identical between both modes, so implementing the target mode reuses
much of the existing code.

The first part of this two-patch series renames the spi_controller to
ctlr instead of host and also changes the suffix of the related functions
to controller. This is done to avoid confusion when referring to the
controller in target mode.

The second patch implements the target mode support by allocating an
SPI controller of the correct type based on the spi-slave property. The
controller is then configured differently depending on the mode. For
an SPI transfer, the same transfer_one() callback is used, with the
difference being in dw_spi_update_config() where only the CTRLR0
register is set. The other registers are not relevant in target mode
and are read-only.

I am posting this as an RFC because I could only perform partial testing
on my setup. I am using an SoC with two DesignWare SPI memory-mapped
controllers identified as Synopsys DWC APB SSI v4.03, one in host mode and
the other in target mode. On the evaluation board, a microcontroller acts
as an SPI relay between the two, but it has some limitations. The number
of bits per word is fixed, as are the clock phase and polarity. It also
only copies data from the host to the target. With this limited setup,
I did test that data can be successfully transferred from the host
to the target using spidev_test. I also checked that polling works by
temporarily disabling the IRQ, but I cannot test DMA. Therefore, more
testing on different devices would be welcome.

Signed-off-by: Benoît Monin <benoit.monin@bootlin.com>
---
Benoît Monin (2):
      spi: dw: rename the spi controller to ctlr
      spi: dw: add target mode support

 drivers/spi/spi-dw-bt1.c  |   4 +-
 drivers/spi/spi-dw-core.c | 188 +++++++++++++++++++++++++++-------------------
 drivers/spi/spi-dw-dma.c  |  22 +++---
 drivers/spi/spi-dw-mmio.c |   9 +--
 drivers/spi/spi-dw-pci.c  |   8 +-
 drivers/spi/spi-dw.h      |  12 +--
 6 files changed, 135 insertions(+), 108 deletions(-)
---
base-commit: e5f0a698b34ed76002dc5cff3804a61c80233a7a
change-id: 20250910-spi-dw-target-5b299400917b

Best regards,
-- 
Benoît Monin, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

On Thu, 02 Oct 2025 14:14:36 +0200, Benoît Monin wrote:
> The DesignWare SPI controller can act as a host or a target; the
> choice between the two is set in hardware and cannot be changed by
> software. When configured in target mode, the controller has a much
> reduced set of capabilities. It only has a single chip-select input and
> can only run standard SPI mode (no dual, quad, or octal mode). Despite
> this, the overall logic of doing an SPI transfer and the register layout
> is identical between both modes, so implementing the target mode reuses
> much of the existing code.
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next

Thanks!

[1/2] spi: dw: rename the spi controller to ctlr
      commit: b926b15547d29a88932de3c24a05c12826fc1dbc
[2/2] spi: dw: add target mode support
      commit: fe8cc44dd173cde5788ab4e3730ac61f3d316d9c

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark