kernel/linux.git/drivers/spi/spidev.c, branch v6.2.2

spi: spidev: fix a recursive locking error

2023-01-27T16:38:05+00:00

When calling spidev_message() from the one of the ioctl() callbacks, the spi_lock is already taken. When we then end up calling spidev_sync(), we get the following splat: [ 214.047619] [ 214.049198] ============================================ [ 214.054533] WARNING: possible recursive locking detected [ 214.059858] 6.2.0-rc3-0.0.0-devel+git.97ec4d559d93 #1 Not tainted [ 214.065969] -------------------------------------------- [ 214.071290] spidev_test/1454 is trying to acquire lock: [ 214.076530] c4925dbc (&spidev->spi_lock){+.+.}-{3:3}, at: spidev_ioctl+0x8e0/0xab8 [ 214.084164] [ 214.084164] but task is already holding lock: [ 214.090007] c4925dbc (&spidev->spi_lock){+.+.}-{3:3}, at: spidev_ioctl+0x44/0xab8 [ 214.097537] [ 214.097537] other info that might help us debug this: [ 214.104075] Possible unsafe locking scenario: [ 214.104075] [ 214.110004] CPU0 [ 214.112461] ---- [ 214.114916] lock(&spidev->spi_lock); [ 214.118687] lock(&spidev->spi_lock); [ 214.122457] [ 214.122457] *** DEADLOCK *** [ 214.122457] [ 214.128386] May be due to missing lock nesting notation [ 214.128386] [ 214.135183] 2 locks held by spidev_test/1454: [ 214.139553] #0: c4925dbc (&spidev->spi_lock){+.+.}-{3:3}, at: spidev_ioctl+0x44/0xab8 [ 214.147524] #1: c4925e14 (&spidev->buf_lock){+.+.}-{3:3}, at: spidev_ioctl+0x70/0xab8 [ 214.155493] [ 214.155493] stack backtrace: [ 214.159861] CPU: 0 PID: 1454 Comm: spidev_test Not tainted 6.2.0-rc3-0.0.0-devel+git.97ec4d559d93 #1 [ 214.169012] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) [ 214.175555] unwind_backtrace from show_stack+0x10/0x14 [ 214.180819] show_stack from dump_stack_lvl+0x60/0x90 [ 214.185900] dump_stack_lvl from __lock_acquire+0x874/0x2858 [ 214.191584] __lock_acquire from lock_acquire+0xfc/0x378 [ 214.196918] lock_acquire from __mutex_lock+0x9c/0x8a8 [ 214.202083] __mutex_lock from mutex_lock_nested+0x1c/0x24 [ 214.207597] mutex_lock_nested from spidev_ioctl+0x8e0/0xab8 [ 214.213284] spidev_ioctl from sys_ioctl+0x4d0/0xe2c [ 214.218277] sys_ioctl from ret_fast_syscall+0x0/0x1c [ 214.223351] Exception stack(0xe75cdfa8 to 0xe75cdff0) [ 214.228422] dfa0: 00000000 00001000 00000003 40206b00 bee266e8 bee266e0 [ 214.236617] dfc0: 00000000 00001000 006a71a0 00000036 004c0040 004bfd18 00000000 00000003 [ 214.244809] dfe0: 00000036 bee266c8 b6f16dc5 b6e8e5f6 Fix it by introducing an unlocked variant of spidev_sync() and calling it from spidev_message() while other users who don't check the spidev->spi's existence keep on using the locking flavor. Reported-by: Francesco Dolcini Fixes: 1f4d2dd45b6e ("spi: spidev: fix a race condition when accessing spidev->spi") Signed-off-by: Bartosz Golaszewski Tested-by: Max Krummenacher Link: https://lore.kernel.org/r/20230116144149.305560-1-brgl@bgdev.pl Signed-off-by: Mark Brown

spi: spidev: remove debug messages that access spidev->spi without locking

2023-01-11T14:15:10+00:00

The two debug messages in spidev_open() dereference spidev->spi without taking the lock and without checking if it's not null. This can lead to a crash. Drop the messages as they're not needed - the user-space will get informed about ENOMEM with the syscall return value. Signed-off-by: Bartosz Golaszewski Link: https://lore.kernel.org/r/20230106100719.196243-2-brgl@bgdev.pl Signed-off-by: Mark Brown

spi: spidev: fix a race condition when accessing spidev->spi

2023-01-11T14:15:10+00:00

