summaryrefslogtreecommitdiff
path: root/drivers/gpio
AgeCommit message (Collapse)AuthorFilesLines
2022-04-27gpio: Request interrupts after IRQ is initializedMario Limonciello1-2/+2
commit 06fb4ecfeac7e00d6704fa5ed19299f2fefb3cc9 upstream. Commit 5467801f1fcb ("gpio: Restrict usage of GPIO chip irq members before initialization") attempted to fix a race condition that lead to a NULL pointer, but in the process caused a regression for _AEI/_EVT declared GPIOs. This manifests in messages showing deferred probing while trying to allocate IRQs like so: amd_gpio AMDI0030:00: Failed to translate GPIO pin 0x0000 to IRQ, err -517 amd_gpio AMDI0030:00: Failed to translate GPIO pin 0x002C to IRQ, err -517 amd_gpio AMDI0030:00: Failed to translate GPIO pin 0x003D to IRQ, err -517 [ .. more of the same .. ] The code for walking _AEI doesn't handle deferred probing and so this leads to non-functional GPIO interrupts. Fix this issue by moving the call to `acpi_gpiochip_request_interrupts` to occur after gc->irc.initialized is set. Fixes: 5467801f1fcb ("gpio: Restrict usage of GPIO chip irq members before initialization") Link: https://lore.kernel.org/linux-gpio/BL1PR12MB51577A77F000A008AA694675E2EF9@BL1PR12MB5157.namprd12.prod.outlook.com/ Link: https://bugzilla.suse.com/show_bug.cgi?id=1198697 Link: https://bugzilla.kernel.org/show_bug.cgi?id=215850 Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1979 Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1976 Reported-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Shreeya Patel <shreeya.patel@collabora.com> Tested-By: Samuel Čavoj <samuel@cavoj.net> Tested-By: lukeluk498@gmail.com Link: Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-and-tested-by: Takashi Iwai <tiwai@suse.de> Cc: Shreeya Patel <shreeya.patel@collabora.com> Cc: stable@vger.kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-20gpiolib: acpi: use correct format charactersLinus Torvalds1-2/+2
[ Upstream commit 213d266ebfb1621aab79cfe63388facc520a1381 ] When compiling with -Wformat, clang emits the following warning: gpiolib-acpi.c:393:4: warning: format specifies type 'unsigned char' but the argument has type 'int' [-Wformat] pin); ^~~ So warning that '%hhX' is paired with an 'int' is all just completely mindless and wrong. Sadly, I can see a different bogus warning reason why people would want to use '%02hhX'. Again, the *sane* thing from a human perspective is to use '%02X. But if the compiler doesn't do any range analysis at all, it could decide that "Oh, that print format could need up to 8 bytes of space in the result". Using '%02hhX' would cut that down to two. And since we use char ev_name[5]; and currently use "_%c%02hhX" as the format string, even a compiler that doesn't notice that "pin <= 255" test that guards this all will go "OK, that's at most 4 bytes and the final NUL termination, so it's fine". While a compiler - like gcc - that only sees that the original source of the 'pin' value is a 'unsigned short' array, and then doesn't take the "pin <= 255" into account, will warn like this: gpiolib-acpi.c: In function 'acpi_gpiochip_request_interrupt': gpiolib-acpi.c:206:24: warning: '%02X' directive writing between 2 and 4 bytes into a region of size 3 [-Wformat-overflow=] sprintf(ev_name, "_%c%02X", ^~~~ gpiolib-acpi.c:206:20: note: directive argument in the range [0, 65535] because gcc isn't being very good at that argument range analysis either. In other words, the original use of 'hhx' was bogus to begin with, and due to *another* compiler warning being bad, and we had that bad code being written back in 2016 to work around _that_ compiler warning (commit e40a3ae1f794: "gpio: acpi: work around false-positive -Wstring-overflow warning"). Sadly, two different bad compiler warnings together does not make for one good one. It just makes for even more pain. End result: I think the simplest and cleanest option is simply the proposed change which undoes that '%hhX' change for gcc, and replaces it with just using a slightly bigger stack allocation. It's not like a 5-byte allocation is in any way likely to have saved any actual stack, since all the other variables in that function are 'int' or bigger. False-positive compiler warnings really do make people write worse code, and that's a problem. But on a scale of bad code, I feel that extending the buffer trivially is better than adding a pointless cast that literally makes no sense. At least in this case the end result isn't unreadable or buggy. We've had several cases of bad compiler warnings that caused changes that were actually horrendously wrong. Fixes: e40a3ae1f794 ("gpio: acpi: work around false-positive -Wstring-overflow warning") Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-04-13gpio: Restrict usage of GPIO chip irq members before initializationShreeya Patel1-0/+19
commit 5467801f1fcbdc46bc7298a84dbf3ca1ff2a7320 upstream. GPIO chip irq members are exposed before they could be completely initialized and this leads to race conditions. One such issue was observed for the gc->irq.domain variable which was accessed through the I2C interface in gpiochip_to_irq() before it could be initialized by gpiochip_add_irqchip(). This resulted in Kernel NULL pointer dereference. Following are the logs for reference :- kernel: Call Trace: kernel: gpiod_to_irq+0x53/0x70 kernel: acpi_dev_gpio_irq_get_by+0x113/0x1f0 kernel: i2c_acpi_get_irq+0xc0/0xd0 kernel: i2c_device_probe+0x28a/0x2a0 kernel: really_probe+0xf2/0x460 kernel: RIP: 0010:gpiochip_to_irq+0x47/0xc0 To avoid such scenarios, restrict usage of GPIO chip irq members before they are completely initialized. Signed-off-by: Shreeya Patel <shreeya.patel@collabora.com> Cc: stable@vger.kernel.org Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-08Revert "gpio: Revert regression in sysfs-gpio (gpiolib.c)"Bartosz Golaszewski1-0/+10
[ Upstream commit 56e337f2cf1326323844927a04e9dbce9a244835 ] This reverts commit fc328a7d1fcce263db0b046917a66f3aa6e68719. This commit - while attempting to fix a regression - has caused a number of other problems. As the fallout from it is more significant than the initial problem itself, revert it for now before we find a correct solution. Link: https://lore.kernel.org/all/20220314192522.GA3031157@roeck-us.net/ Link: https://lore.kernel.org/stable/20220314155509.552218-1-michael@walle.cc/ Link: https://lore.kernel.org/all/20211217153555.9413-1-marcelo.jimenez@gmail.com/ Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> Reported-and-bisected-by: Guenter Roeck <linux@roeck-us.net> Reported-by: Michael Walle <michael@walle.cc> Cc: Thorsten Leemhuis <linux@leemhuis.info> Cc: Marcelo Roberto Jimenez <marcelo.jimenez@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-04-08gpio: Revert regression in sysfs-gpio (gpiolib.c)Marcelo Roberto Jimenez1-10/+0
[ Upstream commit fc328a7d1fcce263db0b046917a66f3aa6e68719 ] Some GPIO lines have stopped working after the patch commit 2ab73c6d8323f ("gpio: Support GPIO controllers without pin-ranges") And this has supposedly been fixed in the following patches commit 89ad556b7f96a ("gpio: Avoid using pin ranges with !PINCTRL") commit 6dbbf84603961 ("gpiolib: Don't free if pin ranges are not defined") But an erratic behavior where some GPIO lines work while others do not work has been introduced. This patch reverts those changes so that the sysfs-gpio interface works properly again. Signed-off-by: Marcelo Roberto Jimenez <marcelo.jimenez@gmail.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-03-16gpio: Return EPROBE_DEFER if gc->to_irq is NULLShreeya Patel1-0/+10
[ Upstream commit ae42f9288846353982e2eab181fb41e7fd8bf60f ] We are racing the registering of .to_irq when probing the i2c driver. This results in random failure of touchscreen devices. Following explains the race condition better. [gpio driver] gpio driver registers gpio chip [gpio consumer] gpio is acquired [gpio consumer] gpiod_to_irq() fails with -ENXIO [gpio driver] gpio driver registers irqchip gpiod_to_irq works at this point, but -ENXIO is fatal We could see the following errors in dmesg logs when gc->to_irq is NULL [2.101857] i2c_hid i2c-FTS3528:00: HID over i2c has not been provided an Int IRQ [2.101953] i2c_hid: probe of i2c-FTS3528:00 failed with error -22 To avoid this situation, defer probing until to_irq is registered. Returning -EPROBE_DEFER would be the first step towards avoiding the failure of devices due to the race in registration of .to_irq. Final solution to this issue would be to avoid using gc irq members until they are fully initialized. This issue has been reported many times in past and people have been using workarounds like changing the pinctrl_amd to built-in instead of loading it as a module or by adding a softdep for pinctrl_amd into the config file. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=209413 Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Shreeya Patel <shreeya.patel@collabora.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-03-16gpio: ts4900: Do not set DAT and OE togetherMark Featherston1-5/+19
[ Upstream commit 03fe003547975680fdb9ff5ab0e41cb68276c4f2 ] This works around an issue with the hardware where both OE and DAT are exposed in the same register. If both are updated simultaneously, the harware makes no guarantees that OE or DAT will actually change in any given order and may result in a glitch of a few ns on a GPIO pin when changing direction and value in a single write. Setting direction to input now only affects OE bit. Setting direction to output updates DAT first, then OE. Fixes: 9c6686322d74 ("gpio: add Technologic I2C-FPGA gpio support") Signed-off-by: Mark Featherston <mark@embeddedTS.com> Signed-off-by: Kris Bahnsen <kris@embeddedTS.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-03-16gpiolib: acpi: Convert ACPI value of debounce to microsecondsAndy Shevchenko2-2/+14
[ Upstream commit 660c619b9d7ccd28648ee3766cdbe94ec7b27402 ] It appears that GPIO ACPI library uses ACPI debounce values directly. However, the GPIO library APIs expect the debounce timeout to be in microseconds. Convert ACPI value of debounce to microseconds. While at it, document this detail where it is appropriate. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=215664 Reported-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Fixes: 8dcb7a15a585 ("gpiolib: acpi: Take into account debounce settings") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-03-02gpio: tegra186: Fix chip_data type confusionMarc Zyngier1-4/+10
commit d1e972ace42390de739cde87d96043dcbe502286 upstream. The tegra186 GPIO driver makes the assumption that the pointer returned by irq_data_get_irq_chip_data() is a pointer to a tegra_gpio structure. Unfortunately, it is actually a pointer to the inner gpio_chip structure, as mandated by the gpiolib infrastructure. Nice try. The saving grace is that the gpio_chip is the first member of tegra_gpio, so the bug has gone undetected since... forever. Fix it by performing a container_of() on the pointer. This results in no additional code, and makes it possible to understand how the whole thing works. Fixes: 5b2b135a87fc ("gpio: Add Tegra186 support") Signed-off-by: Marc Zyngier <maz@kernel.org> Cc: Thierry Reding <treding@nvidia.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com> Link: https://lore.kernel.org/r/20220211093904.1112679-1-maz@kernel.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-02gpio: rockchip: Reset int_bothedge when changing triggerSamuel Holland1-27/+29
[ Upstream commit 7920af5c826cb4a7ada1ae26fdd317642805adc2 ] With v2 hardware, an IRQ can be configured to trigger on both edges via a bit in the int_bothedge register. Currently, the driver sets this bit when changing the trigger type to IRQ_TYPE_EDGE_BOTH, but fails to reset this bit if the trigger type is later changed to something else. This causes spurious IRQs, and when using gpio-keys with wakeup-event-action set to EV_ACT_(DE)ASSERTED, those IRQs translate into spurious wakeups. Fixes: 3bcbd1a85b68 ("gpio/rockchip: support next version gpio controller") Reported-by: Guillaume Savaton <guillaume@baierouge.fr> Tested-by: Guillaume Savaton <guillaume@baierouge.fr> Signed-off-by: Samuel Holland <samuel@sholland.org> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-02-16gpio: sifive: use the correct register to read output valuesNiklas Cassel1-1/+1
[ Upstream commit cc38ef936840ac29204d806deb4d1836ec509594 ] Setting the output of a GPIO to 1 using gpiod_set_value(), followed by reading the same GPIO using gpiod_get_value(), will currently yield an incorrect result. This is because the SiFive GPIO device stores the output values in reg_set, not reg_dat. Supply the flag BGPIOF_READ_OUTPUT_REG_SET to bgpio_init() so that the generic driver reads the correct register. Fixes: 96868dce644d ("gpio/sifive: Add GPIO driver for SiFive SoCs") Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> [Bartosz: added the Fixes tag] Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-02-16gpiolib: Never return internal error codes to user spaceAndy Shevchenko3-8/+17
[ Upstream commit 95a4eed7dd5b7c1c3664a626174290686ddbee9f ] Currently it's possible that character device interface may return the error codes which are not supposed to be seen by user space. In this case it's EPROBE_DEFER. Wrap it to return -ENODEV instead as sysfs does. Fixes: d7c51b47ac11 ("gpio: userspace ABI for reading/writing GPIO lines") Fixes: 61f922db7221 ("gpio: userspace ABI for reading GPIO line events") Fixes: 3c0d9c635ae2 ("gpiolib: cdev: support GPIO_V2_GET_LINE_IOCTL and GPIO_V2_LINE_GET_VALUES_IOCTL") Reported-by: Suresh Balakrishnan <suresh.balakrishnan@intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-02-16gpio: aggregator: Fix calling into sleeping GPIO controllersGeert Uytterhoeven1-4/+14
[ Upstream commit 2cba05451a6d0c703bb74f1a250691404f27c4f1 ] If the parent GPIO controller is a sleeping controller (e.g. a GPIO controller connected to I2C), getting or setting a GPIO triggers a might_sleep() warning. This happens because the GPIO Aggregator takes the can_sleep flag into account only for its internal locking, not for calling into the parent GPIO controller. Fix this by using the gpiod_[gs]et*_cansleep() APIs when calling into a sleeping GPIO controller. Reported-by: Mikko Salomäki <ms@datarespons.se> Fixes: 828546e24280f721 ("gpio: Add GPIO Aggregator") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-02-08gpio: mpc8xxx: Fix an ignored error return from platform_get_irq()Yang Li1-1/+1
commit 9f51ce0b9e73f83bab2442b36d5e247a81bd3401 upstream. The return from the call to platform_get_irq() is int, it can be a negative error code, however this is being assigned to an unsigned int variable 'irqn', so making 'irqn' an int. Eliminate the following coccicheck warning: ./drivers/gpio/gpio-mpc8xxx.c:391:5-21: WARNING: Unsigned expression compared with zero: mpc8xxx_gc -> irqn < 0 Reported-by: Abaci Robot <abaci@linux.alibaba.com> Fixes: 0b39536cc699 ("gpio: mpc8xxx: Fix IRQ check in mpc8xxx_probe") Signed-off-by: Yang Li <yang.lee@linux.alibaba.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-08gpio: idt3243x: Fix an ignored error return from platform_get_irq()Yang Li1-1/+1
commit 7c1cf55577782725ea2bc24687767c8fe8e57486 upstream. The return from the call to platform_get_irq() is int, it can be a negative error code, however this is being assigned to an unsigned int variable 'parent_irq', so making 'parent_irq' an int. Eliminate the following coccicheck warning: ./drivers/gpio/gpio-idt3243x.c:167:6-16: WARNING: Unsigned expression compared with zero: parent_irq < 0 Reported-by: Abaci Robot <abaci@linux.alibaba.com> Fixes: 30fee1d7462a ("gpio: idt3243x: Fix IRQ check in idt_gpio_probe") Signed-off-by: Yang Li <yang.lee@linux.alibaba.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-01-27gpio: idt3243x: Fix IRQ check in idt_gpio_probeMiaoqian Lin1-2/+2
commit 30fee1d7462a446ade399c0819717a830cbdca69 upstream. platform_get_irq() returns negative error number instead 0 on failure. And the doc of platform_get_irq() provides a usage example: int irq = platform_get_irq(pdev, 0); if (irq < 0) return irq; Fix the check of return value to catch errors correctly. Fixes: 4195926aedca ("gpio: Add support for IDT 79RC3243x GPIO controller") Signed-off-by: Miaoqian Lin <linmq006@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-01-27gpio: mpc8xxx: Fix IRQ check in mpc8xxx_probeMiaoqian Lin1-2/+2
commit 0b39536cc699db6850c426db7f9cb45923de40c5 upstream. platform_get_irq() returns negative error number instead 0 on failure. And the doc of platform_get_irq() provides a usage example: int irq = platform_get_irq(pdev, 0); if (irq < 0) return irq; Fix the check of return value to catch errors correctly. Fixes: 76c47d1449fc ("gpio: mpc8xxx: Add ACPI support") Signed-off-by: Miaoqian Lin <linmq006@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-01-27gpio: aspeed-sgpio: Convert aspeed_sgpio.lock to raw_spinlockIwona Winiarska1-16/+16
[ Upstream commit ab39d6988dd53f354130438d8afa5596a2440fed ] The gpio-aspeed-sgpio driver implements an irq_chip which need to be invoked from hardirq context. Since spin_lock() can sleep with PREEMPT_RT, it is no longer legal to invoke it while interrupts are disabled. This also causes lockdep to complain about: [ 25.919465] [ BUG: Invalid wait context ] because aspeed_sgpio.lock (spin_lock_t) is taken under irq_desc.lock (raw_spinlock_t). Let's use of raw_spinlock_t instead of spinlock_t. Signed-off-by: Iwona Winiarska <iwona.winiarska@intel.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27gpio: aspeed: Convert aspeed_gpio.lock to raw_spinlockIwona Winiarska1-26/+26
[ Upstream commit 61a7904b6ace99b1bde0d0e867fa3097f5c8cee2 ] The gpio-aspeed driver implements an irq_chip which need to be invoked from hardirq context. Since spin_lock() can sleep with PREEMPT_RT, it is no longer legal to invoke it while interrupts are disabled. This also causes lockdep to complain about: [ 0.649797] [ BUG: Invalid wait context ] because aspeed_gpio.lock (spin_lock_t) is taken under irq_desc.lock (raw_spinlock_t). Let's use of raw_spinlock_t instead of spinlock_t. Signed-off-by: Iwona Winiarska <iwona.winiarska@intel.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27gpiolib: acpi: Do not set the IRQ type if the IRQ is already in useHans de Goede1-4/+11
[ Upstream commit bdfd6ab8fdccd8b138837efff66f4a1911496378 ] If the IRQ is already in use, then acpi_dev_gpio_irq_get_by() really should not change the type underneath the current owner. I specifically hit an issue with this an a Chuwi Hi8 Super (CWI509) Bay Trail tablet, when the Boot OS selection in the BIOS is set to Android. In this case _STA for a MAX17047 ACPI I2C device wrongly returns 0xf and the _CRS resources for this device include a GpioInt pointing to a GPIO already in use by an _AEI handler, with a different type then specified in the _CRS for the MAX17047 device. Leading to the acpi_dev_gpio_irq_get() call done by the i2c-core-acpi.c code changing the type breaking the _AEI handler. Now this clearly is a bug in the DSDT of this tablet (in Android mode), but in general calling irq_set_irq_type() on an IRQ which already is in use seems like a bad idea. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-11gpio: gpio-aspeed-sgpio: Fix wrong hwirq base in irq handlerSteven Lee1-1/+1
commit e5a7431f5a2d6dcff7d516ee9d178a3254b17b87 upstream. Each aspeed sgpio bank has 64 gpio pins(32 input pins and 32 output pins). The hwirq base for each sgpio bank should be multiples of 64 rather than multiples of 32. Signed-off-by: Steven Lee <steven_lee@aspeedtech.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-29gpio: dln2: Fix interrupts when replugging the deviceNoralf Trønnes1-10/+9
commit 9a5875f14b0e3a13ae314883f1bb72b7f31fac07 upstream. When replugging the device the following message shows up: gpio gpiochip2: (dln2): detected irqchip that is shared with multiple gpiochips: please fix the driver. This also has the effect that interrupts won't work. The same problem would also show up if multiple devices where plugged in. Fix this by allocating the irq_chip data structure per instance like other drivers do. I don't know when this problem appeared, but it is present in 5.10. Cc: <stable@vger.kernel.org> # 5.10+ Cc: Daniel Baluta <daniel.baluta@gmail.com> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-29gpio: virtio: remove timeoutVincent Whitchurch1-5/+1
[ Upstream commit 3e4d9a485029aa9e172dab5420abe775fd86f8e8 ] The driver imposes an arbitrary one second timeout on virtio requests, but the specification doesn't prevent the virtio device from taking longer to process requests, so remove this timeout to support all systems and device implementations. Fixes: 3a29355a22c0275fe86 ("gpio: Add virtio-gpio driver") Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-25gpio: rockchip: needs GENERIC_IRQ_CHIP to fix build errorsRandy Dunlap1-0/+1
[ Upstream commit d6912b1251b47e6b04ea8c8881dfb35a6e7a3e29 ] gpio-rockchip uses interfaces that are provided by the Kconfig symbol GENERIC_IRQ_CHIP, so the driver should select that symbol in order to prevent build errors. Fixes these build errors (and more): aarch64-linux-ld: drivers/gpio/gpio-rockchip.o: in function `rockchip_irq_disable': gpio-rockchip.c:(.text+0x454): undefined reference to `irq_gc_mask_set_bit' aarch64-linux-ld: drivers/gpio/gpio-rockchip.o: in function `rockchip_irq_enable': gpio-rockchip.c:(.text+0x478): undefined reference to `irq_gc_mask_clr_bit' aarch64-linux-ld: drivers/gpio/gpio-rockchip.o: in function `rockchip_interrupts_register': gpio-rockchip.c:(.text+0x518): undefined reference to `irq_generic_chip_ops' aarch64-linux-ld: gpio-rockchip.c:(.text+0x594): undefined reference to `__irq_alloc_domain_generic_chips' aarch64-linux-ld: gpio-rockchip.c:(.text+0x5cc): undefined reference to `irq_get_domain_generic_chip' aarch64-linux-ld: gpio-rockchip.c:(.text+0x5e0): undefined reference to `irq_gc_ack_set_bit' aarch64-linux-ld: gpio-rockchip.c:(.text+0x604): undefined reference to `irq_gc_set_wake' Fixes: 936ee2675eee ("gpio/rockchip: add driver for rockchip gpio") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18gpio: realtek-otto: fix GPIO line IRQ offsetSander Vanheule1-1/+1
[ Upstream commit 585a07079909ba9061ddd88214c36653e1aef71a ] The irqchip uses one domain for all GPIO lines, so the line offset should be determined w.r.t. the first line of the first port, not the first line of the triggered port. Fixes: 0d82fb1127fb ("gpio: Add Realtek Otto GPIO support") Signed-off-by: Sander Vanheule <sander@svanheule.net> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-25gpio: mlxbf2.c: Add check for bgpio_init failureAsmaa Mnebhi1-0/+5
Add a check if bgpio_init fails. Signed-off-by: Asmaa Mnebhi <asmaa@nvidia.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
2021-10-25gpio: xgs-iproc: fix parsing of ngpios propertyJonas Gorski1-1/+1
of_property_read_u32 returns 0 on success, not true, so we need to invert the check to actually take over the provided ngpio value. Fixes: 6a41b6c5fc20 ("gpio: Add xgs-iproc driver") Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com> Reviewed-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
2021-10-06gpio: mockup: Convert to use software nodesAndy Shevchenko1-3/+18
The gpio-mockup driver creates the properties that are shared between platform and GPIO devices. Because of that, the properties may not be removed at the proper point of time without provoking a use-after-free as shown in the following backtrace: refcount_t: underflow; use-after-free. WARNING: CPU: 0 PID: 103 at lib/refcount.c:28 refcount_warn_saturate+0xd1/0x120 ... Call Trace: kobject_put+0xdc/0xf0 software_node_notify_remove+0xa8/0xc0 device_del+0x15a/0x3e0 That's why the driver has to manage the lifetime of the software nodes by itself. The problem originates from the old device_add_properties() API, but has been only revealed after the commit bd1e336aa853 ("driver core: platform: Remove platform_device_add_properties()"). Hence, it's used as a landmark for backporting. Fixes: bd1e336aa853 ("driver core: platform: Remove platform_device_add_properties()") Reported-by: Kent Gibson <warthog618@gmail.com> Tested-by: Kent Gibson <warthog618@gmail.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> [Bartosz: tweaked local variable placement] Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
2021-10-06gpio: pca953x: Improve bias settingAndy Shevchenko1-7/+9
The commit 15add06841a3 ("gpio: pca953x: add ->set_config implementation") introduced support for bias setting. However this, due to being half-baked, brought potential issues: - the turning bias via disabling makes the pin floating for a while; - once enabled, bias can't be disabled. Fix all these by adding support for bias disabling and move the disabling part under the corresponding conditional. While at it, add support for default setting, since it's cheap to add. Fixes: 15add06841a3 ("gpio: pca953x: add ->set_config implementation") Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
2021-10-06gpio: 74x164: Add SPI device ID tableMark Brown1-0/+8
Currently autoloading for SPI devices does not use the DT ID table, it uses SPI modalises. Supporting OF modalises is going to be difficult if not impractical, an attempt was made but has been reverted, so ensure that module autoloading works for this driver by adding a SPI device ID table. Fixes: 96c8395e2166 ("spi: Revert modalias changes") Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
2021-09-30Merge tag 'gpio-fixes-for-v5.15-rc4' of ↵Linus Torvalds1-9/+2
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux Pull gpio fixes from Bartosz Golaszewski: "A single fix for the gpio-pca953x driver and two commits updating the MAINTAINERS entries for Mun Yew Tham (GPIO specific) and myself (treewide after a change in professional situation). Summary: - don't ignore I2C errors in gpio-pca953x - update MAINTAINERS entries for Mun Yew Tham and myself" * tag 'gpio-fixes-for-v5.15-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: MAINTAINERS: Update Mun Yew Tham as Altera Pio Driver maintainer MAINTAINERS: update my email address gpio: pca953x: do not ignore i2c errors
2021-09-29gpio: pca953x: do not ignore i2c errorsAndrey Gusakov1-9/+2
Per gpio_chip interface, error shall be proparated to the caller. Attempt to silent diagnostics by returning zero (as written in the comment) is plain wrong, because the zero return can be interpreted by the caller as the gpio value. Cc: stable@vger.kernel.org Signed-off-by: Andrey Gusakov <andrey.gusakov@cogentembedded.com> Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
2021-09-29Merge tag 'pinctrl-v5.15-2' of ↵Linus Torvalds1-0/+22
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl Pull pin control fixes from Linus Walleij: "Some few pin control fixes for the v5.15 kernel cycle. The most critical is the AMD fixes. - Fix wakeup interrupts in the AMD driver affecting AMD laptops. - Fix parent irqspec translation in the Qualcomm SPMI GPIO driver. - Fix deferred probe handling in the Rockchip driver, this is a stopgap solution while we look for something more elegant. - Add PM suspend callbacks to the Qualcomm SC7280 driver. - Some minor doc fix (should have come in earlier, sorry)" * tag 'pinctrl-v5.15-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: pinctrl: qcom: sc7280: Add PM suspend callbacks gpio/rockchip: fetch deferred output settings on probe pinctrl/rockchip: add a queue for deferred pin output settings on probe pinctrl: qcom: spmi-gpio: correct parent irqspec translation pinctrl: amd: Handle wake-up interrupt pinctrl: amd: Add irq field data pinctrl: core: Remove duplicated word from devm_pinctrl_unregister()
2021-09-22gpio/rockchip: fix get_direction value handlingHeiko Stuebner1-1/+1
The function uses the newly introduced rockchip_gpio_readl_bit() which directly returns the actual value of the requeste bit. So using the existing bit-wise check for the bit inside the value will always return 0. Fix this by dropping the bit manipulation on the result. Fixes: 3bcbd1a85b68 ("gpio/rockchip: support next version gpio controller") Signed-off-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
2021-09-22gpio/rockchip: extended debounce support is only available on v2Heiko Stuebner1-1/+1
The gpio driver runs into issues on v1 gpio blocks, as the db_clk and the whole extended debounce support is only ever defined on v2. So checking for the IS_ERR on the db_clk is not enough, as it will be NULL on v1. Fix this by adding the needed condition for v2 first before checking the existence of the db_clk. This caused my rk3288-veyron-pinky to enter a reboot loop when it tried to enable the power-key as adc-key device. Fixes: 3bcbd1a85b68 ("gpio/rockchip: support next version gpio controller") Signed-off-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
2021-09-22gpio: gpio-aspeed-sgpio: Fix wrong hwirq in irq handler.Steven Lee1-1/+1
The current hwirq is calculated based on the old GPIO pin order(input GPIO range is from 0 to ngpios - 1). It should be calculated based on the current GPIO input pin order(input GPIOs are 0, 2, 4, ..., (ngpios - 1) * 2). Signed-off-by: Steven Lee <steven_lee@aspeedtech.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
2021-09-22gpio: uniphier: Fix void functions to remove return valueKunihiko Hayashi1-2/+2
The return type of irq_chip.irq_mask() and irq_chip.irq_unmask() should be void. Fixes: dbe776c2ca54 ("gpio: uniphier: add UniPhier GPIO controller driver") Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
2021-09-22gpiolib: acpi: Make set-debounce-timeout failures non fatalHans de Goede1-2/+4
Commit 8dcb7a15a585 ("gpiolib: acpi: Take into account debounce settings") made the gpiolib-acpi code call gpio_set_debounce_timeout() when requesting GPIOs. This in itself is fine, but it also made gpio_set_debounce_timeout() errors fatal, causing the requesting of the GPIO to fail. This is causing regressions. E.g. on a HP ElitePad 1000 G2 various _AEI specified GPIO ACPI event sources specify a debouncy timeout of 20 ms, but the pinctrl-baytrail.c only supports certain fixed values, the closest ones being 12 or 24 ms and pinctrl-baytrail.c responds with -EINVAL when specified a value which is not one of the fixed values. This is causing the acpi_request_own_gpiod() call to fail for 3 ACPI event sources on the HP ElitePad 1000 G2, which in turn is causing e.g. the battery charging vs discharging status to never get updated, even though a charger has been plugged-in or unplugged. Make gpio_set_debounce_timeout() errors non fatal, warning about the failure instead, to fix this regression. Note we should probably also fix various pinctrl drivers to just pick the first bigger discrete value rather then returning -EINVAL but this will need to be done on a per driver basis, where as this fix at least gets us back to where things were before and thus restores functionality on devices where this was lost due to gpio_set_debounce_timeout() errors. Fixes: 8dcb7a15a585 ("gpiolib: acpi: Take into account debounce settings") Depends-on: 2e2b496cebef ("gpiolib: acpi: Extract acpi_request_own_gpiod() helper") Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
2021-09-18gpio/rockchip: fetch deferred output settings on probeHeiko Stuebner1-0/+22
Fetch the output settings the pinctrl driver may have created for pinctrl hogs and set the relevant pins as requested. Fixes: 9ce9a02039de ("pinctrl/rockchip: drop the gpio related codes") Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20210913224926.1260726-5-heiko@sntech.de Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2021-09-07Merge tag 'gpio-updates-for-v5.15' of ↵Linus Torvalds17-362/+624
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux Pull gpio updates from Bartosz Golaszewski: "We mostly have various improvements and refactoring all over the place but also some interesting new features - like the virtio GPIO driver that allows guest VMs to use host's GPIOs. We also have a new/old GPIO driver for rockchip - this one has been split out of the pinctrl driver. Summary: - new driver: gpio-virtio allowing a guest VM running linux to access GPIO lines provided by the host - split the GPIO driver out of the rockchip pin control driver - add support for a new model to gpio-aspeed-sgpio, refactor the driver and use generic device property interfaces, improve property sanitization - add ACPI support to gpio-tegra186 - improve the code setting the line names to support multiple GPIO banks per device - constify a bunch of OF functions in the core GPIO code and make the declaration for one of the core OF functions we use consistent within its header - use software nodes in intel_quark_i2c_gpio - add support for the gpio-line-names property in gpio-mt7621 - use the standard GPIO function for setting the GPIO names in gpio-brcmstb - fix a bunch of leaks and other bugs in gpio-mpc8xxx - use generic pm callbacks in gpio-ml-ioh - improve resource management and PM handling in gpio-mlxbf2 - modernize and improve the gpio-dwapb driver - coding style improvements in gpio-rcar - documentation fixes and improvements - update the MAINTAINERS entry for gpio-zynq - minor tweaks in several drivers" * tag 'gpio-updates-for-v5.15' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: (35 commits) gpio: mpc8xxx: Use 'devm_gpiochip_add_data()' to simplify the code and avoid a leak gpio: mpc8xxx: Fix a potential double iounmap call in 'mpc8xxx_probe()' gpio: mpc8xxx: Fix a resources leak in the error handling path of 'mpc8xxx_probe()' gpio: viperboard: remove platform_set_drvdata() call in probe gpio: virtio: Add missing mailings lists in MAINTAINERS entry gpio: virtio: Fix sparse warnings gpio: remove the obsolete MX35 3DS BOARD MC9S08DZ60 GPIO functions gpio: max730x: Use the right include gpio: Add virtio-gpio driver gpio: mlxbf2: Use DEFINE_RES_MEM_NAMED() helper macro gpio: mlxbf2: Use devm_platform_ioremap_resource() gpio: mlxbf2: Drop wrong use of ACPI_PTR() gpio: mlxbf2: Convert to device PM ops gpio: dwapb: Get rid of legacy platform data mfd: intel_quark_i2c_gpio: Convert GPIO to use software nodes gpio: dwapb: Read GPIO base from gpio-base property gpio: dwapb: Unify ACPI enumeration checks in get_irq() and configure_irqs() gpiolib: Deduplicate forward declaration in the consumer.h header MAINTAINERS: update gpio-zynq.yaml reference gpio: tegra186: Add ACPI support ...
2021-08-31gpio: mpc8xxx: Use 'devm_gpiochip_add_data()' to simplify the code and avoid ↵Christophe JAILLET1-3/+1
a leak If an error occurs after a 'gpiochip_add_data()' call it must be undone by a corresponding 'gpiochip_remove()' as already done in the remove function. To simplify the code a fix a leak in the error handling path of the probe, use the managed version instead (i.e. 'devm_gpiochip_add_data()') Fixes: 698b8eeaed72 ("gpio/mpc8xxx: change irq handler from chained to normal") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-08-31gpio: mpc8xxx: Fix a potential double iounmap call in 'mpc8xxx_probe()'Christophe JAILLET1-7/+4
Commit 76c47d1449fc ("gpio: mpc8xxx: Add ACPI support") has switched to a managed version when dealing with 'mpc8xxx_gc->regs'. So the corresponding 'iounmap()' call in the error handling path and in the remove should be removed to avoid a double unmap. This also allows some simplification in the probe. All the error handling paths related to managed resources can be direct returns and a NULL check in what remains in the error handling path can be removed. Fixes: 76c47d1449fc ("gpio: mpc8xxx: Add ACPI support") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-08-31gpio: mpc8xxx: Fix a resources leak in the error handling path of ↵Christophe JAILLET1-0/+2
'mpc8xxx_probe()' Commit 698b8eeaed72 ("gpio/mpc8xxx: change irq handler from chained to normal") has introduced a new 'goto err;' at the very end of the function, but has not updated the error handling path accordingly. Add the now missing 'irq_domain_remove()' call which balances a previous 'irq_domain_create_linear() call. Fixes: 698b8eeaed72 ("gpio/mpc8xxx: change irq handler from chained to normal") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-08-31gpio: viperboard: remove platform_set_drvdata() call in probeAlexandru Ardelean1-11/+3
The platform_set_drvdata() call is only useful if we need to retrieve back the private information. Since the driver doesn't do that, it's not useful to have it. This change removes it. Also removing with this change is some logging about the failure to init the gpio chip data. There are other logging methods to view that this failed. Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-08-31gpio: virtio: Fix sparse warningsViresh Kumar1-21/+20
Fix warnings reported by sparse, related to type mismatch between u16 and __le16. Reported-by: kernel test robot <lkp@intel.com> Fixes: 3a29355a22c0 ("gpio: Add virtio-gpio driver") Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-08-29Merge tag 'irqchip-5.15' of ↵Thomas Gleixner46-142/+871
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/core Pull irqchip updates from Marc Zyngier: - API updates: - Treewide conversion to generic_handle_domain_irq() for anything that looks like a chained interrupt controller - Update the irqdomain documentation - Use of bitmap_zalloc() throughout the tree - New functionalities: - Support for GICv3 EPPI partitions - Fixes: - Qualcomm PDC hierarchy fixes - Yet another priority decoding fix for the GICv3 pseudo-NMIs - Fix the apple-aic driver irq_eoi() callback to always unmask the interrupt - Properly handle edge interrupts on loongson-pch-pic - Let the mtk-sysirq driver advertise IRQCHIP_SKIP_SET_WAKE Link: https://lore.kernel.org/r/20210828121013.2647964-1-maz@kernel.org
2021-08-23Merge branch 'ib-rockchip' of ↵Bartosz Golaszewski3-0/+780
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl into gpio/for-next
2021-08-23gpio: remove the obsolete MX35 3DS BOARD MC9S08DZ60 GPIO functionsLukas Bulwahn3-119/+0
Commit e1324ece2af4 ("ARM: imx: Remove i.MX35 board files") removes the config MACH_MX35_3DS in arch/arm/mach-imx/Kconfig. Hence, since then, the MX35 3DS BOARD MC9S08DZ60 GPIO functions are dead code as its config GPIO_MC9S08DZ60 depends on the config MACH_MX35_3DS. Luckily, ./scripts/checkkconfigsymbols.py warns on non-existing configs: MACH_MX35_3DS Referencing files: drivers/gpio/Kconfig Remove the obsolete MX35 3DS BOARD MC9S08DZ60 GPIO functions. Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-08-23gpio: Add virtio-gpio driverViresh Kumar3-0/+385
This patch adds a new driver for Virtio based GPIO devices. This allows a guest VM running Linux to access GPIO lines provided by the host. It supports all basic operations, except interrupts for the GPIO lines. Based on the initial work posted by: "Enrico Weigelt, metux IT consult" <lkml@metux.net>. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-08-18Merge remote-tracking branch 'linusw/ib-rockchip' into ↵Marc Zyngier3-0/+780
irq/generic_handle_domain_irq Merge Linus' ib-rockchip branch to avoid ugly conflicts with the generic_handle_domain_irq rework. Signed-off-by: Marc Zyngier <maz@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2024-06-11 08:53:45 +0300