kernel/linux.git/include/linux/spi/spi.h, branch v6.19.11

spi: use generic driver_override infrastructure

2026-04-02T11:25:36+00:00

[ Upstream commit cc34d77dd48708d810c12bfd6f5bf03304f6c824 ] When a driver is probed through __driver_attach(), the bus' match() callback is called without the device lock held, thus accessing the driver_override field without a lock, which can cause a UAF. Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally. Note that calling match() from __driver_attach() without the device lock held is intentional. [1] Also note that we do not enable the driver_override feature of struct bus_type, as SPI - in contrast to most other buses - passes "" to sysfs_emit() when the driver_override pointer is NULL. Thus, printing "\n" instead of "(null)\n". Link: https://lore.kernel.org/driver-core/DGRGTIRHA62X.3RY09D9SOK77P@kernel.org/ [1] Reported-by: Gui-Dong Han Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220789 Fixes: 5039563e7c25 ("spi: Add driver_override SPI device attribute") Signed-off-by: Danilo Krummrich Link: https://patch.msgid.link/20260324005919.2408620-12-dakr@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

spi: rename SPI_CS_CNT_MAX => SPI_DEVICE_CS_CNT_MAX

2025-09-22T08:29:45+00:00

Rename SPI_CS_CNT_MAX to SPI_DEVICE_CS_CNT_MAX to make it more obvious that this is the max number of CS per device supported, not per controller. Signed-off-by: Jonas Gorski Link: https://patch.msgid.link/20250915183725.219473-8-jonas.gorski@gmail.com Signed-off-by: Mark Brown

spi: reduce device chip select limit again

2025-09-22T08:29:44+00:00

The spi chipselect limit SPI_CS_CNT_MAX was raised with commit 2f8c7c3715f2 ("spi: Raise limit on number of chip selects") from 4 to 16 to accommodate spi controllers with more than 4 chip selects, and then later to 24 with commit 96893cdd4760 ("spi: Raise limit on number of chip selects to 24"). Now that we removed SPI_CS_CNT_MAX limiting the chip selects of controllers, we can reduce the amount of chip selects per device again to 4, the original value. Signed-off-by: Jonas Gorski Link: https://patch.msgid.link/20250915183725.219473-7-jonas.gorski@gmail.com Signed-off-by: Mark Brown

spi: keep track of number of chipselects in spi_device

2025-09-22T08:29:41+00:00

There are several places where we need to iterate over a device's chipselect. To be able to do it efficiently, store the number of chipselects in spi_device, like we do for controllers. Since we now use a device supplied value, add a check to make sure it isn't more than we can support. Signed-off-by: Jonas Gorski Link: https://patch.msgid.link/20250915183725.219473-3-jonas.gorski@gmail.com Signed-off-by: Mark Brown

spi: Raise limit on number of chip selects to 24

2025-06-29T21:10:52+00:00

We have a system which uses 24 SPI chip selects, raise the hard coded limit accordingly. Signed-off-by: Marc Kleine-Budde Link: https://patch.msgid.link/20250629-spi-increase-number-of-cs-v2-1-85a0a09bab32@pengutronix.de Signed-off-by: Mark Brown

Merge tag 'spi-v6.16' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi

2025-05-27T22:53:55+00:00

Pull spi updates from Mark Brown: "The bulk of the changes in this release are driver work, as well as new device support we have some important work on performance over several drivers, and big overhauls for maintainability on a couple too. Highlights include: - Big cleanups of the sh-msiof driver from Geert Uytterhoeven, and of the NXP FSPI driver from Haibo Chen - Performance improvements for the AXI SPI engine - Support for writes to memory mapped flashes on Renesas devices - Integrated DMA support for Tegra210 QSPI, used by the Tegra234 - DMA support for Amlogic SPI controllers - Support for AMD HID2, Qualcomm IPQ5018, Renesas RZ/G3E, Rockchip RK3528 and Samsung Exynos Autov920 An update to fix some issues with the Atmel QSPI driver runtime PM pulled in a new API from the PM core, and the Renesas memory mapped write changes pull in some code that's shared in drivers/memory" * tag 'spi-v6.16' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: (90 commits) spi: spi-qpic-snand: return early on error from qcom_spi_io_op() spi: loopback-test: fix up const pointer issue in rx_ranges_cmp() spi: gpio: fix const issue in spi_to_spi_gpio() spi: spi-qpic-snand: remove superfluous parameters of qcom_spi_check_error() dt-bindings: spi: samsung: add exynosautov920-spi compatible spi: spi-qpic-snand: reuse qcom_spi_check_raw_flash_errors() spi: dt-bindings: Add rk3528-spi compatible spi: spi_amd: Update Kconfig dependencies spi: spi_amd: Add HIDDMA basic write support spi: spi_amd: Remove read{q,b} usage on DMA buffer spi: sh-msiof: Move register definitions to spi: sh-msiof: Document frame start sync pulse mode spi: sh-msiof: Double maximum DMA transfer size using two groups spi: sh-msiof: Simplify BRG's Division Ratio spi: sh-msiof: Increase TX FIFO size for R-Car V4H/V4M spi: sh-msiof: Correct RX FIFO size for R-Car Gen3 spi: sh-msiof: Correct RX FIFO size for R-Car Gen2 spi: sh-msiof: Add core support for dual-group transfers spi: sh-msiof: Correct SIMDR2_GRPMASK spi: sh-msiof: SIFCTR bitfield conversion ...

