linux-toradex.git/drivers/gpio/gpiolib-sysfs.c, branch v6.10-rc2

gpiolib: Get rid of never false gpio_is_valid() calls

2024-04-17T20:46:44+00:00

In the cases when gpio_is_valid() is called with unsigned parameter
the result is always true in the GPIO library code, hence the check
for false won't ever be true. Get rid of such calls.

While at it, move GPIO device base to be unsigned to clearly show
it won't ever be negative. This requires a new definition for the
maximum GPIO number in the system.

Signed-off-by: Andy Shevchenko 
Reviewed-by: Linus Walleij 
Signed-off-by: Bartosz Golaszewski

gpio: sysfs: repair export returning -EPERM on 1st attempt

2024-03-08T09:32:00+00:00

It would make sense to return -EPERM if the bit was already set (already
used), not if it was cleared. Before this fix pins can only be exported on
the 2nd attempt:

$ echo 522 > /sys/class/gpio/export
sh: write error: Operation not permitted
$ echo 522 > /sys/class/gpio/export

Fixes: 35b545332b80 ("gpio: remove gpio_lock")
Signed-off-by: Alexander Sverdlin 
Signed-off-by: Bartosz Golaszewski

gpio: sysfs: fix inverted pointer logic

2024-02-15T07:40:40+00:00

The logic is inverted, we want to return if the chip *IS* NULL.

Fixes: d83cee3d2bb1 ("gpio: protect the pointer to gpio_chip in gpio_device with SRCU")
Reported-by: Dan Carpenter 
Closes: https://lore.kernel.org/linux-gpio/15671341-0b29-40e0-b487-0a4cdc414d8e@moroto.mountain/
Signed-off-by: Bartosz Golaszewski

gpio: use srcu_dereference() with SRCU-protected pointers

2024-02-15T07:39:25+00:00

Lockdep with CONFIG_PROVE_RCU enabled reports false positives about
suspicious rcu_dereference() usage. Let's silence it by using
srcu_dereference() which is the correct helper with SRCU.

Fixes: d83cee3d2bb1 ("gpio: protect the pointer to gpio_chip in gpio_device with SRCU")
Reported-by: kernel test robot 
Closes: https://lore.kernel.org/oe-lkp/202402122234.d85cca9b-lkp@intel.com
Signed-off-by: Bartosz Golaszewski 
Acked-by: Paul E. McKenney

gpio: protect the pointer to gpio_chip in gpio_device with SRCU

2024-02-12T10:00:31+00:00

Ensure we cannot crash if the GPIO device gets unregistered (and the
chip pointer set to NULL) during any of the API calls.

To that end: wait for all users of gdev->chip to exit their read-only
SRCU critical sections in gpiochip_remove().

For brevity: add a guard class which can be instantiated at the top of
every function requiring read-only access to the chip pointer and use it
in all API calls taking a GPIO descriptor as argument. In places where
we only deal with the GPIO device - use regular guard() helpers and
rcu_dereference() for chip access. Do the same in API calls taking a
const pointer to gpio_desc.

Signed-off-by: Bartosz Golaszewski 
Reviewed-by: Linus Walleij 
Acked-by: Andy Shevchenko

gpio: sysfs: don't access gdev->chip if it's not needed

2024-02-12T09:51:13+00:00

Don't dereference gdev->chip if the same information can be obtained
from struct gpio_device.

Suggested-by: Andy Shevchenko 
Signed-off-by: Bartosz Golaszewski 
Reviewed-by: Linus Walleij 
Acked-by: Andy Shevchenko

gpio: sysfs: pass the GPIO device - not chip - to sysfs callbacks

2024-02-12T09:50:58+00:00

We're working towards protecting the chip pointer in struct gpio_device
with SRCU. In order to use it in sysfs callbacks we must pass the pointer
to the GPIO device that wraps the chip instead of the address of the
chip itself as the user data.

Signed-off-by: Bartosz Golaszewski 
Reviewed-by: Linus Walleij 
Acked-by: Andy Shevchenko

gpio: sysfs: extend the critical section for unregistering sysfs devices

2024-02-12T09:50:55+00:00

Checking the gdev->mockdev pointer for NULL must be part of the critical
section.

Signed-off-by: Bartosz Golaszewski 
Reviewed-by: Linus Walleij 
Acked-by: Andy Shevchenko

gpio: remove gpio_lock

2024-02-12T09:50:45+00:00

The "multi-function" gpio_lock is pretty much useless with how it's used
in GPIOLIB currently. Because many GPIO API calls can be called from all
contexts but may also call into sleeping driver callbacks, there are
many places with utterly broken workarounds like yielding the lock to
call a possibly sleeping function and then re-acquiring it again without
taking into account that the protected state may have changed.

It was also used to protect several unrelated things: like individual
descriptors AND the GPIO device list. We now serialize access to these
two with SRCU and so can finally remove the spinlock.

There is of course the question of consistency of lockless access to
GPIO descriptors. Because we only support exclusive access to GPIOs
(officially anyway, I'm looking at you broken
GPIOD_FLAGS_BIT_NONEXCLUSIVE bit...) and the API contract with providers
does not guarantee serialization, it's enough to ensure we cannot
accidentally dereference an invalid pointer and that the state we present
to both users and providers remains consistent. To achieve that: read the
flags field atomically except for a few special cases. Read their current
value before executing callback code and use this value for any subsequent
logic. Modifying the flags depends on the particular use-case and can
differ. For instance: when requesting a GPIO, we need to set the
REQUESTED bit immediately so that the next user trying to request the
same line sees -EBUSY.

While at it: the allocations that used GFP_ATOMIC until this point can
now switch to GFP_KERNEL.

Signed-off-by: Bartosz Golaszewski 
Reviewed-by: Linus Walleij 
Acked-by: Andy Shevchenko

gpio: sysfs: use gpio_device_find() to iterate over existing devices

2024-02-12T09:50:42+00:00

With the list of GPIO devices now protected with SRCU we can use
gpio_device_find() to traverse it from sysfs.

Signed-off-by: Bartosz Golaszewski 
Reviewed-by: Linus Walleij 
Acked-by: Andy Shevchenko