kernel/linux.git/include/linux/spi/spi.h, branch v5.4.185

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

spi: core: allow defining time that cs is deasserted

2019-05-08T09:28:51+00:00

For some SPI devices that support speed_hz > 1MHz the default 10 us delay when cs_change = 1 is typically way to long and may result in poor spi bus utilization. This patch makes it possible to control the delay at micro or nano second resolution on a per spi_transfer basis. It even allows an "as fast as possible" mode with: xfer.cs_change_delay_unit = SPI_DELAY_UNIT_NSECS; xfer.cs_change_delay = 0; The delay code is shared between delay_usecs and cs_change_delay for consistency and reuse, so in the future this change_delay_unit could also apply to delay_usec as well. Note that on slower SOCs/CPU actually reaching ns deasserts on cs is not realistic as the gpio overhead alone (without any delays added ) may already leave cs deasserted for more than 1us - at least on a raspberry pi. But at the very least this way we can keep it as short as possible. Signed-off-by: Martin Sperl Signed-off-by: Mark Brown

spi: expand mode support

2019-05-02T01:37:55+00:00

This patch changes mode and mode_bits from u16 to u32 to allow more mode configurations. Signed-off-by: Sowjanya Komatineni Signed-off-by: Mark Brown