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>
First of all, the (foo && bar) || (!foo && !bar) when foo and bar
are booleans is equivalent to (foo == bar). Second, reuse variable
that holds already the calculation of the SPI CS mode to be
active-high. No functional changes intended.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20250331093915.4041600-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The biggest change for SPI this release is the addition of offload
support from David Lechner, allowing the hardware to trigger SPI
transactions autonomously. The initial use case is for triggering IIO
operations but there are other applications where having the hardware
ready to go at a minimal signal is useful for synchronising with
external inputs (eg, interrupt handling) or reducing latency (eg, CAN
networking). Otherwise there's the usual fixes, improvements and
cleanups, plus support for a bunch of new devices.
- Support for offloaing support from David Lechner.
- Support for GOcontrol1 Moduline modules, Mediatek MT7988, NXP i.MX94,
Qualcomm SPI NAMD, Rockchip RK3562, Sophogo SG2044 and ST STM32 OSPI.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmfhbQgACgkQJNaLcl1U
h9DQrAf6A30I4GJGwD4qWwCdsChxr0of8r3q0zIAcC53UaMqLBTdwnQT+wD4MTe8
vnUY54Z8PYoDKaPx54YxmWh0zB4OQgxvtcJyaZ9biLWtPy3kZdhHlC5xrVQbzLc5
ki/AW2Fsl2GQ1+5mtI3yP6awQ5HQ17gXS1q+nl2/D1njv2sI1Z1998nBkmsaNwNb
SPmaDV5UIQkO9wENnJCbX7bRlM+FgkgYo10JFffmWCnntsaZ01NlUC+BBg9y9xAy
padE2ucWWDqdmiHOC1z7kJU5MFGZWGSSVATLZZz3GL+vw/Oan/Mb5K2zoZh0IcD9
QPJxNnokYtYFR/IlH/obL0EMutaoSQ==
=vqZa
-----END PGP SIGNATURE-----
Merge tag 'spi-v6.15' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi
Pull spi updates from Mark Brown:
"The biggest change for SPI this release is the addition of offload
support from David Lechner, allowing the hardware to trigger SPI
transactions autonomously. The initial use case is for triggering IIO
operations but there are other applications where having the hardware
ready to go at a minimal signal is useful for synchronising with
external inputs (eg, interrupt handling) or reducing latency (eg, CAN
networking).
Otherwise there's the usual fixes, improvements and cleanups, plus
support for a bunch of new devices.
- Support for offloading support from David Lechner
- Support for GOcontrol1 Moduline modules, Mediatek MT7988, NXP
i.MX94, Qualcomm SPI NAMD, Rockchip RK3562, Sophogo SG2044 and ST
STM32 OSPI"
* tag 'spi-v6.15' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: (59 commits)
spi: spi-mem: Introduce a default ->exec_op() debug log
spi: dt-bindings: cdns,qspi-nor: Require some peripheral properties
spi: dt-bindings: cdns,qspi-nor: Deprecate the Cadence compatible alone
spi: dt-bindings: cdns,qspi-nor: Be more descriptive regarding what this controller is
spi: stm32-ospi: Include "gpio/consumer.h"
MAINTAINERS: adjust the file entry in GOCONTROLL MODULINE MODULE SLOT
spi: spi-qpic-snand: avoid memleak in qcom_spi_ecc_init_ctx_pipelined()
spi: spi-mux: Fix coverity issue, unchecked return value
spi: sophgo: fix incorrect type for ret in sg2044_spifmc_write()
spi: sg2044-nor: fix uninitialized variable in probe
spi: sg2044-nor: fix signedness bug in sg2044_spifmc_write()
spi: sg2044-nor: Convert to dev_err_probe()
spi: sg2044-nor: Fully convert to device managed resources
dt-bindings: spi: add compatibles for mt7988
spi: spidev: Add an entry for the gocontroll moduline module slot
MAINTAINERS: add maintainer for the GOcontroll Moduline module slot
dt-bindings: connector: Add the GOcontroll Moduline module slot bindings
dt-bindings: vendor-prefixes: add GOcontroll
spi: Use inclusive language
spi: cadence-qspi: Improve spi memory performance
...
Fix a reference count leak in slave_show() by properly putting the device
reference obtained from device_find_any_child().
Fixes: 6c364062bf ("spi: core: Add support for registering SPI slave controllers")
Fixes: c21b083798 ("spi: Use device_find_any_child() instead of custom approach")
Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20250319032305.70340-1-linmq006@gmail.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>
Merge series from David Lechner <dlechner@baylibre.com>:
As a recap, here is the background and end goal of this series:
The AXI SPI Engine is a SPI controller that has the ability to record a
series of SPI transactions and then play them back using a hardware
trigger. This allows operations to be performed, repeating many times,
without any CPU intervention. This is needed for achieving high data
rates (millions of samples per second) from ADCs and DACs that are
connected via a SPI bus.
The offload hardware interface consists of a trigger input and a data
output for the RX data. These are connected to other hardware external
to the SPI controller.
To record one or more transactions, commands and TX data are written
to memories in the controller (RX buffer is not used since RX data gets
streamed to an external sink). This sequence of transactions can then be
played back when the trigger input is asserted.
This series includes core SPI support along with the first SPI
controller (AXI SPI Engine) and SPI peripheral (AD7944 ADC) that use
them. This enables capturing analog data at 2 million samples per
second.
The hardware setup looks like this:
+-------------------------------+ +------------------+
| | | |
| SOC/FPGA | | AD7944 ADC |
| +---------------------+ | | |
| | AXI SPI Engine | | | |
| | SPI Bus ============ SPI Bus |
| | | | | |
| | +---------------+ | | | |
| | | Offload 0 | | | +------------------+
| | | RX DATA OUT > > > > |
| | | TRIGGER IN < < < v |
| | +---------------+ | ^ v |
| +---------------------+ ^ v |
| | AXI PWM | ^ v |
| | CH0 > ^ v |
| +---------------------+ v |
| | AXI DMA | v |
| | CH0 < < < |
| +---------------------+ |
| |
+-------------------------------+
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>
This is a fairly quiet release for the most part, though we do have one
really nice improvement in the spi-mem framework which will improve
performance for flash devices especially when built on by changes in the
MTD subsystem which are also due to be sent this merge window. There's
also been some substantial work on some of the drivers, highlights
include:
- Support for per-operation bus frequency in the spi-mem framework,
meaning speeds are no longer limited by the slowest operation.
- ACPI support and improved power management for Rockchip SFC
controllers.
- Support for Atmel SAM7G5 QuadSPI and KEBA SPI controllers.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmeOY7sACgkQJNaLcl1U
h9AA2gf/Zb0B7R5aVlW46OWTYNklvO/yu/3JmVFnd+BdRjr+0/UpnUQ8SAnsFuiK
uX1Mw241SpngI4naqhLdR28SP6dMFyi+/5Orl2/kIzx6RSmCMbNDiw56x71KcXFl
pPjDHRdWOTdRiOwa37/wniaP6wDoWsF4F6sI1jazZP0tc7u+QwT9Hgu+jkzUIQfS
8eSS1W7zOHxqKVohsOb4V8ddVHGbS7EyTbm5RuMOtWP08pTIgzMdQo76WUTkRjLe
8N0PNIbDZSSFLF//DMhTZgeD63cjPN4y7UsM1Z8jrKBtLrEzKSPy/bI/IpnLYyd2
Wdpp2mSCGtRvBO0zU59/HOMv8jYkXw==
=mFrM
-----END PGP SIGNATURE-----
Merge tag 'spi-v6.14' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi
Pull spi updates from Mark Brown:
"This is a fairly quiet release for the most part, though we do have
one really nice improvement in the spi-mem framework which will
improve performance for flash devices especially when built on by
changes in the MTD subsystem which are also due to be sent this merge
window.
There's also been some substantial work on some of the drivers,
highlights include:
- Support for per-operation bus frequency in the spi-mem framework,
meaning speeds are no longer limited by the slowest operation
- ACPI support and improved power management for Rockchip SFC
controllers
- Support for Atmel SAM7G5 QuadSPI and KEBA SPI controllers"
* tag 'spi-v6.14' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: (49 commits)
spi: pxa2xx: Introduce __lpss_ssp_update_priv() helper
spi: ti-qspi: Use syscon_regmap_lookup_by_phandle_args
spi: amd: Fix -Wuninitialized in amd_spi_exec_mem_op()
spi: spi-mem: Estimate the time taken by operations
spi: spi-mem: Create macros for DTR operation
spi: spi-mem: Reorder spi-mem macro assignments
spi: zynqmp-gqspi: Support per spi-mem operation frequency switches
spi: zynq-qspi: Support per spi-mem operation frequency switches
spi: spi-ti-qspi: Support per spi-mem operation frequency switches
spi: spi-sn-f-ospi: Support per spi-mem operation frequency switches
spi: rockchip-sfc: Support per spi-mem operation frequency switches
spi: nxp-fspi: Support per spi-mem operation frequency switches
spi: mxic: Support per spi-mem operation frequency switches
spi: mt65xx: Support per spi-mem operation frequency switches
spi: microchip-core-qspi: Support per spi-mem operation frequency switches
spi: fsl-qspi: Support per spi-mem operation frequency switches
spi: dw: Support per spi-mem operation frequency switches
spi: cadence-qspi: Support per spi-mem operation frequency switches
spi: amlogic-spifc-a1: Support per spi-mem operation frequency switches
spi: amd: Drop redundant check
...
kthread_create() creates a kthread without running it yet. kthread_run()
creates a kthread and runs it.
On the other hand, kthread_create_worker() creates a kthread worker and
runs it.
This difference in behaviours is confusing. Also there is no way to
create a kthread worker and affine it using kthread_bind_mask() or
kthread_affine_preferred() before starting it.
Consolidate the behaviours and introduce kthread_run_worker[_on_cpu]()
that behaves just like kthread_run(). kthread_create_worker[_on_cpu]()
will now only create a kthread worker without starting it.
Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
The few functions are using different approaches on how to check for
the type of firmware node. Unify them to use a modern way of it.
With that in place it becomes obvious that no need to have independent
conditionals when they are dependent and hence the code generation can
be improved a little bit (clang-18, x86_64):
add/remove: 0/0 grow/shrink: 2/2 up/down: 16/-46 (-30)
Total: Before=49801, After=49771, chg -0.06%
Meanwhile no functional changes intended.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20241208195635.1271656-2-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
When probing spi device take care of deferred probe of ACPI irq gpio
similar like for OF/DT case.
>From practical standpoint this fixes issue with vsc-tp driver on
Dell XP 9340 laptop, which try to request interrupt with spi->irq
equal to -EPROBE_DEFER and fail to probe with the following error:
vsc-tp spi-INTC10D0:00: probe with driver vsc-tp failed with error -22
Suggested-by: Hans de Goede <hdegoede@redhat.com>
Fixes: 33ada67da3 ("ACPI / spi: attach GPIO IRQ from ACPI description to SPI device")
Cc: stable@vger.kernel.org
Signed-off-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: Alexis Lothoré <alexis.lothore@bootlin.com> # Dell XPS9320, ov01a10
Link: https://patch.msgid.link/20241122094224.226773-1-stanislaw.gruszka@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The use of of_property_read_bool() for non-boolean properties is
deprecated in favor of of_property_present() when testing for property
presence.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20241104190759.277184-2-robh@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The two instances of struct class are only used here in functions that
take const pointers and so can too be made constant.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Link: https://patch.msgid.link/20241018122437.64275-1-brgl@bgdev.pl
Signed-off-by: Mark Brown <broonie@kernel.org>
Using dev_err_probe() in spi_probe() improves the kernel output from
spi spi0.0: deferred probe pending: (reason unknown)
to
spi spi0.0: deferred probe pending: ad7124: Failed to get irq...
for my current quest to make a certain spi device work.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Link: https://patch.msgid.link/20241004094234.268301-2-u.kleine-koenig@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.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>
The behavior of an SPI controller data output line (SDO or MOSI or COPI
(Controller Output Peripheral Input) for disambiguation) is usually not
specified when the controller is not clocking out data on SCLK edges.
However, there do exist SPI peripherals that require specific MOSI line
state when data is not being clocked out of the controller.
Conventional SPI controllers may set the MOSI line on SCLK edges then bring
it low when no data is going out or leave the line the state of the last
transfer bit. More elaborated controllers are capable to set the MOSI idle
state according to different configurable levels and thus are more suitable
for interfacing with demanding peripherals.
Add SPI mode bits to allow peripherals to request explicit MOSI idle state
when needed.
When supporting a particular MOSI idle configuration, the data output line
state is expected to remain at the configured level when the controller is
not clocking out data. When a device that needs a specific MOSI idle state
is identified, its driver should request the MOSI idle configuration by
setting the proper SPI mode bit.
Acked-by: Nuno Sa <nuno.sa@analog.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: David Lechner <dlechner@baylibre.com>
Tested-by: David Lechner <dlechner@baylibre.com>
Signed-off-by: Marcelo Schmitt <marcelo.schmitt@analog.com>
Link: https://patch.msgid.link/9802160b5e5baed7f83ee43ac819cb757a19be55.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>
Calling spi_maybe_unoptimize_message() in spi_async() is wrong because
the message is likely to be in the queue and not transferred yet. This
can corrupt the message while it is being used by the controller driver.
spi_maybe_unoptimize_message() is already called in the correct place
in spi_finalize_current_message() to balance the call to
spi_maybe_optimize_message() in spi_async().
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-1-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.
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.
While adding a SPI device, the SPI core ensures that multiple logical CS
doesn't map to the same physical CS. For example, spi->chip_select[0] !=
spi->chip_select[1] and so forth. However, unlike the SPI master, the SPI
slave doesn't have the list of chip selects, this leads to probe failure
when the SPI controller is configured as slave. Update the
__spi_add_device() function to perform this check only if the SPI
controller is configured as master.
Fixes: 4d8ff6b099 ("spi: Add multi-cs memories support in SPI core")
Signed-off-by: Amit Kumar Mahapatra <amit.kumar-mahapatra@amd.com>
Link: https://msgid.link/r/20240617153052.26636-1-amit.kumar-mahapatra@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The granularity of DMA mappings is transfer and moreover,
the direction is also important as it can be unidirect.
The current cur_msg_mapped flag doesn't fit well the DMA mapping
and syncing calls and we have tons of checks around on top of it.
So, instead of doing that rework the code to use per transfer per
direction flag to show if it's DMA mapped or not.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-QRD
Link: https://lore.kernel.org/r/20240531194723.1761567-9-andriy.shevchenko@linux.intel.com
Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
Tested-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQFSBAABCAA8FiEEq68RxlopcLEwq+PEeb4+QwBBGIYFAmZc9egeHHRvcnZhbGRz
QGxpbnV4LWZvdW5kYXRpb24ub3JnAAoJEHm+PkMAQRiGoLsH/0xo1TNZwNRE9Qux
gFbJDDhxMtvWnJCSqUuhpypd7SoVVEVKiXW942gWTl97PlCEH0ov3p+0UbxnmG13
kKJT1C/gct95L03OAfGquIjBSWh4/55o6Vz1zYTGvTFpWZo7G3ZvCDY8o9kN5/L3
mnpC+GfzZ9ckg+2TfwlbGBQUtILHV3IipCbfDFPSrT8mS0IT67uvBlND3nI++woj
J1znGqg1PQ6yFnFCfj4RYCiyv/jEAT0ZTyokO4rH+iQVufc3y02mokhMuqmSoE6T
5bbHToLZIaa/QjRamN/+ltwyrhv8WlX4rJOkMibJY6w8gpukt/k6gL2Pguk4y2pf
0FPbbC0=
=0AGs
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmZdsDsACgkQJNaLcl1U
h9B5bgf+K3H6WnMn+2TsKE7TBRW8D8J1FJdYDcJ5CoM/tw10YqgNHIvrZXvikLQG
Di3jM3SIFTWn2R350PBx+z+05o3vjVKWpH1bi/EPCCfKl80vyOaMFDZYL7jRxBBl
x3dzqsn//U13U2mdVQ0d1plxtCBqzy8v1nDq+9KNog1gjfTLFQ2Aa+++oZkoDqo4
TJgqBAAzmynDawEhZ7WKdAb6Wb/AEyvWGgfudE+N2Qs3NZt2tbnD2KH23e8SF3ZN
J3CiL6JPSuI2fAW8+zlZdmQRf/pEZFXxebnKc7fyDglqmzU4Pw4IIt/xIfuFMDBA
eEPZ+gaeBV2jjPsqXb1gxD3hqCMYeQ==
=qq1C
-----END PGP SIGNATURE-----
spi: Merge up fixes
We need these to get the i.MX8 boards working in CI again.
Commit 8cc3bad9d9 ("spi: Remove unneded check for orig_nents")
introduced a regression: unmapped data could now be passed to the DMA
APIs, resulting in null pointer dereferences. Commit 9f788ba457 ("spi:
Don't mark message DMA mapped when no transfer in it is") and commit
da560097c0 ("spi: Check if transfer is mapped before calling DMA sync
APIs") addressed the problem, but only partially. Unidirectional
transactions will still result in null pointer dereference. To prevent
that from happening, assign a dummy scatterlist when no data is mapped,
so that the DMA API can be called and not result in a null pointer
dereference.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reported-by: Neil Armstrong <neil.armstrong@linaro.org>
Closes: https://lore.kernel.org/r/8ae675b5-fcf9-4c9b-b06a-4462f70e1322@linaro.org
Reported-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Closes: https://lore.kernel.org/all/d3679496-2e4e-4a7c-97ed-f193bd53af1d@notapiano
Closes: https://lore.kernel.org/all/4748499f-789c-45a8-b50a-2dd09f4bac8c@notapiano
Fixes: 8cc3bad9d9 ("spi: Remove unneded check for orig_nents")
Tested-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
[nfraprado: wrote the commit message]
Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Link: https://msgid.link/r/20240529-dma-oops-dummy-v1-1-bb43aacfb11b@collabora.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The refactoring makes code less verbose and easier to read.
Besides that the binary size is also reduced, which sounds
like a win-win case:
add/remove: 0/1 grow/shrink: 2/2 up/down: 210/-226 (-16)
Function old new delta
spi_destroy_queue 42 156 +114
spi_controller_suspend 101 197 +96
spi_unregister_controller 346 319 -27
spi_register_controller 1834 1794 -40
spi_stop_queue 159 - -159
Total: Before=49230, After=49214, chg -0.03%
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://msgid.link/r/20240510204945.2581944-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Andy Shevchenko <andriy.shevchenko@linux.intel.com>:
A couple of fixes to avoid calling DMA sync API when it's not needed.
This doesn't stop from discussing if IOMMU code is doing the right thing,
i.e. dereferences SG list when orig_nents == 0, but this is a separate
story.
The resent update to remove the orig_nents checks revealed
that not all DMA sync backends can cope with the unallocated
SG list, while supplying orig_nents == 0 (the commit 861370f49c
("iommu/dma: force bouncing if the size is not cacheline-aligned"),
for example, makes that happen for the IOMMU case). It means
we have to check if the buffers are DMA mapped before trying
to sync them. Re-introduce that check in a form of calling
->can_dma() in the same way as it's done in the DMA mapping loop
for the SPI transfers.
Reported-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Reported-by: Neil Armstrong <neil.armstrong@linaro.org>
Closes: https://lore.kernel.org/r/8ae675b5-fcf9-4c9b-b06a-4462f70e1322@linaro.org
Closes: https://lore.kernel.org/all/d3679496-2e4e-4a7c-97ed-f193bd53af1d@notapiano
Fixes: 8cc3bad9d9 ("spi: Remove unneded check for orig_nents")
Suggested-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Tested-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://msgid.link/r/20240522171018.3362521-3-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There is no need to set the DMA mapped flag of the message if it has
no mapped transfers. Moreover, it may give the code a chance to take
the wrong paths, i.e. to exercise DMA related APIs on unmapped data.
Make __spi_map_msg() to bail earlier on the above mentioned cases.
Fixes: 99adef310f ("spi: Provide core support for DMA mapping transfers")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://msgid.link/r/20240522171018.3362521-2-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Both dma_unmap_sgtable() and sg_free_table() in spi_unmap_buf_attrs()
have checks for orig_nents against 0. No need to duplicate this.
All the same applies to other DMA mapping API calls.
Also note, there is no other user in the kernel that does this kind of
checks.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20240507201028.564630-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
If spi_sync() is called with the non-empty queue and the same spi_message
is then reused, the complete callback for the message remains set while
the context is cleared, leading to a null pointer dereference when the
callback is invoked from spi_finalize_current_message().
With function inlining disabled, the call stack might look like this:
_raw_spin_lock_irqsave from complete_with_flags+0x18/0x58
complete_with_flags from spi_complete+0x8/0xc
spi_complete from spi_finalize_current_message+0xec/0x184
spi_finalize_current_message from spi_transfer_one_message+0x2a8/0x474
spi_transfer_one_message from __spi_pump_transfer_message+0x104/0x230
__spi_pump_transfer_message from __spi_transfer_message_noqueue+0x30/0xc4
__spi_transfer_message_noqueue from __spi_sync+0x204/0x248
__spi_sync from spi_sync+0x24/0x3c
spi_sync from mcp251xfd_regmap_crc_read+0x124/0x28c [mcp251xfd]
mcp251xfd_regmap_crc_read [mcp251xfd] from _regmap_raw_read+0xf8/0x154
_regmap_raw_read from _regmap_bus_read+0x44/0x70
_regmap_bus_read from _regmap_read+0x60/0xd8
_regmap_read from regmap_read+0x3c/0x5c
regmap_read from mcp251xfd_alloc_can_err_skb+0x1c/0x54 [mcp251xfd]
mcp251xfd_alloc_can_err_skb [mcp251xfd] from mcp251xfd_irq+0x194/0xe70 [mcp251xfd]
mcp251xfd_irq [mcp251xfd] from irq_thread_fn+0x1c/0x78
irq_thread_fn from irq_thread+0x118/0x1f4
irq_thread from kthread+0xd8/0xf4
kthread from ret_from_fork+0x14/0x28
Fix this by also setting message->complete to NULL when the transfer is
complete.
Fixes: ae7d2346dc ("spi: Don't use the message queue if possible in spi_sync")
Signed-off-by: Mans Rullgard <mans@mansr.com>
Link: https://lore.kernel.org/r/20240430182705.13019-1-mans@mansr.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There are macros spi_valid_txbuf() and spi_valid_rxbuf() for determining
if an xfer actually intended to send or receive data.
These checks were hard-coded in spi_statistics_add_transfer_stats(). We
can make use of the macros instead to make the code more readable and
more robust against potential future changes in case the definition of
what valid means changes.
The macro takes the spi_message as an argument, so we need to change
spi_statistics_add_transfer_stats() to take the spi_message as an
argument instead of the controller.
Signed-off-by: David Lechner <dlechner@baylibre.com>
Link: https://lore.kernel.org/r/20240430201530.2138095-3-dlechner@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Charles Keepax <ckeepax@opensource.cirrus.com>:
In some cs42l43 systems a couple of cs35l56 amplifiers are attached
to the cs42l43's SPI and I2S. On Windows the cs42l43 is controlled
by a SDCA class driver and these two amplifiers are controlled by
firmware running on the cs42l43. However, under Linux the decision
was made to interact with the cs42l43 directly, affording the user
greater control over the audio system. However, this has resulted
in an issue where these two bridged cs35l56 amplifiers are not
populated in ACPI and must be added manually. There is at least an
SDCA extension unit DT entry we can key off.
The process of adding this is handled using a software node, firstly the
ability to add native chip selects to software nodes must be added.
Secondly, an additional flag for naming the SPI devices is added this
allows the machine driver to key to the correct amplifier. Then finally,
the cs42l43 SPI driver adds the two amplifiers directly onto its SPI
bus.
An additional series will follow soon to add the audio machine driver
parts (in the sof-sdw driver), however that is fairly orthogonal to
this part of the process, getting the actual amplifiers registered.
Merge series from Andy Shevchenko <andriy.shevchenko@linux.intel.com>:
A couple of additional refactorings on top of the multi-CS support.
One is to make sure that the comment and the code are not disrupted
if additional changes come in the future and second one is f or the
sake of deduplication. In both cases it also makes indentation level
smaller in the affected pieces of the code.
No functional changes intended.
