kernel/linux.git/include/linux/spi/spi.h, branch v4.19.77

spi: Get rid of the spi_flash_read() API

2018-05-11T02:34:41+00:00

This API has been replaced by the spi_mem_xx() one, its only user (spi-nor) has been converted to spi_mem_xx() and all SPI controller drivers that were implementing the ->spi_flash_xxx() hooks are also implementing the spi_mem ones. So we can safely get rid of this API. Signed-off-by: Boris Brezillon Reviewed-by: Frieder Schrempf Tested-by: Frieder Schrempf Signed-off-by: Mark Brown

spi: Extend the core to ease integration of SPI memory controllers

2018-05-11T02:32:43+00:00

Some controllers are exposing high-level interfaces to access various kind of SPI memories. Unfortunately they do not fit in the current spi_controller model and usually have drivers placed in drivers/mtd/spi-nor which are only supporting SPI NORs and not SPI memories in general. This is an attempt at defining a SPI memory interface which works for all kinds of SPI memories (NORs, NANDs, SRAMs). Signed-off-by: Boris Brezillon Reviewed-by: Frieder Schrempf Tested-by: Frieder Schrempf Signed-off-by: Mark Brown

spi: Fix double "when"

2017-11-30T16:55:35+00:00

Signed-off-by: Geert Uytterhoeven Signed-off-by: Mark Brown

spi: Generalize SPI "master" to "controller"

2017-06-13T17:51:11+00:00

Now struct spi_master is used for both SPI master and slave controllers, it makes sense to rename it to struct spi_controller, and replace "master" by "controller" where appropriate. For now this conversion is done for SPI core infrastructure only. Wrappers are provided for backwards compatibility, until all SPI drivers have been converted. Noteworthy details: - SPI_MASTER_GPIO_SS is retained, as it only makes sense for SPI master controllers, - spi_busnum_to_master() is retained, as it looks up masters only, - A new field spi_device.controller is added, but spi_device.master is retained for compatibility (both are always initialized by spi_alloc_device()), - spi_flash_read() is used by SPI masters only. Signed-off-by: Geert Uytterhoeven Signed-off-by: Mark Brown

spi: core: Add support for registering SPI slave controllers

2017-05-26T12:11:00+00:00

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 Signed-off-by: Mark Brown

Merge remote-tracking branches 'spi/topic/ti-qspi' and 'spi/topic/xlp' into spi-next

2017-04-26T14:58:22+00:00

Merge remote-tracking branches 'spi/topic/devprop', 'spi/topic/fsl', 'spi/topic/fsl-dspi', 'spi/topic/imx' and 'spi/topic/lantiq' into spi-next

2017-04-26T14:58:04+00:00

spi: Add can_dma like interface for spi_flash_read

2017-04-21T17:03:53+00:00

Add an interface analogous to ->can_dma() for spi_flash_read() interface. This will enable SPI controller drivers to inform SPI core when not to do DMA mappings. Signed-off-by: Vignesh R Signed-off-by: Mark Brown

spi: dynamycally allocated message initialization

2017-03-29T10:40:39+00:00

Invoke the proper function while initializing a dynamically allocated spi_message to avoid NULL pointer dereference during resources deallocation. Signed-off-by: Emiliano Ingrassia Signed-off-by: Mark Brown

spi: allow attaching device properties to SPI board info

2017-03-06T10:38:03+00:00

Generic device properties support statically defined property sets. For them to be usable, we need to attach these property sets before devices are registered and probed. Allowing to attach property list to spi_board_info structure will allow non-ACPI non-DT boards switch to using generic properties and get rid of custom platform data. Signed-off-by: Dmitry Torokhov Signed-off-by: Mark Brown