There's a spinlock in place that is taken in file_operations callbacks whenever we check if spidev->spi is still alive (not null). It's also taken when spidev->spi is set to NULL in remove(). This however doesn't protect the code against driver unbind event while one of the syscalls is still in progress. To that end we need a lock taken continuously as long as we may still access spidev->spi. As both the file ops and the remove callback are never called from interrupt context, we can replace the spinlock with a mutex. Signed-off-by: Bartosz Golaszewski Link: https://lore.kernel.org/r/20230106100719.196243-1-brgl@bgdev.pl Signed-off-by: Mark Brown

spi: spidev: mask SPI_CS_HIGH in SPI_IOC_RD_MODE

2022-12-01T11:16:56+00:00

Commit f3186dd87669 ("spi: Optionally use GPIO descriptors for CS GPIOs") has changed the user-space interface so that bogus SPI_CS_HIGH started to appear in the mask returned by SPI_IOC_RD_MODE even for active-low CS pins. Commit 138c9c32f090 ("spi: spidev: Fix CS polarity if GPIO descriptors are used") fixed only SPI_IOC_WR_MODE part of the problem. Let's fix SPI_IOC_RD_MODE symmetrically. Test case: #include #include #include int main(int argc, char **argv) { char modew = SPI_CPHA; char moder; int f = open("/dev/spidev0.0", O_RDWR); if (f < 0) return 1; ioctl(f, SPI_IOC_WR_MODE, &modew); ioctl(f, SPI_IOC_RD_MODE, &moder); return moder == modew ? 0 : 2; } Fixes: f3186dd87669 ("spi: Optionally use GPIO descriptors for CS GPIOs") Signed-off-by: Alexander Sverdlin Link: https://lore.kernel.org/r/20221130162927.539512-1-alexander.sverdlin@siemens.com Signed-off-by: Mark Brown

spi: spidev: add SPI_RX_CPHA_FLIP

2022-04-19T12:13:48+00:00

Allow userspace to set SPI_RX_CPHA_FLIP mode bit using the SPI_IOC_WR_MODE32 ioctl. Signed-off-by: Baruch Siach Link: https://lore.kernel.org/r/6ae31ad24f8252418878b21a8759a04b78726dac.1649702729.git.baruch@tkos.co.il Signed-off-by: Mark Brown

spi: spidev: replace usage of found with dedicated list iterator variable

2022-04-05T09:21:55+00:00

To move the list iterator variable into the list_for_each_entry_*() macro in the future it should be avoided to use the list iterator variable after the loop body. To *never* use the list iterator variable after the loop it was concluded to use a separate iterator variable instead of a found boolean [1]. This removes the need to use a found variable and simply checking if the variable was set, can determine if the break/goto was hit. Link: https://lore.kernel.org/all/CAHk-=wgRr_D8CB-D9Kg-c=EHreAsk5SqXPwr9Y7k9sA6cWXJ6w@mail.gmail.com/ Signed-off-by: Jakob Koschel Link: https://lore.kernel.org/r/20220324072534.63420-1-jakobkoschel@gmail.com Signed-off-by: Mark Brown

spi: spidev: Replace OF specific code by device property API

2022-04-05T09:21:50+00:00

Instead of calling the OF specific APIs, use device property ones. It also prevents misusing PRP0001 in ACPI when trying to instantiate spidev directly. We only support special SPI test devices there. Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20220323140215.2568-4-andriy.shevchenko@linux.intel.com Signed-off-by: Mark Brown

spi: spidev: Replace ACPI specific code by device_get_match_data()

2022-04-05T09:21:46+00:00

Instead of calling the ACPI specific APIs, use device_get_match_data(). Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20220323140215.2568-3-andriy.shevchenko@linux.intel.com Signed-off-by: Mark Brown

spi: spidev: Convert BUILD_BUG_ON() to static_assert()

2022-04-05T09:21:42+00:00

static_assert() is a preferred method to fail build when the certain constraints are not met. Convert BUILD_BUG_ON() to static_assert(). Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20220323140215.2568-2-andriy.shevchenko@linux.intel.com Signed-off-by: Mark Brown

spi: make remove callback a void function

2022-02-09T14:32:59+00:00

Merge series from Uwe Kleine-König : this series goal is to change the spi remove callback's return value to void. After numerous patches nearly all drivers already return 0 unconditionally. The four first patches in this series convert the remaining three drivers to return 0, the final patch changes the remove prototype and converts all implementers. base-commit: 26291c54e111ff6ba87a164d85d4a4e134b7315c