spi: use container_of_cont() for to_spi_device()

2025-05-22T11:03:28+00:00

Some places in the spi core pass in a const pointer to a device and the default container_of() casts that away, which is not a good idea. Preserve the proper const attribute by using container_of_const() for to_spi_device() instead, which is what it was designed for. Note, this removes the NULL check for a device pointer in the call, but no one was ever checking for that return value, and a device pointer should never be NULL overall anyway, so this should be a safe change. Cc: Mark Brown Fixes: d69d80484598 ("driver core: have match() callback in struct bus_type take a const *") Signed-off-by: Greg Kroah-Hartman Link: https://patch.msgid.link/2025052230-fidgeting-stooge-66f5@gregkh Signed-off-by: Mark Brown

spi: Introduce and use spi_bpw_to_bytes()

2025-04-18T04:11:47+00:00

Merge series from Andy Shevchenko : Recently in the discussion with David the idea of having a common helper popped up. The helper converts the given bits per word to bytes. The result will always be power-of-two (e.g. for 37 bits it returns 8 bytes) or 0 for 0 input. More details are in the respective code comment. This mini-series introduces it and replaces current users under drivers/spi and we expect more (and possibly some lurking in other subsystems).

spi: Add spi_bpw_to_bytes() helper and use it

2025-04-17T16:30:40+00:00

This helper converts the given bits per word to bytes. The result will always be power-of-two, e.g., =============== ================= Input (in bits) Output (in bytes) =============== ================= 5 1 9 2 21 4 37 8 =============== ================= It will return 0 for the 0 input. There are a couple of cases in SPI that are using the same approach and at least one more (in IIO) would benefit of it. Add a helper for everyone. Signed-off-by: Andy Shevchenko Reviewed-by: David Lechner Link: https://patch.msgid.link/20250417152529.490582-2-andriy.shevchenko@linux.intel.com Acked-by: Mukesh Kumar Savaliya Signed-off-by: Mark Brown

spi: Add support for Double Transfer Rate (DTR) mode

2025-04-13T19:27:01+00:00

Introduce support for protocol drivers to specify whether a transfer should use single or dual transfer mode. Currently, the SPI controller cannot determine this information from the user, leading to potential limitations in transfer capabilities. Add a new field `dtr_mode` in the `spi_transfer` structure. The `dtr_mode` field allows protocol drivers to indicate if Double Transfer Rate (DTR) mode is supported for a given transfer. When `dtr_mode` is set to true, the SPI controller will use DTR mode; otherwise, it will default to single transfer mode. Introduce another field `dtr_caps` to indicate if the QSPI controller is capable of supporting DTR mode (SDR and DDR). By default, both `dtr_caps` and `dtr_mode` will be false. These flags manage the QSPI controller's DTR mode capabilities within the SPI framework. The QSPI controller driver uses these flags to configure single or double transfer rates using the controller register. The existing spi-mem driver helps configure the DTR mode but is limited to memory devices. There is no support available to set DTR mode for non-memory devices, e.g., touch or any generic SPI sensor. This change is backward compatible and doesn't break existing SPI or QSPI drivers. Changes include: - Addition of `dtr_mode` and `dtr_caps` fields in the `spi_transfer` structure. - Documentation updates to reflect the new `dtr_mode` and `dtr_caps` fields. Signed-off-by: Mukesh Kumar Savaliya Link: https://patch.msgid.link/20250404135427.313825-1-quic_msavaliy@quicinc.com Signed-off-by: Mark Brown