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 <kees@kernel.org>
The ofpart parsing in physmap-core has been prioritized.
There has been a series of conversion to scoped for each OF child
loops.
* Bindings
The bulk of the changes consists in binding fixes/updates to restrict
the use of undefined properties, which was almost inefficient in the
current form because of the nesting of partition nodes and the lack of
compatible strings sometimes.
These changes are accompanied by YAML conversions and the addition of a
dma-coherent property in the cdns,hp-nfc driver.
* SPI NAND
The major feature this release is the support for octal DTR
modes (8D-8D-8D).
Support for Foresee F35SQB002G chips has been added.
Other changes are small misc fixes.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEE9HuaYnbmDhq/XIDIJWrqGEe9VoQFAmmPXI4ACgkQJWrqGEe9
VoQKJgf/YgI8L684Hq8OejCZYCoChZpTTvMmqmZ0CgRaZ157jcYTY5Od46pUpfEs
uSuoXW6+cuxdGeeUtyb3u5uJduO8r7UMjYLBqtMRGjvtfN9EDdhqVQWnRfCr9PoR
MS4moQa14tEakeP/u6stsmGLpzPkgiygcdTCWS4LhNoJ0LgkLjfBusQm6P5uqc+a
m/XS4Mg8SPj7pGjinu5KsvKWKiez6k4ExXiLM9p0TX/8iacFhGBrzKqv6zMiNyfL
p5ZS3ZLv9d79sLKOPlycfNO9LOp6O6ufn+zmuHQpTHGdlPegiNCoF1fOB9XZxc4A
iK9Z7b3ko9ta0HdjzRYkG/eFtTL0dQ==
=hnfP
-----END PGP SIGNATURE-----
Merge tag 'mtd/for-7.0' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux
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
...
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
-----BEGIN PGP SIGNATURE-----
iQJCBAABCAAsFiEEIXTw5fNLNI7mMiVaLtJE4w1nLE8FAmmLT6wOHHRpd2FpQHN1
c2UuZGUACgkQLtJE4w1nLE8pNA/+OW1DA4II37keAClezQ6Z5O88MPO0ETx6DFgO
yT1fWWiqaSzETdxMHVkviiagoeeE96wN8mM/B2Vvljd+KL0L+z+dEATZgct1w2xQ
toWB78eOvFlVv51oYxrHhVCWHpFtC5SEi7Ize8FmR/NaaRd2aBNlAz9n88fvR3Bg
ApfGFsufEYqDPCfQG002r4skcKaqrOMabhd/RSwp4MrTZkG/O2h95BUHuF2EEUHr
j0MayB0n77Dav6PxfgayNcxjAEPi9tu8T9mP3HO3Z8AtGyaTLZPPf4Y3MBybTmIU
7CBiDQJy9a6vd7qhfMtr0tNwVNXZOOjRkzDl0HRDqKkw08ftybKTZBmP/dFmCNAp
f/0os6ue4Sl/lh1KXAW8wqyN8i/0Y5SCNvb1FOuGQwg8CWAqC+7jfIyFrQVgGsTj
fOsvpH3DmU0dGxVwJYiIBXCVNS8/TGF5vw9URyh0vm3LXH7AHn9e+IB7QlYvAOFR
Vis81OTO3QbjQn5Ig4+7vDkj6ywjLApX5kx6GiVMUisKJ54YX8RHC0HBZcOeyavy
Qfe/VMHcFmWKNLhRRUaKdsZwZMuig/RTrJfCp2eLGnEVHyPM+/5ECjRSzCcL5I4t
+jFJkhjEryqWtWk1Vmxz4gCyqoGsdSGSsuVVdYlS7MmMkAb6kpl2EztvpXR3FH60
TNqVYLY=
=kfLN
-----END PGP SIGNATURE-----
Merge tag 'sound-7.0-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
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
...
Merge series from David Lechner <dlechner@baylibre.com>:
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.
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á <nuno.sa@analog.com>
Acked-by: Marcelo Schmitt <marcelo.schmitt@analog.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Signed-off-by: David Lechner <dlechner@baylibre.com>
Link: https://patch.msgid.link/20260123-spi-add-multi-bus-support-v6-4-12af183c06eb@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
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 <dlechner@baylibre.com>
Link: https://patch.msgid.link/20260123-spi-add-multi-bus-support-v6-3-12af183c06eb@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
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 <miquel.raynal@bootlin.com>
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 <miquel.raynal@bootlin.com>
Link: https://patch.msgid.link/20260109-winbond-v6-17-rc1-oddr-v2-2-1fff6a2ddb80@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
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 <tudor.ambarus@linaro.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://patch.msgid.link/20260109-winbond-v6-17-rc1-oddr-v2-1-1fff6a2ddb80@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently, the helper of_find_spi_controller_by_node() is gated under
CONFIG_OF_DYNAMIC. This prevents drivers from using it in all CONFIG_OF
configurations.
This patch moves the gating to CONFIG_OF, keeping the inline fallback
returning NULL when Device Tree support is disabled.
Signed-off-by: Oder Chiou <oder_chiou@realtek.com>
Link: https://patch.msgid.link/6d8ae977d9f4726ea23ad5382638750593f9a2e4.1767148150.git.oder_chiou@realtek.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Some devices are primarily described on another bus (e.g. I2C) but also
have an additional SPI connection that serves as a transport for
firmware loading. Export of_find_spi_controller_by_node() so drivers can
obtain the SPI controller referenced by a DT phandle.
Signed-off-by: Oder Chiou <oder_chiou@realtek.com>
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/0e572a00aa305e588357162d400ba9472ce56dd3.1767148150.git.oder_chiou@realtek.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add an offset parameter that can be passed in the periodic trigger.
This is useful for example when ADC drivers implement a separate periodic
signal to trigger conversion and need offload to read the result with
some delay. While at it, add some documentation to offload periodic trigger
parameters.
Reviewed-by: David Lechner <dlechner@baylibre.com>
Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
Signed-off-by: Marcelo Schmitt <marcelo.schmitt@analog.com>
Link: https://patch.msgid.link/cd315e95c0bd8523f00e91c400abcd6a418e5924.1759760519.git.marcelo.schmitt@analog.com
Signed-off-by: Mark Brown <broonie@kernel.org>
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 <jonas.gorski@gmail.com>
Link: https://patch.msgid.link/20250915183725.219473-8-jonas.gorski@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The spi chipselect limit SPI_CS_CNT_MAX was raised with commit
2f8c7c3715 ("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 96893cdd47 ("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 <jonas.gorski@gmail.com>
Link: https://patch.msgid.link/20250915183725.219473-7-jonas.gorski@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
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 <jonas.gorski@gmail.com>
Link: https://patch.msgid.link/20250915183725.219473-3-jonas.gorski@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Apart from a binding conversion to yaml, only minor changes/small fixes
have been merged.
* Raw NAND changes:
Various controller drivers received minor fixes like DMA mapping checks,
better timing derivations or bitflip statistics.
It has also been discovered that some Hynix NAND flashes were not
supporting read-retries, which is not properly supported.
* SPI NAND changes:
In order to support high-speed modes, certain chips need extra
configuration like adding more dummy cycles. This is now possible,
especially on Winbond chips.
Aside from that, Gigadevice gets support for a new chip (GD5F1GM9).
* SPI NOR changes:
A notable changes is the fix for exiting 4-byte addressing on Infineon
SEMPER flashes. These flashes do not support the standard EX4B
opcode (E9h), and use a vendor-specific opcode (B8h) instead.
There is also a fix for unlocking flashes that are write-protected at
power-on. This was caused by using an uninitialized mtd_info in
spi_nor_try_unlock_all().
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEE9HuaYnbmDhq/XIDIJWrqGEe9VoQFAmiLn/sACgkQJWrqGEe9
VoTGowf/c6kynDuMlQbTANv/UIYX/LRFZsnIx0LB32LWrhLaUIBsbFxejyt07WG9
ryej+xRUtSHGsqMIw+B/PjvA4hUNLdsSwO/udIwstXNQjJcO9OKp/ucpvlxLzIha
REq8IifvT9vLLA+Efoq2L25dM14KjuFCAjwm3GH/SmdTOqPhI/Bbnx4vRWIPeXrx
XZ69ovIiu5NqLTD5IFGsu+omhbFWlDtVALtKNknrTOXWrjLZhDpieO4f7M9rvru6
OwazFQAWuixzqZRMFqvOzu8KUDnOHi9gHrzi6tS7T1zBUDz9ywdBtaHYCd7VlMJh
uV1wjUdWjnIh9E8R/llv3D+ko1Ya1w==
=IS/d
-----END PGP SIGNATURE-----
Merge tag 'mtd/for-6.17' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux
Pull mtd updates from Miquel Raynal:
"MTD changes:
- Apart from a binding conversion to yaml, only minor changes/small
fixes have been merged.
Raw NAND changes:
- Minor fixes for various controller drivers like DMA mapping checks,
better timing derivations or bitflip statistics.
- some Hynix NAND flashes were not supporting read-retries, so don't
even try to do it
SPI NAND changes:
- In order to support high-speed modes, certain chips need extra
configuration like adding more dummy cycles. This is now possible,
especially on Winbond chips.
- Aside from that, Gigadevice gets support for a new chip (GD5F1GM9).
SPI NOR changes:
- A notable changes is the fix for exiting 4-byte addressing on
Infineon SEMPER flashes. These flashes do not support the standard
EX4B opcode (E9h), and use a vendor-specific opcode (B8h) instead.
- There is also a fix for unlocking flashes that are write-protected
at power-on. This was caused by using an uninitialized mtd_info in
spi_nor_try_unlock_all()"
* tag 'mtd/for-6.17' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux: (26 commits)
mtd: spinand: winbond: Add comment about the maximum frequency
mtd: spinand: winbond: Enable high-speed modes on w35n0xjw
mtd: spinand: winbond: Enable high-speed modes on w25n0xjw
mtd: spinand: Add a ->configure_chip() hook
mtd: spinand: Add a frequency field to all READ_FROM_CACHE variants
mtd: spinand: Fix macro alignment
spi: spi-mem: Take into account the actual maximum frequency
spi: spi-mem: Use picoseconds for calculating the op durations
mtd: rawnand: atmel: set pmecc data setup time
mtd: spinand: propagate spinand_wait() errors from spinand_write_page()
mtd: rawnand: fsmc: Add missing check after DMA map
mtd: rawnand: rockchip: Add missing check after DMA map
mtd: rawnand: hynix: don't try read-retry on SLC NANDs
mtd: rawnand: atmel: Fix dma_mapping_error() address
mtd: nand: brcmnand: fix mtd corrected bits stat
mtd: rawnand: renesas: Add missing check after DMA map
mtd: spinand: gigadevice: Add support for GD5F1GM9 chips
mtd: nand: brcmnand: replace manual string choices with standard helpers
mtd: map: Don't use "proxy" headers
mtd: spi-nor: Fix spi_nor_try_unlock_all()
...
In order to pick the best variant, the duration of each typical
operation is derived and then compared. These durations are based on the
maximum capabilities of the chips, which are commonly the limiting
factors. However there are other possible limiting pieces, such as the
hardware layout, EMC considerations and in some cases, the SPI controller
itself.
We need to take this into account to further refine our variant choice,
so let's use the actual frequency that will be used for the operation
instead of the theoretical maximum.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
This 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.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmgzCzkACgkQJNaLcl1U
h9DF5gf+MlaB2j6ggH/OnXdV6aQTcjta357+ptWH3CDQbx0nsMj50i+eqxhzOK69
tyOMX0gcqo8bBQq1mhm3Z2fDYbYYRKwf7OwymHD1KGNGn9zegORNw790/XGTeoMo
m5f9Trz9UNP+7NjWuOioKoy6zghp4Ti2WAAUPhGUQBnyaV269bonNvisRtqnDP5u
nOu1DYANZqL3icuUIdJ3Aklmn4On1svUPuE9HOn/GNocZZWegcCHfBjmSRuLUAGO
RR1jP/d+RfSvTSrdqZGwrfWLFBBirjSLXNB1g7sjiVTnSseuBnOZ/z7PuBQQ+NuB
ENyoQXNLFZKMTQ5wmuQpXnwIIXsxYg==
=FmJ2
-----END PGP SIGNATURE-----
Merge tag 'spi-v6.16' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi
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 <linux/spi/sh_msiof.h>
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
...
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 <broonie@kernel.org>
Fixes: d69d804845 ("driver core: have match() callback in struct bus_type take a const *")
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://patch.msgid.link/2025052230-fidgeting-stooge-66f5@gregkh
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Andy Shevchenko <andriy.shevchenko@linux.intel.com>:
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).
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 <andriy.shevchenko@linux.intel.com>
Reviewed-by: David Lechner <dlechner@baylibre.com>
Link: https://patch.msgid.link/20250417152529.490582-2-andriy.shevchenko@linux.intel.com
Acked-by: Mukesh Kumar Savaliya <quic_msavaliy@quicinc.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
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 <quic_msavaliy@quicinc.com>
Link: https://patch.msgid.link/20250404135427.313825-1-quic_msavaliy@quicinc.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Replace "master" by "[host] controller" in the SPI core code and comments.
All the similar to the "slave" by "target [device]" changes.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20250313140340.380359-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add #include <linux/bits.h> to linux/spi/offload/types.h since this
file uses the BIT macro.
Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: David Lechner <dlechner@baylibre.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20250210-spi-offload-extra-headers-v1-1-0f3356362254@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Most configuration of SPI offloads is handled opaquely using the offload
pointer that is passed to the various offload functions. However, there
are some offload features that need to be controlled on a per transfer
basis.
This patch adds a flag field to struct spi_transfer to allow specifying
such features. The first feature to be added is the ability to stream
data to/from a hardware sink/source rather than using a tx or rx buffer.
Additional flags can be added in the future as needed.
A flags field is also added to the offload struct for providers to
indicate which flags are supported. This allows for generic checking of
offload capabilities during __spi_validate() so that each offload
provider doesn't have to implement their own validation.
As a first users of this streaming capability, getter functions are
added to get a DMA channel that is directly connected to the offload.
Peripheral drivers will use this to get a DMA channel and configure it
to suit their needs.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Nuno Sa <nuno.sa@analog.com>
Signed-off-by: David Lechner <dlechner@baylibre.com>
Link: https://patch.msgid.link/20250207-dlech-mainline-spi-engine-offload-2-v8-5-e48a489be48c@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Extend SPI offloading to support hardware triggers.
This allows an arbitrary hardware trigger to be used to start a SPI
transfer that was previously set up with spi_optimize_message().
A new struct spi_offload_trigger is introduced that can be used to
configure any type of trigger. It has a type discriminator and a union
to allow it to be extended in the future. Two trigger types are defined
to start with. One is a trigger that indicates that the SPI peripheral
is ready to read or write data. The other is a periodic trigger to
repeat a SPI message at a fixed rate.
There is also a spi_offload_hw_trigger_validate() function that works
similar to clk_round_rate(). It basically asks the question of if we
enabled the hardware trigger what would the actual parameters be. This
can be used to test if the requested trigger type is actually supported
by the hardware and for periodic triggers, it can be used to find the
actual rate that the hardware is capable of.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Nuno Sa <nuno.sa@analog.com>
Signed-off-by: David Lechner <dlechner@baylibre.com>
Link: https://patch.msgid.link/20250207-dlech-mainline-spi-engine-offload-2-v8-2-e48a489be48c@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add the basic infrastructure to support SPI offload providers and
consumers.
SPI offloading is a feature that allows the SPI controller to perform
transfers without any CPU intervention. This is useful, e.g. for
high-speed data acquisition.
SPI controllers with offload support need to implement the get_offload
and put_offload callbacks and can use the devm_spi_offload_alloc() to
allocate offload instances.
SPI peripheral drivers will call devm_spi_offload_get() to get a
reference to the matching offload instance. This offload instance can
then be attached to a SPI message to request offloading that message.
It is expected that SPI controllers with offload support will check for
the offload instance in the SPI message in the ctlr->optimize_message()
callback and handle it accordingly.
CONFIG_SPI_OFFLOAD is intended to be a select-only option. Both
consumer and provider drivers should `select SPI_OFFLOAD` in their
Kconfig to ensure that the SPI core is built with offload support.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Nuno Sa <nuno.sa@analog.com>
Signed-off-by: David Lechner <dlechner@baylibre.com>
Link: https://patch.msgid.link/20250207-dlech-mainline-spi-engine-offload-2-v8-1-e48a489be48c@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
In the SPI-NAND layer, we currently make list of operation variants from
the fastest one to the slowest and there is a bit of logic in the core
to go over them and pick the first one that is supported by the
controller, ie. the fastest one among the supported ops.
This kind of logic only works if all operations run at the same
frequency, but as soon as we introduce per operation max frequencies it
is not longer as obvious which operation will be faster, especially
since it also depends on the PCB/controller frequency limitation.
One way to make this choice more clever is to go over all the
variants and for each of them derive an indicator which will help derive
the theoretical best. In this case, we derive a theoretical duration for
the entire operation and we take the smallest one.
Add a helper that parses the spi-mem operation and returns this value.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://patch.msgid.link/20250110-winbond-6-11-rc1-quad-support-v3-20-7ab4bd56cf6e@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
We do have macros for defining command, address, dummy and data
cycles. We also have a .dtr flag that implies sampling the bus on both
edges, but there are currently no macros enabling it. We might make use
of such macros, so let's create:
- SPI_MEM_DTR_OP_CMD
- SPI_MEM_DTR_OP_ADDR
- SPI_MEM_DTR_OP_DUMMY
- SPI_MEM_DTR_OP_DATA_OUT
- SPI_MEM_DTR_OP_DATA_OUT
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://patch.msgid.link/20241224-winbond-6-11-rc1-quad-support-v2-19-ad218dbc406f@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There are spi devices with multiple frequency limitations depending on
the invoked command. We probably do not want to afford running at the
lowest supported frequency all the time, so if we want to get the most
of our hardware, we need to allow per-operation frequency limitations.
Among all the SPI memory controllers, I believe all are capable of
changing the spi frequency on the fly. Some of the drivers do not make
any frequency setup though. And some others will derive a per chip
prescaler value which will be used forever.
Actually changing the frequency on the fly is something new in Linux, so
we need to carefully flag the drivers which do and do not support it. A
controller capability is created for that, and the presence for this
capability will always be checked before accepting such pattern.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Link: https://patch.msgid.link/20241224-winbond-6-11-rc1-quad-support-v2-2-ad218dbc406f@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
In the spi subsystem, the bus frequency is derived as follows:
- the controller may expose a minimum and maximum operating frequency
- the hardware description, through the spi peripheral properties,
advise what is the maximum acceptable frequency from a device/wiring
point of view.
Transfers must be observed at a frequency which fits both (so in
practice, the lowest maximum).
Actually, this second point mixes two information and already takes the
lowest frequency among:
- what the spi device is capable of (what is written in the component
datasheet)
- what the wiring allows (electromagnetic sensibility, crossovers,
terminations, antenna effect, etc).
This logic works until spi devices are no longer capable of sustaining
their highest frequency regardless of the operation. Spi memories are
typically subject to such variation. Some devices are capable of
spitting their internally stored data (essentially in read mode) at a
very fast rate, typically up to 166MHz on Winbond SPI-NAND chips, using
"fast" commands. However, some of the low-end operations, such as
regular page read-from-cache commands, are more limited and can only be
executed at 54MHz at most. This is currently a problem in the SPI-NAND
subsystem. Another situation, even if not yet supported, will be with
DTR commands, when the data is latched on both edges of the clock. The
same chips as mentioned previously are in this case limited to
80MHz. Yet another example might be continuous reads, which, under
certain circumstances, can also run at most at 104 or 120MHz.
As a matter of fact, the "one frequency per chip" policy is outdated and
more fine grain configuration is needed: we need to allow per-operation
frequency limitations. So far, all datasheets I encountered advertise a
maximum default frequency, which need to be lowered for certain specific
operations. So based on the current infrastructure, we can still expect
firmware (device trees in general) to continued advertising the same
maximum speed which is a mix between the PCB limitations and the chip
maximum capability, and expect per-operation lower frequencies when this
is relevant.
Add a `struct spi_mem_op` member to carry this information. Not
providing this field explicitly from upper layers means that there is no
further constraint and the default spi device maximum speed will be
carried instead. The SPI_MEM_OP() macro is also expanded with an
optional frequency argument, because virtually all operations can be
subject to such a limitation, and this will allow for a smooth and
discrete transition.
For controller drivers which do not implement the spi-mem interface, the
per-transfer speed is also set acordingly to a lower (than the maximum
default) speed when relevant.
Acked-by: Pratyush Yadav <pratyush@kernel.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://patch.msgid.link/20241224-winbond-6-11-rc1-quad-support-v2-1-ad218dbc406f@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
misc issues got fixed.
SPI-NAND changes:
A load of fixes to Winbond manufacturer driver have been done, plus a
structure constification.
Raw NAND changes:
The GPMI driver has been improved on the power management side.
The Davinci driver has been cleaned up.
A leak in the Atmel driver plus some typos in the core have been fixed.
SPI NOR changes:
Introduce byte swap support for 8D-8D-8D mode and a user for it:
macronix. SPI NOR flashes may swap the bytes on a 16-bit boundary when
configured in Octal DTR mode. For such cases the byte order is
propagated through SPI MEM to the SPI controllers so that the
controllers swap the bytes back at runtime. This avoids breaking the
boot sequence because of the endianness problems that appear when the
bootloaders use 1-1-1 and the kernel uses 8D-8D-8D with byte swap
support. Along with the SPI MEM byte swap support we queue a patch for
the SPI MXIC controller that swaps the bytes back at runtime.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEE9HuaYnbmDhq/XIDIJWrqGEe9VoQFAmc/WusACgkQJWrqGEe9
VoR0Zgf/admMDFN51dtkz950bnOkZfot/4uLgUQCDenhbugHrom7KWQ6+oh1+HSN
9EAjLoLNQzq4vxKx1WoI/99iJO86zg/DiyVD3nQidv9JkqHRDp2t13ZLclr4gGyW
Kh1lDQ+9GwpB8CQQnxVaPL39NjjqR3RiEfEP/1fVgGYQvCt4yedhVsDT3WThJeVb
1n7l54RBpZji88mT0chFB9CoSLnzrYZFh2MvzJaW/i1v02yZLXHFxFiKiKo+WysY
FGQTY3x0j20H2Ib8RSP7ECegvNb1HtfIxAPsTIqDBGbrA+ahvBr0J/XxX3NbV3RT
Ee4rXqL257zH9dC9Rr1LJAZCqiyx7w==
=p+y9
-----END PGP SIGNATURE-----
Merge tag 'mtd/for-6.13' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux
Pull MTD updates from Miquel Raynal:
"MTD device changes:
- switch platform_driver back to remove()
- misc fixes
SPI-NAND changes:
- a load of fixes to Winbond manufacturer driver
- structure constification
Raw NAND changes:
- improve the power management of the GPMI driver
- Davinci driver clean-ups
- fix leak in the Atmel driver
- fix some typos in the core
SPI NOR changes:
- Introduce byte swap support for 8D-8D-8D mode and a user for it:
macronix.
SPI NOR flashes may swap the bytes on a 16-bit boundary when
configured in Octal DTR mode. For such cases the byte order is
propagated through SPI MEM to the SPI controllers so that the
controllers swap the bytes back at runtime. This avoids breaking
the boot sequence because of the endianness problems that appear
when the bootloaders use 1-1-1 and the kernel uses 8D-8D-8D with
byte swap support. Along with the SPI MEM byte swap support we
queue a patch for the SPI MXIC controller that swaps the bytes back
at runtime"
* tag 'mtd/for-6.13' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux: (25 commits)
mtd: spi-nor: core: replace dummy buswidth from addr to data
mtd: spi-nor: winbond: add "w/ and w/o SFDP" comment
mtd: spi-nor: spansion: Use nor->addr_nbytes in octal DTR mode in RD_ANY_REG_OP
mtd: Switch back to struct platform_driver::remove()
mtd: cfi_cmdset_0002: remove redundant assignment to variable ret
mtd: spinand: Constify struct nand_ecc_engine_ops
MAINTAINERS: add mailing list for GPMI NAND driver
mtd: spinand: winbond: Sort the devices
mtd: spinand: winbond: Ignore the last ID characters
mtd: spinand: winbond: Fix 512GW, 01GW, 01JW and 02JW ECC information
mtd: spinand: winbond: Fix 512GW and 02JW OOB layout
mtd: nand: raw: gpmi: improve power management handling
mtd: nand: raw: gpmi: switch to SYSTEM_SLEEP_PM_OPS
mtd: rawnand: davinci: use generic device property helpers
mtd: rawnand: davinci: break the line correctly
mtd: rawnand: davinci: order headers alphabetically
mtd: rawnand: atmel: Fix possible memory leak
mtd: rawnand: Correct multiple typos in comments
mtd: hyperbus: rpc-if: Add missing MODULE_DEVICE_TABLE
mtd: spi-nor: add support for Macronix Octal flash
...
There are NOR flashes (Macronix) that swap the bytes on a 16-bit
boundary when configured in Octal DTR mode. The byte order of
16-bit words is swapped when read or written in Octal Double
Transfer Rate (DTR) mode compared to Single Transfer Rate (STR)
modes. If one writes D0 D1 D2 D3 bytes using 1-1-1 mode, and uses
8D-8D-8D SPI mode for reading, it will read back D1 D0 D3 D2.
Swapping the bytes may introduce some endianness problems. It can
affect the boot sequence if the entire boot sequence is not handled
in either 8D-8D-8D mode or 1-1-1 mode. Therefore, it is necessary
to swap the bytes back to ensure the same byte order as in STR modes.
Fortunately there are controllers that could swap the bytes back at
runtime, addressing the flash's endianness requirements. Provide a
way for the upper layers to specify the byte order in Octal DTR mode.
Merge Tudor's patch and add modifications for suiting newer version
of Linux kernel.
Suggested-by: Michael Walle <mwalle@kernel.org>
Signed-off-by: JaimeLiao <jaimeliao@mxic.com.tw>
Signed-off-by: AlvinZhou <alvinzhou@mxic.com.tw>
Acked-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20240926141956.2386374-3-alvinzhou.tw@gmail.com
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
All the {devm_}spi_alloc_master/slave() have been replaced,
so they can be removed and replaced in doc and comment.
No functional changed.
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://patch.msgid.link/20240902125947.1368-8-yangyingliang@huaweicloud.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Richard Fitzgerald <rf@opensource.cirrus.com>:
Provide empty versions of acpi_spi_count_resources(),
acpi_spi_device_alloc() and acpi_spi_find_controller_by_adev()
if the real functions are not being built.
This commit fixes two problems with the original definitions:
1) There wasn't an empty version of these functions
2) The #if only depended on CONFIG_ACPI. But the functions are implemented
in the core spi.c so CONFIG_SPI_MASTER must also be enabled for the real
functions to exist.
Provide empty versions of acpi_spi_count_resources(),
acpi_spi_device_alloc() and acpi_spi_find_controller_by_adev()
if the real functions are not being built.
This commit fixes two problems with the original definitions:
1) There wasn't an empty version of these functions
2) The #if only depended on CONFIG_ACPI. But the functions are implemented
in the core spi.c so CONFIG_SPI_MASTER must also be enabled for the real
functions to exist.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20240802152215.20831-2-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Some SPI peripherals may require strict MOSI line state when the controller
is not clocking out data. Implement support for MOSI idle state
configuration (low or high) by setting the data output line level on
controller setup and after transfers. Bitbang operations now call
controller specific set_mosi_idle() callback to set MOSI to its idle state.
The MOSI line is kept at its idle state if no tx buffer is provided.
Acked-by: Nuno Sa <nuno.sa@analog.com>
Reviewed-by: David Lechner <dlechner@baylibre.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Marcelo Schmitt <marcelo.schmitt@analog.com>
Link: https://patch.msgid.link/de61a600b56ed9cb714d5ea87afa88948e70041e.1720810545.git.marcelo.schmitt@analog.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Here is the big set of driver core changes for 6.11-rc1.
Lots of stuff in here, with not a huge diffstat, but apis are evolving
which required lots of files to be touched. Highlights of the changes
in here are:
- platform remove callback api final fixups (Uwe took many releases to
get here, finally!)
- Rust bindings for basic firmware apis and initial driver-core
interactions. It's not all that useful for a "write a whole driver
in rust" type of thing, but the firmware bindings do help out the
phy rust drivers, and the driver core bindings give a solid base on
which others can start their work. There is still a long way to go
here before we have a multitude of rust drivers being added, but
it's a great first step.
- driver core const api changes. This reached across all bus types,
and there are some fix-ups for some not-common bus types that
linux-next and 0-day testing shook out. This work is being done to
help make the rust bindings more safe, as well as the C code, moving
toward the end-goal of allowing us to put driver structures into
read-only memory. We aren't there yet, but are getting closer.
- minor devres cleanups and fixes found by code inspection
- arch_topology minor changes
- other minor driver core cleanups
All of these have been in linux-next for a very long time with no
reported problems.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCZqH+aQ8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+ymoOQCfVBdLcBjEDAGh3L8qHRGMPy4rV2EAoL/r+zKm
cJEYtJpGtWX6aAtugm9E
=ZyJV
-----END PGP SIGNATURE-----
Merge tag 'driver-core-6.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core
Pull driver core updates from Greg KH:
"Here is the big set of driver core changes for 6.11-rc1.
Lots of stuff in here, with not a huge diffstat, but apis are evolving
which required lots of files to be touched. Highlights of the changes
in here are:
- platform remove callback api final fixups (Uwe took many releases
to get here, finally!)
- Rust bindings for basic firmware apis and initial driver-core
interactions.
It's not all that useful for a "write a whole driver in rust" type
of thing, but the firmware bindings do help out the phy rust
drivers, and the driver core bindings give a solid base on which
others can start their work.
There is still a long way to go here before we have a multitude of
rust drivers being added, but it's a great first step.
- driver core const api changes.
This reached across all bus types, and there are some fix-ups for
some not-common bus types that linux-next and 0-day testing shook
out.
This work is being done to help make the rust bindings more safe,
as well as the C code, moving toward the end-goal of allowing us to
put driver structures into read-only memory. We aren't there yet,
but are getting closer.
- minor devres cleanups and fixes found by code inspection
- arch_topology minor changes
- other minor driver core cleanups
All of these have been in linux-next for a very long time with no
reported problems"
* tag 'driver-core-6.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (55 commits)
ARM: sa1100: make match function take a const pointer
sysfs/cpu: Make crash_hotplug attribute world-readable
dio: Have dio_bus_match() callback take a const *
zorro: make match function take a const pointer
driver core: module: make module_[add|remove]_driver take a const *
driver core: make driver_find_device() take a const *
driver core: make driver_[create|remove]_file take a const *
firmware_loader: fix soundness issue in `request_internal`
firmware_loader: annotate doctests as `no_run`
devres: Correct code style for functions that return a pointer type
devres: Initialize an uninitialized struct member
devres: Fix memory leakage caused by driver API devm_free_percpu()
devres: Fix devm_krealloc() wasting memory
driver core: platform: Switch to use kmemdup_array()
driver core: have match() callback in struct bus_type take a const *
MAINTAINERS: add Rust device abstractions to DRIVER CORE
device: rust: improve safety comments
MAINTAINERS: add Danilo as FIRMWARE LOADER maintainer
MAINTAINERS: add Rust FW abstractions to FIRMWARE LOADER
firmware: rust: improve safety comments
...
There's some quite exciting core work in this release, we've got the
beginnings of support for hardware initiated transfers which is itself
independently useful for optimising fast paths in existing drivers.
We also have a rework of the DMA mapping which allows finer grained
decisions about DMA mapping messages and also helps remove some bodges
that we'd had.
Otherwise it's a fairly quiet release, a few new drivers and features
for existing drivers, together with various cleanups and DT binding
conversions.
One regmap SPI fix made it's way in here too which I should probably
have sent as a regmap fix instead.
- Support for pre-optimising messages, reducing the overhead for
messages that are repeatedly used (eg, reading the interrupt status
from a device). This will also be used for hardware initiated
transfers in future.
- A reworking of how DMA mapping is done, introducing a new helper and
allowing the DMA mapping decision to be done per transfer instead of
per message.
- Support for Atmel SAMA7D64, Freescale LX2160A DSPI and WCH CH341A.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmaVLH0ACgkQJNaLcl1U
h9DhHQf+KD1gVf0dF9N7Y4gf+fjFQpbf7hxpB24lpJ952/9Ke1hsM19JZDqNaTVa
ITXIyQLr4uCtPXZ6jOd03td/6TGs9sG3VTLcRrYCG44CvhWpDgAg9Nc3KbNj95Zf
oPWMLEG2Y2ZjGzIrbqciJ5IRF/gT4rnc2PwytmkrPYwQn6CLUCw7BM3QFFqMnyPb
U4UA/EmLuOqtlu4z+hdL97JX/XWQfWNLzXfIlIrfJserRBexwmefN7Y2+5fica02
OBTDyMsg82yZtqASvbsTVn4di577oCYbMnpy+0f+a74h2DDMDfspury8CbrST+Cj
Jr7/082RuYUlUUyrR9N98EhJ9p1K+w==
=snrv
-----END PGP SIGNATURE-----
Merge tag 'spi-v6.11' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi
Pull spi updates from Mark Brown:
"There's some quite exciting core work in this release, we've got the
beginnings of support for hardware initiated transfers which is itself
independently useful for optimising fast paths in existing drivers.
We also have a rework of the DMA mapping which allows finer grained
decisions about DMA mapping messages and also helps remove some bodges
that we'd had.
Otherwise it's a fairly quiet release, a few new drivers and features
for existing drivers, together with various cleanups and DT binding
conversions.
One regmap SPI fix made it's way in here too which I should probably
have sent as a regmap fix instead.
Summary:
- Support for pre-optimising messages, reducing the overhead for
messages that are repeatedly used (eg, reading the interrupt status
from a device). This will also be used for hardware initiated
transfers in future.
- A reworking of how DMA mapping is done, introducing a new helper
and allowing the DMA mapping decision to be done per transfer
instead of per message.
- Support for Atmel SAMA7D64, Freescale LX2160A DSPI and WCH CH341A"
* tag 'spi-v6.11' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: (72 commits)
spi: dt-bindings: at91: Add sama7d65 compatible string
spi: add ch341a usb2spi driver
spi: dt-bindings: fsl-dspi: add compatible string 'fsl,lx2160a-dspi'
spi: dt-bindings: fsl-dspi: add dmas and dma-names properties
spi: spi: Remove unnecessary ‘0’ values from status
spi: spi: Remove unnecessary ‘0’ values from rc
spi: xcomm: fix coding style
spi: xcomm: remove i2c_set_clientdata()
spi: xcomm: make use of devm_spi_alloc_host()
spi: xcomm: add gpiochip support
spi: dt-bindings: snps,dw-apb-ssi.yaml: update compatible property
spi: dt-bindings: fsl-dspi: Convert to yaml format
spi: fsl-dspi: use common proptery 'spi-cs-setup(hold)-delay-ns'
spi: axi-spi-engine: remove platform_set_drvdata()
spi: spi-fsl-lpspi: Pass pm_ptr()
spi: spi-imx: Pass pm_ptr()
spi: spi-fsl-lpspi: Switch to SYSTEM_SLEEP_PM_OPS()
spi: spi-imx: Switch to RUNTIME_PM_OPS/SYSTEM_SLEEP_PM_OPS()
spi: add EXPORT_SYMBOL_GPL(devm_spi_optimize_message)
spi: add devm_spi_optimize_message() helper
...
Adding spi_optimize_message() broke the spi-mux driver because it
calls spi_async() from it's transfer_one_message() callback. This
resulted in passing an incorrectly optimized message to the controller.
For example, if the underlying controller has an optimize_message()
callback, this would have not been called and can cause a crash when
the underlying controller driver tries to transfer the message.
Also, since the spi-mux driver swaps out the controller pointer by
replacing msg->spi, __spi_unoptimize_message() was being called with a
different controller than the one used in __spi_optimize_message(). This
could cause a crash when attempting to free the message resources when
__spi_unoptimize_message() is called in spi_finalize_current_message()
since it is being called with a controller that did not allocate the
resources.
This is fixed by adding a defer_optimize_message flag for controllers.
This flag causes all of the spi_[maybe_][un]optimize_message() calls to
be a no-op (other than attaching a pointer to the spi device to the
message).
This allows the spi-mux driver to pass an unmodified message to
spi_async() in spi_mux_transfer_one_message() after the spi device has
been swapped out. This causes __spi_optimize_message() and
__spi_unoptimize_message() to be called only once per message and with
the correct/same controller in each case.
Reported-by: Oleksij Rempel <o.rempel@pengutronix.de>
Closes: https://lore.kernel.org/linux-spi/Zn6HMrYG2b7epUxT@pengutronix.de/
Reported-by: Marc Kleine-Budde <mkl@pengutronix.de>
Closes: https://lore.kernel.org/linux-spi/20240628-awesome-discerning-bear-1621f9-mkl@pengutronix.de/
Fixes: 7b1d87af14 ("spi: add spi_optimize_message() APIs")
Signed-off-by: David Lechner <dlechner@baylibre.com>
Link: https://patch.msgid.link/20240708-spi-mux-fix-v1-2-6c8845193128@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
In the match() callback, the struct device_driver * should not be
changed, so change the function callback to be a const *. This is one
step of many towards making the driver core safe to have struct
device_driver in read-only memory.
Because the match() callback is in all busses, all busses are modified
to handle this properly. This does entail switching some container_of()
calls to container_of_const() to properly handle the constant *.
For some busses, like PCI and USB and HV, the const * is cast away in
the match callback as those busses do want to modify those structures at
this point in time (they have a local lock in the driver structure.)
That will have to be changed in the future if they wish to have their
struct device * in read-only-memory.
Cc: Rafael J. Wysocki <rafael@kernel.org>
Reviewed-by: Alex Elder <elder@kernel.org>
Acked-by: Sumit Garg <sumit.garg@linaro.org>
Link: https://lore.kernel.org/r/2024070136-wrongdoer-busily-01e8@gregkh
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Merge series from David Lechner <dlechner@baylibre.com>:
In the IIO subsystem, we are finding that it is common to call
spi_optimize_message() during driver probe since the SPI message
doesn't change for the lifetime of the driver. This patch adds a
devm_spi_optimize_message() helper to simplify this common pattern.
Kees Cook