linux.git/include/linux/spi, branch master

spi: use generic driver_override infrastructure

2026-03-24T15:00:08+00:00

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

treewide: Replace kmalloc with kmalloc_obj for non-scalar types

2026-02-21T09:02:28+00:00

This is the result of running the Coccinelle script from
scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to
avoid scalar types (which need careful case-by-case checking), and
instead replace kmalloc-family calls that allocate struct or union
object instances:

Single allocations:	kmalloc(sizeof(TYPE), ...)
are replaced with:	kmalloc_obj(TYPE, ...)

Array allocations:	kmalloc_array(COUNT, sizeof(TYPE), ...)
are replaced with:	kmalloc_objs(TYPE, COUNT, ...)

Flex array allocations:	kmalloc(struct_size(PTR, FAM, COUNT), ...)
are replaced with:	kmalloc_flex(*PTR, FAM, COUNT, ...)

(where TYPE may also be *VAR)

The resulting allocations no longer return "void *", instead returning
"TYPE *".

Signed-off-by: Kees Cook

Merge tag 'mtd/for-7.0' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux

2026-02-13T23:06:58+00:00

Pull MTD updates from Miquel Raynal:
 "MTD:

   - prioritize ofpart in physmap-core probing

   - conversions to scoped for each OF child loops

  Bindings:

   - The bulk of the changes consists of binding fixes/updates to
     restrict the use of undefined properties, which was mostly
     ineffective in the current form because of the nesting of partition
     nodes and the lack of compatible strings

   - YAML conversions and the addition of a dma-coherent property in the
     cdns,hp-nfc driver

  SPI NAND:

   - support for octal DTR modes (8D-8D-8D)

   - support for Foresee F35SQB002G chips

  And small misc fixes"

* tag 'mtd/for-7.0' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux: (65 commits)
  mtd: spi-nor: hisi-sfc: fix refcounting bug in hisi_spi_nor_register_all()
  mtd: spinand: fix NULL pointer dereference in spinand_support_vendor_ops()
  mtd: rawnand: pl353: Add message about ECC mode
  mtd: rawnand: pl353: Fix software ECC support
  mtd: spinand: winbond: Remove unneeded semicolon
  dt-bindings: mtd: cdns,hp-nfc: Add dma-coherent property
  mtd: spinand: Disable continuous read during probe
  mtd: spinand: add Foresee F35SQB002G flash support
  mtd: spinand: winbond: W35N octal DTR support
  mtd: spinand: Add octal DTR support
  mtd: spinand: Warn if using SSDR-only vendor commands in a non SSDR mode
  mtd: spinand: Give the bus interface to the configuration helper
  mtd: spinand: Propagate the bus interface across core helpers
  mtd: spinand: Add support for setting a bus interface
  mtd: spinand: Gather all the bus interface steps in one single function
  mtd: spinand: winbond: Configure the IO mode after the dummy cycles
  mtd: spinand: winbond: Rename IO_MODE register macro
  mtd: spinand: winbond: Fix style
  mtd: spinand: winbond: Register W35N vendor specific operation
  mtd: spinand: winbond: Register W25N vendor specific operation
  ...

Merge tag 'sound-7.0-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound

2026-02-11T19:43:00+00:00

Pull sound updates from Takashi Iwai:
 "It's been relatively calm for a new era; majority of changes are for
  ASoC, mostly device-specific changes, while there are a bit of
  cleanups in core stuff. A few SPI API and regmap updates are included
  to be used by sound drivers, too.

  Core:
   - A few trivial cleanups about __free() and runtime PM macros
   - Convert to new snd_seq_bus binding

  ASoC:
   - Generic SDCA support for reporting jack events
   - Continuing platform support, cleanup and feature improvements for
     AMD, Intel, Qualcomm and SOF code
   - Platform description improvements for the Cirrus drivers
   - Support for NXP i.MX952, Realtek RT1320 and RT5575, and Sophogo
     CV1800B

  HD- and USB-audio:
   - Many quirks as usual"

* tag 'sound-7.0-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (341 commits)
  ALSA: usb-audio: Add DSD support for iBasso DC04U
  ALSA: mixer: oss: Add card disconnect checkpoints
  ASoC: SOF: ipc4-control: Set correct error code in refresh_bytes_control
  ASoC: SOF: Intel: select CONFIG_SND_HDA_EXT_CORE from SND_SOC_SOF_HDA_COMMON
  ALSA: usb-audio: Add iface reset and delay quirk for AB13X USB Audio
  ASoC: amd: maintainer information
  ALSA: ctxfi: Add quirk for SE-300PCIE variant (160b:0102)
  ALSA: hda/generic: fix typos in comments
  ALSA: hda/realtek - Enable mute LEDs on HP ENVY x360 15-es0xxx
  ALSA: hda/conexant: Add quirk for HP ZBook Studio G4
  ASoC: fsl_asrc_dma: allocate memory from dma device
  ASoC: fsl_asrc: Add support for i.MX952 platform
  ASoC: fsl_asrc_m2m: Add option to start ASRC before DMA device for M2M
  ASoC: dt-bindings: fsl,imx-asrc: Add support for i.MX952 platform
  ALSA: oss: delete self assignment
  ASoC: rockchip: spdif: Convert to FIELD_PREP
  ASoC: rockchip: spdif: Fill IEC958 CS info per params
  ASoC: rockchip: spdif: Add support for format S32_LE
  ASoC: rockchip: spdif: Add support for set mclk rate
  ASoC: rockchip: spdif: Swap PCM and DAI component registration order
  ...

spi: add multi-lane support

2026-02-02T22:03:20+00:00

