kernel/linux.git/drivers/gpio/gpio-eic-sprd.c, branch linux-7.1.y

treewide: rename GPIO set callbacks back to their original names

2025-08-07T08:07:06+00:00

The conversion of all GPIO drivers to using the .set_rv() and .set_multiple_rv() callbacks from struct gpio_chip (which - unlike their predecessors - return an integer and allow the controller drivers to indicate failures to users) is now complete and the legacy ones have been removed. Rename the new callbacks back to their original names in one sweeping change. Signed-off-by: Bartosz Golaszewski

gpio: eic-sprd: use new line value setter callbacks

2025-04-16T15:52:42+00:00

struct gpio_chip now has callbacks for setting line values that return an integer, allowing to indicate failures. Convert the driver to using them. Signed-off-by: Bartosz Golaszewski Link: https://lore.kernel.org/r/20250407-gpiochip-set-rv-gpio-part1-v1-2-78399683ca38@linaro.org Signed-off-by: Bartosz Golaszewski

gpio: eic-sprd: use generic device_get_match_data()

2024-10-14T08:28:56+00:00

There's no need to use the OF-specific variant to get the match data. Switch to using device_get_match_data() instead. Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20241007102859.35602-1-brgl@bgdev.pl Signed-off-by: Bartosz Golaszewski

Merge tag 'v6.8-rc4' into gpio/for-next

2024-02-12T09:12:41+00:00

Linux 6.8-rc4 Pulling this for a bugfix upstream with which the gpio/for-next branch conflicts.

gpio: eic-sprd: Clear interrupt after set the interrupt type

2024-01-22T10:38:08+00:00

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 Signed-off-by: Wenhua Lin Signed-off-by: Bartosz Golaszewski

gpio: eic-sprd: Optimize the calculation method of eic number

2024-01-22T10:37:59+00:00

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 Acked-by: Chunyan Zhang Signed-off-by: Bartosz Golaszewski

gpio: eic-sprd: use a helper variable for &pdev->dev

2023-09-13T12:13:32+00:00

Instead of dereferencing pdev everywhere, just store the address of the underlying struct device in a local variable. Signed-off-by: Bartosz Golaszewski Reviewed-by: Baolin Wang

gpio: eic-sprd: unregister from the irq notifier on remove()

2023-09-13T12:13:06+00:00

This is a tristate module, it can be unloaded. We need to cleanup properly and unregister from the interrupt notifier on driver detach. Fixes: b32415652a4d ("gpio: eic-sprd: use atomic notifiers to notify all chips about irqs") Signed-off-by: Bartosz Golaszewski Reviewed-by: Baolin Wang

gpio: eic-sprd: use atomic notifiers to notify all chips about irqs

2023-09-11T09:17:06+00:00

Calling gpiochip_find() from interrupt handler in this driver is an abuse of the GPIO API. It only happens to work because nobody added a might_sleep() to it and the lock used by GPIOLIB is a spinlock. Both will soon be changed as we're limiting both the number of interfaces allowed to be called from atomic context as well as making struct gpio_chip private to the GPIO code that owns it. We'll also switch to protecting the global GPIO device list with a mutex as there is no reason to allow changes to it from interrupt handlers. Instead of iterating over all SPRD chips and looking up each corresponding GPIO chip, let's make each SPRD GPIO controller register with a notifier chain. The chain will be called at interrupt so that every chip that already probed will be notified. The rest of the interrupt handling remains the same. This should result in faster code as we're avoiding iterating over the list of all GPIO devices. Signed-off-by: Bartosz Golaszewski Reviewed-by: Chunyan Zhang Tested-by: Wenhua Lin

gpio: eic-sprd: remove unneeded platform_set_drvdata() call

2023-07-29T14:07:04+00:00

The platform_set_drvdata() call was never used, ever since the driver was originally added. It looks like this copy+paste left-over. Possibly the author copied from a driver that had this line, but also had a remove hook. Reviewed-by: Alexandru Ardelean Signed-off-by: Andrei Coardos Reviewed-by: Andy Shevchenko Reviewed-by: Baolin Wang Signed-off-by: Bartosz Golaszewski