summaryrefslogtreecommitdiff
path: root/drivers/gpio
AgeCommit message (Collapse)AuthorFilesLines
2024-02-16gpio: cdev: fix a NULL-pointer dereference with DEBUG enabledBartosz Golaszewski1-2/+2
We are actually passing the gc pointer to chip_dbg() so we have to srcu_dereference() it. Fixes: 8574b5b47610 ("gpio: cdev: use correct pointer accessors with SRCU") Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Closes: https://lore.kernel.org/lkml/179caa10-5f86-4707-8bb0-fe1b316326d6@samsung.com/ Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
2024-02-15gpio: sysfs: fix inverted pointer logicBartosz Golaszewski1-1/+1
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 <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/linux-gpio/15671341-0b29-40e0-b487-0a4cdc414d8e@moroto.mountain/ Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-02-15gpio: don't let lockdep complain about inherently dangerous RCU usageBartosz Golaszewski1-2/+3
There are two legacy, deprecated functions - gpiod_to_chip() and gpio_device_get_chip() - that still have users in tree. They return the address of the SRCU-protected chip outside of the read-only critical sections. They are inherently dangerous and the users should convert to safer alternatives. Let's explicitly silence lockdep warnings by using rcu_dereference_check(ptr, 1). While at it: reuse gpio_device_get_chip() in gpiod_to_chip(). Fixes: d83cee3d2bb1 ("gpio: protect the pointer to gpio_chip in gpio_device with SRCU") Reported-by: kernel test robot <oliver.sang@intel.com> Closes: https://lore.kernel.org/oe-lkp/202402122234.d85cca9b-lkp@intel.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-02-15gpio: use srcu_dereference() with SRCU-protected pointersBartosz Golaszewski3-11/+13
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 <oliver.sang@intel.com> Closes: https://lore.kernel.org/oe-lkp/202402122234.d85cca9b-lkp@intel.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Acked-by: Paul E. McKenney <paulmck@kernel.org>
2024-02-15gpio: cdev: use correct pointer accessors with SRCUBartosz Golaszewski1-13/+12
We never dereference the chip pointer in character device code so we can use the lighter rcu_access_pointer() helper. This also makes lockep happier as it no longer complains about suspicious rcu_dereference() usage. Fixes: d83cee3d2bb1 ("gpio: protect the pointer to gpio_chip in gpio_device with SRCU") Reported-by: kernel test robot <oliver.sang@intel.com> Closes: https://lore.kernel.org/oe-lkp/202402122234.d85cca9b-lkp@intel.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Paul E. McKenney <paulmck@kernel.org>
2024-02-15gpio: take the SRCU read lock in gpiod_hog()Bartosz Golaszewski1-4/+7
gpiod_hog() may be called without the gpio_device SRCU read lock taken so we need to do it here as well. It's alright if someone else is already holding the lock as SRCU read critical sections can be nested. Fixes: d83cee3d2bb1 ("gpio: protect the pointer to gpio_chip in gpio_device with SRCU") Reported-by: kernel test robot <oliver.sang@intel.com> Closes: https://lore.kernel.org/oe-lkp/202402122234.d85cca9b-lkp@intel.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Paul E. McKenney <paulmck@kernel.org>
2024-02-14gpio: initialize descriptor SRCU structure before adding OF-based chipsBartosz Golaszewski1-9/+9
In certain situations we may end up taking the GPIO descriptor SRCU read lock in of_gpiochip_add() before the SRCU struct is initialized. Move the initialization before the call to of_gpiochip_add(). Fixes: be711caa87c5 ("gpio: add SRCU infrastructure to struct gpio_desc") Fixes: 1f2bcb8c8ccd ("gpio: protect the descriptor label with SRCU") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-lkp/202402122228.e607a080-lkp@intel.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-02-12gpio: mark unsafe gpio_chip manipulators as deprecatedBartosz Golaszewski1-0/+6
We still have some functions that return the address of the GPIO chip associated with the GPIO device. This is dangerous and the users should find a better solution. Let's add appropriate comments to the kernel docs. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2024-02-12gpio: remove the RW semaphore from the GPIO deviceBartosz Golaszewski2-9/+0
With all accesses to gdev->chip being protected with SRCU, we can now remove the RW-semaphore specific to the character device which fulfilled the same role up to this point. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2024-02-12gpio: protect the pointer to gpio_chip in gpio_device with SRCUBartosz Golaszewski4-129/+271
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 <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2024-02-12gpio: add SRCU infrastructure to struct gpio_deviceBartosz Golaszewski2-3/+12
Add the SRCU struct to GPIO device. It will be used to serialize access to the GPIO chip pointer. Initialize and clean it up where applicable. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2024-02-12gpio: add the can_sleep flag to struct gpio_deviceBartosz Golaszewski2-5/+9
Duplicating the can_sleep value in GPIO device will allow us to not needlessly dereference the chip pointer in several places and reduce the number of SRCU read-only critical sections. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2024-02-12gpio: remove unnecessary checks from gpiod_to_chip()Bartosz Golaszewski1-2/+2
We don't need to check the gdev pointer in struct gpio_desc - it's always assigned and never cleared. It's also pointless to check gdev->chip before we actually serialize access to it. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2024-02-12gpio: reduce the functionality of validate_desc()Bartosz Golaszewski1-15/+3
Checking desc->gdev->chip for NULL without holding it in place with some serializing mechanism is pointless. Remove this check. Also don't check desc->gdev for NULL as it can never happen. We'll be protecting gdev->chip with SRCU soon but we will provide a dedicated, automatic class for that. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2024-02-12gpio: don't dereference gdev->chip in gpiochip_setup_dev()Bartosz Golaszewski1-1/+1
We don't need to dereference gdev->chip in gpiochip_setup_dev() as at the time it's called, the label in the associated struct gpio_device is already set. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2024-02-12gpio: sysfs: don't access gdev->chip if it's not neededBartosz Golaszewski1-3/+3
Don't dereference gdev->chip if the same information can be obtained from struct gpio_device. Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2024-02-12gpio: cdev: don't access gdev->chip if it's not neededBartosz Golaszewski1-1/+1
The variable holding the number of GPIO lines is duplicated in GPIO device so read it instead of unnecessarily dereferencing the chip pointer. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2024-02-12gpio: cdev: replace gpiochip_get_desc() with gpio_device_get_desc()Bartosz Golaszewski1-5/+5
gpio_device_get_desc() is the safer alternative to gpiochip_get_desc(). As we don't really need to dereference the chip pointer to retrieve the descriptors in character device code, let's use it. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2024-02-12gpio: sysfs: pass the GPIO device - not chip - to sysfs callbacksBartosz Golaszewski1-7/+7
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 <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2024-02-12gpio: sysfs: extend the critical section for unregistering sysfs devicesBartosz Golaszewski1-7/+8
Checking the gdev->mockdev pointer for NULL must be part of the critical section. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2024-02-12gpio: remove unneeded code from gpio_device_get_desc()Bartosz Golaszewski1-10/+0
The GPIO chip pointer is unused. Let's remove it. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2024-02-12gpio: reinforce desc->flags handlingBartosz Golaszewski1-17/+25
We now removed the gpio_lock spinlock and modified the places previously protected by it to handle desc->flags access in a consistent way. Let's improve other places that were previously unprotected by reading the flags field of gpio_desc once and using the stored value for logic consistency. If we need to modify the field, let's also write it back once with a consistent value resulting from the function's logic. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2024-02-12gpio: remove gpio_lockBartosz Golaszewski4-98/+47
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 <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2024-02-12gpio: sysfs: use gpio_device_find() to iterate over existing devicesBartosz Golaszewski3-25/+24
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 <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2024-02-12gpio: protect the descriptor label with SRCUBartosz Golaszewski3-30/+61
In order to ensure that the label is not freed while it's being accessed, let's protect it with SRCU and synchronize it everytime it's changed. Let's modify desc_set_label() to manage the memory used for the label as it can only be freed once synchronize_srcu() returns. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2024-02-12gpio: add SRCU infrastructure to struct gpio_descBartosz Golaszewski2-2/+19
Extend the GPIO descriptor with an SRCU structure in order to serialize the access to the label. Initialize and clean it up where applicable. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2024-02-12gpio: don't set label from irq helpersBartosz Golaszewski1-13/+8
We will soon serialize access to the descriptor label using SRCU. The write-side of the protection will require calling synchronize_srcu() which must not be called from atomic context. We have two irq helpers: gpiochip_lock_as_irq() and gpiochip_unlock_as_irq() that set the label if the GPIO is not requested but is being used as interrupt. They are called with a spinlock held from the interrupt subsystem. They must not do it if we are to use SRCU so instead let's move the special corner case to a dedicated getter. Don't actually set the label to "interrupt" in the above case but rather use the newly added gpiod_get_label() helper to hide the logic that atomically checks the descriptor flags and returns the address of a static "interrupt" string. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2024-02-12gpio: provide and use gpiod_get_label()Bartosz Golaszewski3-4/+10
We will soon serialize access to the descriptor label using SRCU. The write-side of the protection will require calling synchronize_srcu() which must not be called from atomic context. We have two irq helpers: gpiochip_lock_as_irq() and gpiochip_unlock_as_irq() that set the label if the GPIO is not requested but is being used as interrupt. They are called with a spinlock held from the interrupt subsystem. They must not do it if we are to use SRCU so instead let's move the special corner case to a dedicated getter. First: let's implement and use the getter where it's applicable. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2024-02-12gpio: remove unused logging helpersBartosz Golaszewski1-13/+0
The general rule of the kernel is to not provide symbols that have no users upstream. Let's remove logging helpers that are not used anywhere. This will save us work later when we'll be modifying them to use the upcoming SRCU infrastructure. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2024-02-12gpio: of: assign and read the hog pointer atomicallyBartosz Golaszewski2-3/+3
The device nodes representing GPIO hogs cannot be deleted without unregistering the GPIO chip so there's no need to serialize their access. However we must ensure that users can get the right address so write and read it atomically. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2024-02-12gpio: protect the list of GPIO devices with SRCUBartosz Golaszewski1-112/+135
We're working towards removing the "multi-function" GPIO spinlock that's implemented terribly wrong. We tried using an RW-semaphore to protect the list of GPIO devices but it turned out that we still have old code using legacy GPIO calls that need to translate the global GPIO number to the address of the associated descriptor and - to that end - traverse the list while holding the lock. If we change the spinlock to a sleeping lock then we'll end up with "scheduling while atomic" bugs. Let's allow lockless traversal of the list using SRCU and only use the mutex when modyfing the list. While at it: let's protect the period between when we start the lookup and when we finally request the descriptor (increasing the reference count of the GPIO device) with the SRCU read lock. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2024-02-12gpio: constify opaque pointer in gpio_device_find() match functionKrzysztof Kozlowski3-7/+8
The match function used in gpio_device_find() should not modify the contents of passed opaque pointer, because such modification would not be necessary for actual matching and it could lead to quite unreadable, spaghetti code. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> [Bartosz: fix coding style in header] Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-02-12Merge tag 'v6.8-rc4' into gpio/for-nextBartosz Golaszewski3-8/+46
Linux 6.8-rc4 Pulling this for a bugfix upstream with which the gpio/for-next branch conflicts.
2024-02-08gpio: set device type for GPIO chipsBartosz Golaszewski1-4/+9
It's useful to have the device type information for those sub-devices that are actually GPIO chips registered with GPIOLIB. While at it: use the device type struct to setup the release callback which is the preferred way to use the device API. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-02-08gpio: remove GPIO device from the list unconditionally in error pathBartosz Golaszewski1-4/+4
Since commit 48e1b4d369cf ("gpiolib: remove the GPIO device from the list when it's unregistered") we remove the GPIO device entry from the global list (used to order devices by their GPIO ranges) when unregistering the chip, not when releasing the device. It will not happen when the last reference is put anymore. This means, we need to remove it in error path in gpiochip_add_data_with_key() unconditionally, without checking if the device's .release() callback is set. Fixes: 48e1b4d369cf ("gpiolib: remove the GPIO device from the list when it's unregistered") Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-02-05gpio: gpiolib: make gpio_bus_type constRicardo B. Marliere1-1/+1
Now that the driver core can properly handle constant struct bus_type, move the gpio_bus_type variable to be a constant structure as well, placing it into read-only memory which can not be modified at runtime. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ricardo B. Marliere <ricardo@marliere.net> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-02-02gpio: vf610: enable COMPILE_TESTMartin Kaiser1-1/+1
Enable COMPILE_TEST for the vf610 gpio driver to support test builds on systems without this hardware. Signed-off-by: Martin Kaiser <martin@kaiser.cx> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-02-02gpio: vf610: allow disabling the vf610 driverMartin Kaiser1-1/+2
The vf610 gpio driver is enabled by default for all i.MX machines, without any option to disable it in a board-specific config file. Most i.MX chipsets have no hardware for this driver. Change the default to enable GPIO_VF610 for SOC_VF610 and disable it otherwise. Add a text description after the bool type, this makes the driver selectable by make config etc. Fixes: 30a35c07d9e9 ("gpio: vf610: drop the SOC_VF610 dependency for GPIO_VF610") Signed-off-by: Martin Kaiser <martin@kaiser.cx> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-01-29gpio: unexport GPIO irq domain functions only used internallyBartosz Golaszewski1-51/+42
There are no external users for the irq domain helpers so unexport them and remove the prototypes from the driver header. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-01-29gpio: cdev: remove leftover function pointer typedefsBartosz Golaszewski1-5/+0
The locking wrappers were replaces with lock guards. These typedefs are no longer needed. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Kent Gibson <warthog618@gmail.com>
2024-01-22gpio: eic-sprd: Clear interrupt after set the interrupt typeWenhua Lin1-4/+28
The raw interrupt status of eic maybe set before the interrupt is enabled, since the eic interrupt has a latch function, which would trigger the interrupt event once enabled it from user side. To solve this problem, interrupts generated before setting the interrupt trigger type are ignored. Fixes: 25518e024e3a ("gpio: Add Spreadtrum EIC driver support") Acked-by: Chunyan Zhang <zhang.lyra@gmail.com> Signed-off-by: Wenhua Lin <Wenhua.Lin@unisoc.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-01-22gpio: eic-sprd: Optimize the calculation method of eic numberWenhua Lin1-6/+4
The num_eics is a default value, but some SoCs support more than 8. In order to adapt to all projects, the total number of eics is automatically calculated through dts. Signed-off-by: Wenhua Lin <Wenhua.Lin@unisoc.com> Acked-by: Chunyan Zhang <zhang.lyra@gmail.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-01-22gpiolib: acpi: Ignore touchpad wakeup on GPD G1619-04Mario Limonciello1-0/+14
Spurious wakeups are reported on the GPD G1619-04 which can be absolved by programming the GPIO to ignore wakeups. Cc: stable@vger.kernel.org Reported-and-tested-by: George Melikov <mail@gmelikov.ru> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3073 Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-01-22gpio: legacy: mark old interfaces as deprecated in kernel docsBartosz Golaszewski2-0/+14
We've recently had someone try to use of_get_named_gpio() in new code. Mark legacy interfaces as deprecated in kernel docs to avoid any confusion. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-01-18Merge tag 'gpio-fixes-for-v6.8-rc1' of ↵Linus Torvalds7-98/+111
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux Pull gpio fixes from Bartosz Golaszewski: "Apart from some regular driver fixes there's a relatively big revert of the locking changes that were introduced to GPIOLIB in this merge window. This is because it turned out that some legacy GPIO interfaces - that need to translate a number from the global GPIO numberspace to the address of the relevant descriptor, thus running a GPIO device lookup and taking the GPIO device list lock - are still used in old code from atomic context resulting in "scheduling while atomic" errors. I'll try to make the read-only part of the list access entirely lockless using SRCU but this will take some time so let's go back to the old global spinlock for now. Summary: - revert the changes aiming to use a read-write semaphore to protect the list of GPIO devices due to calls to legacy API taking that lock from atomic context in old code - fix inverted logic in DEFINE_FREE() for GPIO device references - check the return value of bgpio_init() in gpio-mlxbf3 - fix node address in the DT bindings example for gpio-xilinx - fix signedness bug in gpio-rtd - fix kernel-doc warnings in gpio-en7523" * tag 'gpio-fixes-for-v6.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: gpiolib: revert the attempt to protect the GPIO device list with an rwsem gpio: EN7523: fix kernel-doc warnings gpiolib: Fix scope-based gpio_device refcounting gpio: mlxbf3: add an error code check in mlxbf3_gpio_probe dt-bindings: gpio: xilinx: Fix node address in gpio gpio: rtd: Fix signedness bug in probe
2024-01-18Merge tag 'backlight-next-6.8' of ↵Linus Torvalds1-2/+2
git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight Pull backlight updates from Lee Jones: "New Drivers: - Add support for Monolithic Power Systems MP3309C WLED Step-up Converter Fix-ups: - Use/convert to new/better APIs/helpers/MACROs instead of hand-rolling implementations - Device Tree Binding updates - Demote non-kerneldoc header comments - Improve error handling; return proper error values, simplify, avoid duplicates, etc - Convert over to the new (kinda) GPIOD API Bug Fixes: - Fix uninitialised local variable" * tag 'backlight-next-6.8' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight: backlight: hx8357: Convert to agnostic GPIO API backlight: ili922x: Add an error code check in ili922x_write() backlight: ili922x: Drop kernel-doc for local macros backlight: mp3309c: Fix uninitialized local variable backlight: pwm_bl: Use dev_err_probe backlight: mp3309c: Add support for MPS MP3309C dt-bindings: backlight: mp3309c: Remove two required properties
2024-01-17gpiolib: revert the attempt to protect the GPIO device list with an rwsemBartosz Golaszewski4-89/+97
This reverts commits 1979a2807547 ("gpiolib: replace the GPIO device mutex with a read-write semaphore") and 65a828bab158 ("gpiolib: use a mutex to protect the list of GPIO devices"). Unfortunately the legacy GPIO API that's still used in older code has to translate numbers from the global GPIO numberspace to descriptors. This results in a GPIO device lookup in every call to legacy functions. Some of those functions - like gpio_set/get_value() - can be called from atomic context so taking a sleeping lock that is an RW semaphore results in an error. We'll probably have to protect this list with SRCU. Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/linux-wireless/f7b5ff1e-8f34-4d98-a7be-b826cb897dc8@moroto.mountain/ Fixes: 1979a2807547 ("gpiolib: replace the GPIO device mutex with a read-write semaphore") Fixes: 65a828bab158 ("gpiolib: use a mutex to protect the list of GPIO devices") Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-01-15gpio: EN7523: fix kernel-doc warningsRandy Dunlap1-3/+3
Add "struct" keyword and explain the @dir array differently to prevent kernel-doc warnings: gpio-en7523.c:22: warning: cannot understand function prototype: 'struct airoha_gpio_ctrl ' gpio-en7523.c:27: warning: Function parameter or struct member 'dir' not described in 'airoha_gpio_ctrl' gpio-en7523.c:27: warning: Excess struct member 'dir0' description in 'airoha_gpio_ctrl' gpio-en7523.c:27: warning: Excess struct member 'dir1' description in 'airoha_gpio_ctrl' Fixes: 0868ad385aff ("gpio: Add support for Airoha EN7523 GPIO controller") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-01-15gpio: mlxbf3: add an error code check in mlxbf3_gpio_probeSu Hui1-0/+2
Clang static checker warning: Value stored to 'ret' is never read. bgpio_init() returns error code if failed, it's better to add this check. Fixes: cd33f216d241 ("gpio: mlxbf3: Add gpio driver support") Signed-off-by: Su Hui <suhui@nfschina.com> [Bartosz: add the Fixes: tag] Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-01-15gpio: rtd: Fix signedness bug in probeDan Carpenter1-6/+9
The "data->irqs[]" array holds unsigned int so this error handling will not work correctly. Fixes: eee636bff0dc ("gpio: rtd: Add support for Realtek DHC(Digital Home Center) RTD SoCs") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
generated by cgit v1.2.3 (git 2.25.1) at 2025-05-14 08:32:34 +0000