Merge series from David Lechner :

This series is adding support for SPI controllers and peripherals that
have multiple SPI data lanes (data lanes being independent sets of
SDI/SDO lines, each with their own serializer/deserializer).

This series covers this specific use case:

+--------------+    +---------+
| SPI          |    | SPI     |
| Controller   |    | ADC     |
|              |    |         |
|          CS0 |--->| CS      |
|         SCLK |--->| SCLK    |
|          SDO |--->| SDI     |
|         SDI0 |<---| SDOA    |
|         SDI1 |<---| SDOB    |
|         SDI2 |<---| SDOC    |
|         SDI3 |<---| SDOD    |
+--------------+     +--------+

The ADC is a simultaneous sampling ADC that can convert 4 samples at the
same time. It has 4 data output lines (SDOA-D) that each contain the
data of one of the 4 channels. So it requires a SPI controller with 4
separate deserializers in order to receive all of the information at the
same time.

This should also work for the use case in [1] as well. (Some of the
patches in this series were already submitted there). In that case the
SPI controller is used kind of like it is two separate SPI controllers,
each with its own chip select, clock, and data lines.

[1]: https://lore.kernel.org/linux-spi/20250616220054.3968946-1-sean.anderson@linux.dev/

The DT bindings are a fairly straight-forward mapping of which pins on
the peripheral are connected to which pins on the controller. The SPI
core code parses this and makes the information available to drivers.
When a peripheral driver sees that multiple data lanes are wired up, it
can chose to use them when sending messages.

The SPI message API is a bit higher-level than just specifying the
number of data lines for a SPI transfer though. I did some research on
other SPI controllers that have this feature. They tend to be the kind
meant for connecting to two flash memory chips at the same time but can
be used more generically as well. They generally have the option to
either use one lane at a time (Sean's use case), or can mirror the same
data on multiple lanes (no users of this yet) or can perform striping
of a single data FIFO/DMA stream to/from the two lanes (our use case).

For now, the API assumes that if you want to do mirror/striping, then
you want to use all available data lanes. Otherwise, it just uses the
first data lane for "normal" SPI transfers.

spi: add multi_lane_mode field to struct spi_transfer

2026-02-02T12:12:44+00:00

Add a new multi_lane_mode field to struct spi_transfer to allow
peripherals that support multiple SPI lanes to be used with a single
SPI controller.

This requires both the peripheral and the controller to have multiple
serializers connected to separate data lanes. It could also be used with
a single controller and multiple peripherals that are functioning as a
single logical device (similar to parallel memories).

Acked-by: Nuno Sá 
Acked-by: Marcelo Schmitt 
Reviewed-by: Jonathan Cameron 
Signed-off-by: David Lechner 
Link: https://patch.msgid.link/20260123-spi-add-multi-bus-support-v6-4-12af183c06eb@baylibre.com
Signed-off-by: Mark Brown

spi: support controllers with multiple data lanes

2026-02-02T12:12:43+00:00

Add support for SPI controllers with multiple physical SPI data lanes.
(A data lane in this context means lines connected to a serializer, so a
controller with two data lanes would have two serializers in a single
controller).

This is common in the type of controller that can be used with parallel
flash memories, but can be used for general purpose SPI as well.

To indicate support, a controller just needs to set ctlr->num_data_lanes
to something greater than 1. Peripherals indicate which lane they are
connected to via device tree (ACPI support can be added if needed).

The spi-{tx,rx}-bus-width DT properties can now be arrays. The length of
the array indicates the number of data lanes, and each element indicates
the bus width of that lane. For now, we restrict all lanes to have the
same bus width to keep things simple. Support for an optional controller
lane mapping property is also implemented.

Signed-off-by: David Lechner 
Link: https://patch.msgid.link/20260123-spi-add-multi-bus-support-v6-3-12af183c06eb@baylibre.com
Signed-off-by: Mark Brown

spi: spi-mem: Create a repeated address operation

2026-01-29T19:21:38+00:00

In octal DTR mode addresses may either be long enough to cover at least
two bytes (in which case the existing macro works), or otherwise for
single byte addresses, the byte must also be duplicated and sent twice:
on each front of the clock.

Create a macro for this common case.

Signed-off-by: Miquel Raynal

spi: spi-mem: Create a repeated address operation

2026-01-12T12:40:29+00:00

In octal DTR mode addresses may either be long enough to cover at least
two bytes (in which case the existing macro works), or otherwise for
single byte addresses, the byte must also be duplicated and sent twice:
on each front of the clock.

Create a macro for this common case.

Signed-off-by: Miquel Raynal 
Link: https://patch.msgid.link/20260109-winbond-v6-17-rc1-oddr-v2-2-1fff6a2ddb80@bootlin.com
Signed-off-by: Mark Brown

spi: spi-mem: Make the DTR command operation macro more suitable

2026-01-12T12:40:29+00:00

In order to introduce DTR support in SPI NAND, a number of macros had to
be created in the spi-mem layer. One of them remained unused at this
point, SPI_MEM_DTR_OP_CMD. Being in the process of introducing octal DTR
support now, experience shows that as-is the macro is not useful. In
order to be really useful in octal DTR mode, the command opcode (one
byte) must always be transmitted on the 8 data lines on both the rising
and falling edge of the clock. Align the macro with the real needs by
duplicating the opcode in the buffer and doubling its size.

Reviewed-by: Tudor Ambarus 
Signed-off-by: Miquel Raynal 
Link: https://patch.msgid.link/20260109-winbond-v6-17-rc1-oddr-v2-1-1fff6a2ddb80@bootlin.com
Signed-off-by: Mark Brown