The Altera SPI driver currently uses the spi-bitbang infrastructure for
transfer queue management, but non of the bitbang functionality itself.
This is because when the driver was written this was the only way to not
have to do queue management in the driver itself.

Nowadays transfer queue management is available from the SPI driver core
itself and using the bitbang infrastructure just adds an additional level
of indirection.

Switch the driver over to using the core queue management directly.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>

When the audio driver selects CONFIG_PXA_SSP on ARCH_MMP as a
loadable module, and the PXA SPI driver is built-in, we get
a link error in the SPI driver:

drivers/spi/spi-pxa2xx.o: In function `pxa2xx_spi_remove':
spi-pxa2xx.c:(.text+0x5f0): undefined reference to `pxa_ssp_free'
drivers/spi/spi-pxa2xx.o: In function `pxa2xx_spi_probe':
spi-pxa2xx.c:(.text+0xeac): undefined reference to `pxa_ssp_request'
spi-pxa2xx.c:(.text+0x1468): undefined reference to `pxa_ssp_free'
spi-pxa2xx.c:(.text+0x15bc): undefined reference to `pxa_ssp_free'

The problem is that the PXA SPI driver only uses 'select SSP'
specifically when building it for PXA, but we can also build it
for PCI, which is meant for Intel x86 SoCs that use the same SPI
block. When the sound driver forces the SSP to be a loadable
module, the IS_ENABLED() check in include/linux/pxa2xx_ssp.h
triggers but the spi driver can't reference the exported symbols.

I had a different approach before, making the PCI case depend
on X86, which fixed the problem by avoiding the MMP case.

This goes a different route, making the driver select PXA_SSP
also on MMP, which has an SSP that none of the boards in mainline
Linux use for SPI. There is no harm in always enabling the build
on MMP (PCI or not PCI), so I do that too, to document that this
hardware is actually available on MMP.

Link: https://patchwork.kernel.org/patch/8879921/
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mark Brown <broonie@kernel.org>

The STM32 Serial Peripheral Interface (SPI) can be used to communicate
with external devices while using the specific synchronous protocol. It
supports a half-duplex, full-duplex and simplex synchronous, serial
communication with external devices with 4-bit to 16/32-bit per word. It
has two 8x/16x 8-bit embedded Rx and TxFIFOs with DMA capability. It can
operate in master or slave mode.

Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

Add an example SPI slave handler to allow remote control of system
reboot, power off, halt, and suspend.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

Add an example SPI slave handler responding with the uptime at the time
of reception of the last SPI message.

This can be used by an external microcontroller as a dead man's switch.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

Add support for registering SPI slave controllers using the existing SPI
master framework:
  - SPI slave controllers must use spi_alloc_slave() instead of
    spi_alloc_master(), and should provide an additional callback
    "slave_abort" to abort an ongoing SPI transfer request,
  - SPI slave controllers are added to a new "spi_slave" device class,
  - SPI slave handlers can be bound to the SPI slave device represented
    by an SPI slave controller using a DT child node named "slave",
  - Alternatively, (un)binding an SPI slave handler to the SPI slave
    device represented by an SPI slave controller can be done by
    (un)registering the slave device through a sysfs virtual file named
    "slave".

From the point of view of an SPI slave protocol handler, an SPI slave
controller looks almost like an ordinary SPI master controller. The only
exception is that a transfer request will block on the remote SPI
master, and may be cancelled using spi_slave_abort().

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mark Brown <broonie@kernel.org>