linux-stable.git/include/linux/spi/spi.h, branch linux-5.4.y

spi: Fix deadlock when adding SPI controllers on SPI buses

2024-11-17T13:58:51+00:00

commit 6098475d4cb48d821bdf453c61118c56e26294f0 upstream.

Currently we have a global spi_add_lock which we take when adding new
devices so that we can check that we're not trying to reuse a chip
select that's already controlled.  This means that if the SPI device is
itself a SPI controller and triggers the instantiation of further SPI
devices we trigger a deadlock as we try to register and instantiate
those devices while in the process of doing so for the parent controller
and hence already holding the global spi_add_lock.  Since we only care
about concurrency within a single SPI bus move the lock to be per
controller, avoiding the deadlock.

This can be easily triggered in the case of spi-mux.

Reported-by: Uwe Kleine-König 
Signed-off-by: Mark Brown 
Signed-off-by: Hardik Gohil 
Signed-off-by: Greg Kroah-Hartman

spi: introduce SPI_MODE_X_MASK macro

2024-02-23T07:24:48+00:00

[ Upstream commit 029b42d8519cef70c4fb5fcaccd08f1053ed2bf0 ]

Provide a macro to filter all SPI_MODE_0,1,2,3 mode in one run.

The latest SPI framework will parse the devicetree in following call
sequence: of_register_spi_device() -> of_spi_parse_dt()
So, driver do not need to pars the devicetree and will get prepared
flags in the probe.

On one hand it is good far most drivers. On other hand some drivers need to
filter flags provide by SPI framework and apply know to work flags. This drivers
may use SPI_MODE_X_MASK to filter MODE flags and set own, known flags:
  spi->flags &= ~SPI_MODE_X_MASK;
  spi->flags |= SPI_MODE_0;

Signed-off-by: Oleksij Rempel 
Link: https://lore.kernel.org/r/20201027095724.18654-2-o.rempel@pengutronix.de
Signed-off-by: Mark Brown 
Stable-dep-of: 6d710b769c1f ("serial: sc16is7xx: add check for unsupported SPI modes during probe")
Signed-off-by: Sasha Levin

spi: Fix use-after-free with devm_spi_alloc_*

2021-05-14T07:44:20+00:00

[ Upstream commit 794aaf01444d4e765e2b067cba01cc69c1c68ed9 ]

We can't rely on the contents of the devres list during
spi_unregister_controller(), as the list is already torn down at the
time we perform devres_find() for devm_spi_release_controller. This
causes devices registered with devm_spi_alloc_{master,slave}() to be
mistakenly identified as legacy, non-devm managed devices and have their
reference counters decremented below 0.

------------[ cut here ]------------
WARNING: CPU: 1 PID: 660 at lib/refcount.c:28 refcount_warn_saturate+0x108/0x174
[] (refcount_warn_saturate) from [] (kobject_put+0x90/0x98)
[] (kobject_put) from [] (put_device+0x20/0x24)
 r4:b6700140
[] (put_device) from [] (devm_spi_release_controller+0x3c/0x40)
[] (devm_spi_release_controller) from [] (release_nodes+0x84/0xc4)
 r5:b6700180 r4:b6700100
[] (release_nodes) from [] (devres_release_all+0x5c/0x60)
 r8:b1638c54 r7:b117ad94 r6:b1638c10 r5:b117ad94 r4:b163dc10
[] (devres_release_all) from [] (__device_release_driver+0x144/0x1ec)
 r5:b117ad94 r4:b163dc10
[] (__device_release_driver) from [] (device_driver_detach+0x84/0xa0)
 r9:00000000 r8:00000000 r7:b117ad94 r6:b163dc54 r5:b1638c10 r4:b163dc10
[] (device_driver_detach) from [] (unbind_store+0xe4/0xf8)

Instead, determine the devm allocation state as a flag on the
controller which is guaranteed to be stable during cleanup.

Fixes: 5e844cc37a5c ("spi: Introduce device-managed SPI controller allocation")
Signed-off-by: William A. Kennington III 
Link: https://lore.kernel.org/r/20210407095527.2771582-1-wak@google.com
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin

spi: Introduce device-managed SPI controller allocation

2020-11-24T12:29:22+00:00

commit 5e844cc37a5cbaa460e68f9a989d321d63088a89 upstream.

SPI driver probing currently comprises two steps, whereas removal
comprises only one step:

    spi_alloc_master()
    spi_register_controller()

    spi_unregister_controller()

That's because spi_unregister_controller() calls device_unregister()
instead of device_del(), thereby releasing the reference on the
spi_controller which was obtained by spi_alloc_master().

An SPI driver's private data is contained in the same memory allocation
as the spi_controller struct.  Thus, once spi_unregister_controller()
has been called, the private data is inaccessible.  But some drivers
need to access it after spi_unregister_controller() to perform further
teardown steps.

Introduce devm_spi_alloc_master() and devm_spi_alloc_slave(), which
release a reference on the spi_controller struct only after the driver
has unbound, thereby keeping the memory allocation accessible.  Change
spi_unregister_controller() to not release a reference if the
spi_controller was allocated by one of these new devm functions.

The present commit is small enough to be backportable to stable.
It allows fixing drivers which use the private data in their ->remove()
hook after it's been freed.  It also allows fixing drivers which neglect
to release a reference on the spi_controller in the probe error path.

Long-term, most SPI drivers shall be moved over to the devm functions
introduced herein.  The few that can't shall be changed in a treewide
commit to explicitly release the last reference on the controller.
That commit shall amend spi_unregister_controller() to no longer release
a reference, thereby completing the migration.

As a result, the behaviour will be less surprising and more consistent
with subsystems such as IIO, which also includes the private data in the
allocation of the generic iio_dev struct, but calls device_del() in
iio_device_unregister().

Signed-off-by: Lukas Wunner 
Link: https://lore.kernel.org/r/272bae2ef08abd21388c98e23729886663d19192.1605121038.git.lukas@wunner.de
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

Merge remote-tracking branch 'spi/topic/pump-rt' into spi-next

2019-07-04T16:35:11+00:00

spi: Add a prototype for exported spi_set_cs_timing()

2019-06-17T12:49:56+00:00

Compiler is not happy about spi_set_cs_timing() prototype.

drivers/spi/spi.c:3016:6: warning: no previous prototype for ‘spi_set_cs_timing’ [-Wmissing-prototypes]
 void spi_set_cs_timing(struct spi_device *spi, u8 setup, u8 hold,
      ^~~~~~~~~~~~~~~~~

Let's add it to the header.

Signed-off-by: Andy Shevchenko 
Signed-off-by: Mark Brown

spi: Allow SPI devices to request the pumping thread be realtime

2019-05-23T13:44:02+00:00

Right now the only way to get the SPI pumping thread bumped up to
realtime priority is for the controller to request it.  However it may
be that the controller works fine with the normal priority but
communication to a particular SPI device on the bus needs realtime
priority.

Let's add a way for devices to request realtime priority when they set
themselves up.

NOTE: this will just affect the priority of transfers that end up on
the SPI core's pumping thread.  In many cases transfers happen in the
context of the caller so if you need realtime priority for all
transfers you should ensure the calling context is also realtime
priority.

Signed-off-by: Douglas Anderson 
Reviewed-by: Guenter Roeck 
Tested-by: Enric Balletbo i Serra 
Signed-off-by: Mark Brown

spi: core: allow reporting the effectivly used speed_hz for a transfer

2019-05-13T12:11:36+00:00

Provide a means for the spi bus driver to report the effectively used
spi clock frequency used for each spi_transfer.

Signed-off-by: Martin Sperl 
Signed-off-by: Mark Brown

Merge tag 'spi-bpw-is-supported' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi into spi-5.3

2019-05-12T03:08:03+00:00

spi: Add spi_is_bpw_supported()

Lets client drivers check and potentially handle issues.

spi: core: allow defining time that cs is deasserted as a multiple of SCK

2019-05-08T09:30:01+00:00

Support setting a delay between cs assert and deassert as
a multiple of spi clock length.

Signed-off-by: Martin Sperl 
Signed-off-by: Mark Brown