summaryrefslogtreecommitdiffstats
path: root/drivers/gpio
Commit message (Collapse)AuthorAgeFilesLines
* gpio: don't use same lockdep class for all devm_gpiochip_add_data usersAhmad Fatoum2020-08-191-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 5f402bb17533113c21d61c2d4bc4ef4a6fa1c9a5 ] Commit 959bc7b22bd2 ("gpio: Automatically add lockdep keys") documents in its commits message its intention to "create a unique class key for each driver". It does so by having gpiochip_add_data add in-place the definition of two static lockdep classes for LOCKDEP use. That way, every caller of the macro adds their gpiochip with unique lockdep classes. There are many indirect callers of gpiochip_add_data, however, via use of devm_gpiochip_add_data. devm_gpiochip_add_data has external linkage and all its users will share the same lockdep classes, which probably is not intended. Fix this by replicating the gpio_chip_add_data statics-in-macro for the devm_ version as well. Fixes: 959bc7b22bd2 ("gpio: Automatically add lockdep keys") Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Link: https://lore.kernel.org/r/20200731123835.8003-1-a.fatoum@pengutronix.de Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* gpio: max77620: Fix missing release of interruptDmitry Osipenko2020-08-111-2/+3
| | | | | | | | | | | | | | | | | commit 2a5e6f7eede8cd1c4bac0b8ec6491cec4e75c99a upstream. The requested interrupt is never released by the driver. Fix this by using the resource-managed variant of request_threaded_irq(). Fixes: ab3dd9cc24d4 ("gpio: max77620: Fix interrupt handling") Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Acked-by: Laxman Dewangan <ldewangan@nvidia.com> Cc: <stable@vger.kernel.org> # 5.5+ Link: https://lore.kernel.org/r/20200709171203.12950-3-digetx@gmail.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* gpio: arizona: put pm_runtime in case of failureNavid Emamdoost2020-07-291-1/+5
| | | | | | | | | | | | | | [ Upstream commit 861254d826499944cb4d9b5a15f5a794a6b99a69 ] Calling pm_runtime_get_sync increments the counter even in case of failure, causing incorrect ref count if pm_runtime_put is not called in error handling paths. Call pm_runtime_put if pm_runtime_get_sync fails. Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com> Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20200605030052.78235-1-navid.emamdoost@gmail.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* gpio: arizona: handle pm_runtime_get_sync failure caseNavid Emamdoost2020-07-291-0/+1
| | | | | | | | | | | | | | [ Upstream commit e6f390a834b56583e6fc0949822644ce92fbb107 ] Calling pm_runtime_get_sync increments the counter even in case of failure, causing incorrect ref count. Call pm_runtime_put if pm_runtime_get_sync fails. Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com> Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20200605025207.65719-1-navid.emamdoost@gmail.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* gpio: pca953x: disable regmap locking for automatic address incrementingAndy Shevchenko2020-07-221-0/+1
| | | | | | | | | | | | | | | | | | | | commit ec3decd21380081e3b5de4ba8d85d90a95f201a0 upstream. It's a repetition of the commit aa58a21ae378 ("gpio: pca953x: disable regmap locking") which states the following: This driver uses its own locking but regmap silently uses a mutex for all operations too. Add the option to disable locking to the regmap config struct. Fixes: bcf41dc480b1 ("gpio: pca953x: fix handling of automatic address incrementing") Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* gpio: pca953x: Fix GPIO resource leak on Intel Galileo Gen 2Andy Shevchenko2020-07-161-1/+6
| | | | | | | | | | | | | | | | | [ Upstream commit 5d8913504ccfeea6120df5ae1c6f4479ff09b931 ] When adding a quirk for IRQ on Intel Galileo Gen 2 the commit ba8c90c61847 ("gpio: pca953x: Override IRQ for one of the expanders on Galileo Gen 2") missed GPIO resource release. We can safely do this in the same quirk, since IRQ will be locked by GPIO framework when requested and unlocked on freeing. Fixes: ba8c90c61847 ("gpio: pca953x: Override IRQ for one of the expanders on Galileo Gen 2") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* gpio: pca953x: Fix direction setting when configure an IRQAndy Shevchenko2020-07-161-2/+4
| | | | | | | | | | | | | | | | | | | | [ Upstream commit 0b22c25e1b81c5f718e89c4d759e6a359be24417 ] The commit 0f25fda840a9 ("gpio: pca953x: Zap ad-hoc reg_direction cache") seems inadvertently made a typo in pca953x_irq_bus_sync_unlock(). When the direction bit is 1 it means input, and the piece of code in question was looking for output ones that should be turned to inputs. Fix direction setting when configure an IRQ by injecting a bitmap complement operation. Fixes: 0f25fda840a9 ("gpio: pca953x: Zap ad-hoc reg_direction cache") Depends-on: 35d13d94893f ("gpio: pca953x: convert to use bitmap API") Cc: Marek Vasut <marek.vasut@gmail.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* gpio: pca953x: Override IRQ for one of the expanders on Galileo Gen 2Andy Shevchenko2020-07-161-0/+79
| | | | | | | | | | | | | | | | | | | | | [ Upstream commit ba8c90c6184784b397807b72403656085ac2f8c1 ] ACPI table on Intel Galileo Gen 2 has wrong pin number for IRQ resource of one of the I²C GPIO expanders. Since we know what that number is and luckily have GPIO bases fixed for SoC's controllers, we may use a simple DMI quirk to match the platform and retrieve GpioInt() pin on it for the expander in question. Mika suggested the way to avoid a quirk in the GPIO ACPI library and here is the second, almost rewritten version of it. Fixes: f32517bf1ae0 ("gpio: pca953x: support ACPI devices found on Galileo Gen2") Depends-on: 25e3ef894eef ("gpio: acpi: Split out acpi_gpio_get_irq_resource() helper") Suggested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* gpio: pca953x: Synchronize interrupt handler properlyAndy Shevchenko2020-07-161-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 064c73afe7385de99e5b2785b88c83dc5d84403b ] Since the commit aa58a21ae378 ("gpio: pca953x: disable regmap locking") the locking of regmap is disabled and that immediately introduces a synchronization issue. It's easy to see when we try to monitor more than one interrupt from the same chip. It seems that the problem exists from the day one and even commit 6e20fb18054c ("drivers/gpio/pca953x.c: add a mutex to fix race condition") missed this. Below are the traces and shell reproducers before and after proposed change. Note duplicates in the IRQ events. /proc/interrupts also shows a deviation, i.e. sum of children interrupts higher than parent's one. When locking is disabled for regmap and no protection in IRQ handler ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ... gpioset-194 regmap_hw_write_start: i2c-INT3491:02 reg=2 count=1 irq/31-i2c-INT3-139 regmap_hw_read_start: i2c-INT3491:02 reg=4c count=2 gpioset-194 regmap_hw_write_done: i2c-INT3491:02 reg=2 count=1 gpioset-194 regmap_reg_read_cache: i2c-INT3491:02 reg=6 val=f5 gpioset-194 regmap_reg_write: i2c-INT3491:02 reg=6 val=f5 gpioset-194 regmap_hw_write_start: i2c-INT3491:02 reg=6 count=1 irq/31-i2c-INT3-139 regmap_hw_read_done: i2c-INT3491:02 reg=4c count=2 ... % gpiomon gpiochip3 0 & % gpioset gpiochip3 1=0 % gpioset gpiochip3 1=1 event: RISING EDGE offset: 0 timestamp: [ 302.782583765] % gpiomon gpiochip3 2 & % gpioset gpiochip3 1=0 event: RISING EDGE offset: 2 timestamp: [ 312.033148829] event: FALLING EDGE offset: 0 timestamp: [ 312.022757525] % gpioset gpiochip3 1=1 event: RISING EDGE offset: 2 timestamp: [ 316.201148473] event: RISING EDGE offset: 0 timestamp: [ 316.191759599] When locking is disabled for regmap and protection in IRQ handler ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ... gpioset-202 regmap_hw_write_start: i2c-INT3491:02 reg=2 count=1 gpioset-202 regmap_hw_write_done: i2c-INT3491:02 reg=2 count=1 gpioset-202 regmap_reg_read_cache: i2c-INT3491:02 reg=6 val=fd gpioset-202 regmap_reg_write: i2c-INT3491:02 reg=6 val=fd gpioset-202 regmap_hw_write_start: i2c-INT3491:02 reg=6 count=1 gpioset-202 regmap_hw_write_done: i2c-INT3491:02 reg=6 count=1 irq/31-i2c-INT3-139 regmap_hw_read_start: i2c-INT3491:02 reg=4c count=2 irq/31-i2c-INT3-139 regmap_hw_read_done: i2c-INT3491:02 reg=4c count=2 ... % gpiomon gpiochip3 0 & % gpioset gpiochip3 1=0 event: FALLING EDGE offset: 0 timestamp: [ 531.330078107] % gpioset gpiochip3 1=1 event: RISING EDGE offset: 0 timestamp: [ 532.912239128] % gpiomon gpiochip3 2 & % gpioset gpiochip3 1=0 event: FALLING EDGE offset: 0 timestamp: [ 539.633669484] % gpioset gpiochip3 1=1 event: RISING EDGE offset: 0 timestamp: [ 542.256978461] Fixes: 6e20fb18054c ("drivers/gpio/pca953x.c: add a mutex to fix race condition") Depends-on: 35d13d94893f ("gpio: pca953x: convert to use bitmap API") Depends-on: 49427232764d ("gpio: pca953x: Perform basic regmap conversion") Cc: Marek Vasut <marek.vasut@gmail.com> Cc: Roland Stigge <stigge@antcom.de> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* gpio: pca953x: fix handling of automatic address incrementingUwe Kleine-König2020-06-241-16/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit bcf41dc480b179bfb669a232080a2e26dc7294b4 ] Some of the chips supported by the pca953x driver need the most significant bit in the address word set to automatically increment the address pointer on subsequent reads and writes (example: PCA9505). With this bit unset the same register is read multiple times on a multi-byte read sequence. Other chips must not have this bit set and autoincrement always (example: PCA9555). Up to now this AI bit was interpreted to be part of the address, which resulted in inconsistent regmap caching when a register was written with AI set and then read without it. This happened for the PCA9505 in pca953x_gpio_set_multiple() where pca953x_read_regs() bulk read from the cache for registers 0x8-0xc and then wrote to registers 0x88-0x8c. (Side note: reading 5 values from offset 0x8 yiels OP0 5 times because AI must be set to get OP0-OP4, which is another bug that is resolved here as a by-product.) The same problem happens when calls to gpio_set_value() and gpio_set_array_value() were mixed. With this patch the AI bit is always set for chips that support it. This works as there are no code locations that make use of the behaviour with AI unset (for the chips that support it). Note that the call to pca953x_setup_gpio() had to be done a bit earlier to make the NBANK macro work. The history of this bug is a bit complicated. Commit b32cecb46bdc ("gpio: pca953x: Extract the register address mangling to single function") changed which chips and functions are affected. Commit 3b00691cc46a ("gpio: pca953x: hack to fix 24 bit gpio expanders") used some duct tape to make the driver at least appear to work. Commit 49427232764d ("gpio: pca953x: Perform basic regmap conversion") introduced the caching. Commit b4818afeacbd ("gpio: pca953x: Add set_multiple to allow multiple bits to be set in one write.") introduced the .set_multiple() callback which didn't work for chips that need the AI bit which was fixed later for some chips in 8958262af3fb ("gpio: pca953x: Repair multi-byte IO address increment on PCA9575"). So I'm sorry, I don't know which commit I should pick for a Fixes: line. Tested-by: Marcel Gudert <m.gudert@eckelmann.de> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Tested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* gpio: mlxbf2: fix return value check in mlxbf2_gpio_get_lock_res()Wei Yongjun2020-06-241-2/+2
| | | | | | | | | | | | | [ Upstream commit 66d8ad67aab3bc6f55e7de81565cd0d4875bd851 ] In case of error, the function devm_ioremap() returns NULL pointer not ERR_PTR(). The IS_ERR() test in the return value check should be replaced with NULL test. Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Link: https://lore.kernel.org/r/20200427110829.154785-1-weiyongjun1@huawei.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* gpio: dwapb: Append MODULE_ALIAS for platform driverAndy Shevchenko2020-06-241-3/+6
| | | | | | | | | | | | | | | | | | | | [ Upstream commit c58220cba2e03618659fa7d5dfae31f5ad4ae9d0 ] The commit 3d2613c4289f ("GPIO: gpio-dwapb: Enable platform driver binding to MFD driver") introduced a use of the platform driver but missed to add the following line to it: MODULE_ALIAS("platform:gpio-dwapb"); Add this to get driver loaded automatically if platform device is registered. Fixes: 3d2613c4289f ("GPIO: gpio-dwapb: Enable platform driver binding to MFD driver") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Serge Semin <fancer.lancer@gmail.com> Reviewed-by: Serge Semin <fancer.lancer@gmail.com> Link: https://lore.kernel.org/r/20200415141534.31240-2-andriy.shevchenko@linux.intel.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* gpio: dwapb: Call acpi_gpiochip_free_interrupts() on GPIO chip de-registrationAndy Shevchenko2020-06-241-9/+16
| | | | | | | | | | | | | | | | | | | [ Upstream commit 494a94e38dcf62543a32a4424d646ff80b4b28bd ] Add missed acpi_gpiochip_free_interrupts() call when unregistering ports. While at it, drop extra check to call acpi_gpiochip_request_interrupts(). There is no need to have an additional check to call acpi_gpiochip_request_interrupts(). Even without any interrupts available the registered ACPI Event handlers can be useful for debugging purposes. Fixes: e6cb3486f5a1 ("gpio: dwapb: add gpio-signaled acpi event support") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Serge Semin <fancer.lancer@gmail.com> Acked-by: Serge Semin <fancer.lancer@gmail.com> Link: https://lore.kernel.org/r/20200519131233.59032-1-andriy.shevchenko@linux.intel.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* gpio: fix locking open drain IRQ linesLinus Walleij2020-05-291-2/+9
| | | | | | | | | | | | | | | | | | We provided the right semantics on open drain lines being by definition output but incidentally the irq set up function would only allow IRQs on lines that were "not output". Fix the semantics to allow output open drain lines to be used for IRQs. Reported-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Tested-by: Hans Verkuil <hverkuil@xs4all.nl> Cc: Russell King <linux@armlinux.org.uk> Cc: stable@vger.kernel.org # v5.3+ Link: https://lore.kernel.org/r/20200527140758.162280-1-linus.walleij@linaro.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* gpio: bcm-kona: Fix return value of bcm_kona_gpio_probe()Tiezhu Yang2020-05-251-1/+1
| | | | | | | | | | Propagate the error code returned by devm_platform_ioremap_resource() out of probe() instead of overwriting it. Fixes: 72d8cb715477 ("drivers: gpio: bcm-kona: use devm_platform_ioremap_resource()") Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn> [Bartosz: tweaked the commit message] Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
* gpio: pxa: Fix return value of pxa_gpio_probe()Tiezhu Yang2020-05-251-2/+2
| | | | | | | | | When call function devm_platform_ioremap_resource(), we should use IS_ERR() to check the return value and return PTR_ERR() if failed. Fixes: 542c25b7a209 ("drivers: gpio: pxa: use devm_platform_ioremap_resource()") Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
* gpio: mlxbf2: Fix sleeping while holding spinlockAxel Lin2020-05-251-3/+3
| | | | | | | | | mutex_lock() can sleep, don't call mutex_lock() while holding spin_lock. Fixes: bc0ae0e737f5 ("gpio: add driver for Mellanox BlueField 2 GPIO controller") Signed-off-by: Axel Lin <axel.lin@ingics.com> Acked-by: asmaa@mellanox.com Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
* Merge tag 'gpio-fixes-for-v5.7-rc6' of ↵Linus Walleij2020-05-183-10/+27
|\ | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux into fixes gpio fixes for v5.7-rc6 - fix probing for chips without PWM in gpio-mvebu - fix ida_simple_get() error path in gpio-exar - fix user-space notifications for line state changes
| * gpiolib: notify user-space about line status changes after flags are setBartosz Golaszewski2020-05-131-2/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently we emit the REQUESTED line state event after the line is requested but before the flags are configured. This is obviously wrong as we want to pass the updated lineinfo to user-space together with the event. Since the flags can be configured in different ways depending on how the line is being requested - we need to call the notifier chain in different places separately. Fixes: 51c1064e82e7 ("gpiolib: add new ioctl() for monitoring changes in line info") Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
| * gpio: exar: Fix bad handling for ida_simple_get error pathTakashi Iwai2020-05-051-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The commit 7ecced0934e5 ("gpio: exar: add a check for the return value of ida_simple_get fails") added a goto jump to the common error handler for ida_simple_get() error, but this is wrong in two ways: it doesn't set the proper return code and, more badly, it invokes ida_simple_remove() with a negative index that shall lead to a kernel panic via BUG_ON(). This patch addresses those two issues. Fixes: 7ecced0934e5 ("gpio: exar: add a check for the return value of ida_simple_get fails") Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
| * gpio: mvebu: Fix probing for chips without PWMSascha Hauer2020-04-241-6/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The PWM iomem resource is optional and its presence indicates whether the GPIO chip has a PWM or not, which is why mvebu_pwm_probe() returned successfully when the PWM resource was not present. With f51b18d92b66 the driver switched to devm_platform_ioremap_resource_byname() and its error return is propagated to the caller, so now a missing PWM resource leads to a probe error in the driver. To fix this explicitly test for the presence of the PWM resource and return successfully when it's not there. Do this check before the check for the clock is done (which GPIO chips without a PWM do not have). Also move the existing comment why the PWM resource is optional up to the actual check. Fixes: f51b18d92b66 ("gpio: mvebu: use devm_platform_ioremap_resource_byname()") Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
* | gpio: tegra: mask GPIO IRQs during IRQ shutdownStephen Warren2020-04-281-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | The driver currently leaves GPIO IRQs unmasked even when the GPIO IRQ client has released the GPIO IRQ. This allows the HW to raise IRQs, and SW to process them, after shutdown. Fix this by masking the IRQ when it's shut down. This is usually taken care of by the irqchip core, but since this driver has a custom irq_shutdown implementation, it must do this explicitly itself. Signed-off-by: Stephen Warren <swarren@nvidia.com> Link: https://lore.kernel.org/r/20200427232605.11608-1-swarren@wwwdotorg.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* | gpio: of: Build fails if CONFIG_OF_DYNAMIC enabled without CONFIG_OF_GPIODavid Gow2020-04-281-2/+3
|/ | | | | | | | | | | | | | | | | | | The symbol 'gpio_of_notifier' doesn't exist without both CONFIG_OF_GPIO and CONFIG_OF_DYNAMIC enabled, but is referenced when only CONFIG_OF_DYNAMIC is enabled. This broke building with 'make ARCH=um allyesconfig': --------------- /usr/bin/ld: drivers/gpio/gpiolib.o: in function `gpiolib_dev_init': ./drivers/gpio/gpiolib.c:5293: undefined reference to `gpio_of_notifier' collect2: error: ld returned 1 exit status --------------- Fixes: 63636d956c45 ("gpio: of: Add DT overlay support for GPIO hogs") Signed-off-by: David Gow <davidgow@google.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20200425044655.166257-1-davidgow@google.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* gpiolib: don't call sleeping functions with a spinlock takenBartosz Golaszewski2020-04-231-1/+12
| | | | | | | | | | | | | | | | | We must not call pinctrl_gpio_can_use_line() with the gpio_lock taken as it takes a mutex internally. Let's move the call before taking the spinlock and store the return value. This isn't perfect - there's a moment between calling pinctrl_gpio_can_use_line() and taking the spinlock where the situation can change but it isn't a regression either: previously this part wasn't protected at all and it only affects the information user-space is seeing. Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Fixes: d2ac25798208 ("gpiolib: provide a dedicated function for setting lineinfo") Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Acked-by: Linus Walleij <linus.walleij@linaro.org>
* gpiolib: improve the robustness of watch/unwatch ioctl()Bartosz Golaszewski2020-04-231-2/+14
| | | | | | | | | | | This makes the new ioctl() a bit more robust - we now check if a line is already being watched and return -EBUSY if the user-space tries to start watching it again. Same for unwatch - return -EBUSY if user-space tries to unwatch a line that's not being watched. Fixes: 51c1064e82e7 ("gpiolib: add new ioctl() for monitoring changes in line info") Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
* gpio: pca953x: Fix pca953x_gpio_set_configAdam Ford2020-04-231-1/+1
| | | | | | | | | | | | | | pca953x_gpio_set_config is setup to support pull-up/down bias. Currently the driver uses a variable called 'config' to determine which options to use. Unfortunately, this is incorrect. This patch uses function pinconf_to_config_param(config), which converts this 'config' parameter back to pinconfig to determine which option to use. Fixes: 15add06841a3 ("gpio: pca953x: add ->set_config implementation") Signed-off-by: Adam Ford <aford173@gmail.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
* Merge tag 'gpio-v5.7-1' of ↵Linus Torvalds2020-04-0425-659/+1446
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio Pull GPIO updates from Linus Walleij: "This is the bulk of GPIO development for the v5.7 kernel cycle. Core and userspace API: - The userspace API KFIFOs have been imoproved with locks that do not block interrupts. This makes us better at getting events to userspace without blocking or disturbing new events arriving in the same time. This was reviewed by the KFIFO maintainer Stefani. This is a generic improvement which paves the road for similar improvements in other subsystems. - We provide a new ioctl() for monitoring changes in the line information, such as when multiple clients are taking lines and giving them back, possibly reconfiguring them in the process: we can now monitor that and not get stuck with stale static information. - An example tool 'gpio-watch' is provided to showcase this functionality. - Timestamps for events are switched to ktime_get_ns() which is monotonic. We previously had a 'realtime' stamp which could move forward and *backward* in time, which probably would just cause silent bugs and weird behaviour. In the long run we see two relevant timestamps: ktime_get_ns() or the timestamp sometimes provided by the GPIO hardware itself, if that exists. - Device Tree overlay support for GPIO hogs. On systems that load overlays, these overlays can now contain hogs, and will then be respected. - Handle pin control interaction with nonexisting pin ranges in the GPIO library core instead of in the individual drivers. New drivers: - New driver for the Mellanox BlueField 2 GPIO controller. Driver improvements: - Introduce the BGPIOF_NO_SET_ON_INPUT flag to the generic MMIO GPIO library and use this flag in the MT7621 driver. - Texas Instruments OMAP CPU power management improvements, such as blocking of idle on pending GPIO interrupts" * tag 'gpio-v5.7-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (59 commits) Revert "gpio: eic-sprd: Use devm_platform_ioremap_resource()" pinctrl: Unconditionally assign .request()/.free() gpio: Unconditionally assign .request()/.free() gpio: export of_pinctrl_get to modules pinctrl: Define of_pinctrl_get() dummy for !PINCTRL gpio: Rename variable in core APIs gpio: Avoid using pin ranges with !PINCTRL gpiolib: Remove unused gpio_chip parameter from gpio_set_bias() gpiolib: Pass gpio_desc to gpio_set_config() gpiolib: Introduce gpiod_set_config() tools: gpio: Fix out-of-tree build regression gpio: gpiolib: fix a doc warning gpio: tegra186: Add Tegra194 pin ranges for GG.0 and GG.1 gpio: tegra186: Add support for pin ranges gpio: Support GPIO controllers without pin-ranges ARM: integrator: impd1: Use GPIO_LOOKUP() helper macro gpio: brcmstb: support gpio-line-names property tools: gpio: Fix typo in gpio-utils tools: gpio-hammer: Apply scripts/Lindent and retain good changes gpiolib: gpio_name_to_desc: factor out !name check ...
| * Revert "gpio: eic-sprd: Use devm_platform_ioremap_resource()"Baolin Wang2020-04-021-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 0f5cb8cc27a266c81e6523b436479802e9aafc9e. This commit will cause below warnings, since our EIC controller can support differnt banks on different Spreadtrum SoCs, and each bank has its own base address, we will get invalid resource warning if the bank number is less than SPRD_EIC_MAX_BANK on some Spreadtrum SoCs. So we should not use devm_platform_ioremap_resource() here to remove the warnings. [ 1.118508] sprd-eic 40210000.gpio: invalid resource [ 1.118535] sprd-eic 40210000.gpio: invalid resource [ 1.119034] sprd-eic 40210080.gpio: invalid resource [ 1.119055] sprd-eic 40210080.gpio: invalid resource [ 1.119462] sprd-eic 402100a0.gpio: invalid resource [ 1.119482] sprd-eic 402100a0.gpio: invalid resource [ 1.119893] sprd-eic 402100c0.gpio: invalid resource [ 1.119913] sprd-eic 402100c0.gpio: invalid resource Signed-off-by: Baolin Wang <baolin.wang7@gmail.com> Link: https://lore.kernel.org/r/8d3579f4b49bb675dc805035960f24852898be28.1585734060.git.baolin.wang7@gmail.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
| * gpio: Unconditionally assign .request()/.free()Thierry Reding2020-04-025-26/+12
| | | | | | | | | | | | | | | | | | | | | | The gpiochip_generic_request() and gpiochip_generic_free() functions can now deal properly with chips that don't have any pin-ranges defined, so they can be assigned unconditionally. Suggested-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://lore.kernel.org/r/20200401200527.2982450-1-thierry.reding@gmail.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
| * gpio: Rename variable in core APIsLinus Walleij2020-03-311-412/+413
| | | | | | | | | | | | | | | | | | | | | | | | | | | | There is struct gpio *gc, *chip and *gpiochip, and yes I am responsible for some of the inconsistencies. I want this to be just gc everywhere for minimizing cognitive resistance when reading the code: more compact function signatures and less clutter. Purely syntactic changes intended. No semantic effects. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20200329140405.52276-1-linus.walleij@linaro.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
| * gpio: Avoid using pin ranges with !PINCTRLThierry Reding2020-03-311-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Do not use the struct gpio_device's .pin_ranges field if the PINCTRL Kconfig symbol is not selected to avoid build failures. Fixes: 2ab73c6d8323fa1e ("gpio: Support GPIO controllers without pin-ranges") Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://lore.kernel.org/r/20200330090257.2332864-1-thierry.reding@gmail.com Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org> Tested-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
| * gpiolib: Remove unused gpio_chip parameter from gpio_set_bias()Geert Uytterhoeven2020-03-271-5/+3
| | | | | | | | | | | | | | | | | | gpio_set_bias() no longer uses the passed gpio_chip pointer parameter. Remove it. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20200325100439.14000-3-geert+renesas@glider.be Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
| * gpiolib: Pass gpio_desc to gpio_set_config()Geert Uytterhoeven2020-03-271-10/+7
| | | | | | | | | | | | | | | | | | | | All callers of gpio_set_config() have to convert a gpio_desc to a gpio_chip and offset. Avoid these duplicated conversion steps by letting gpio_set_config() take a gpio_desc pointer directly. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20200325100439.14000-2-geert+renesas@glider.be Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
| * gpiolib: Introduce gpiod_set_config()Geert Uytterhoeven2020-03-271-6/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The GPIO Aggregator will need a method to forward a .set_config() call to its parent gpiochip. This requires obtaining the gpio_chip and offset for a given gpio_desc. While gpiod_to_chip() is public, gpio_chip_hwgpio() is not, so there is currently no method to obtain the needed GPIO offset parameter. Hence introduce a public gpiod_set_config() helper, which invokes the .set_config() callback through a gpio_desc pointer, like is done for most other gpio_chip callbacks. Rewrite the existing gpiod_set_debounce() helper as a wrapper around gpiod_set_config(), to avoid duplication. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20200324135653.6676-5-geert+renesas@glider.be Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
| * Merge tag 'v5.6-rc7' into develLinus Walleij2020-03-274-20/+31
| |\ | | | | | | | | | Linux 5.6-rc7
| * | gpio: gpiolib: fix a doc warningMauro Carvalho Chehab2020-03-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use a different markup for the ERR_PTR, as %FOO doesn't work if there are parenthesis. So, use, instead: ``ERR_PTR(-EINVAL)`` This fixes the following warning: ./drivers/gpio/gpiolib.c:139: WARNING: Inline literal start-string without end-string. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/51197e3568f073e22c280f0584bfa20b44436708.1584456635.git.mchehab+huawei@kernel.org Reviewed-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
| * | gpio: tegra186: Add Tegra194 pin ranges for GG.0 and GG.1Thierry Reding2020-03-271-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The GG.0 and GG.1 GPIOs serve as CLKREQ and RST pins, respectively, for PCIe controller 5 on Tegra194. When this controller is configured in endpoint mode, these pins need to be used as GPIOs by the PCIe endpoint driver. Typically the mode programming of these pins (GPIO vs. SFIO) is performed by early boot firmware to ensure that the configuration is consistent. However, the GG.0 and GG.1 pins are part of a special power partition that is not enabled during early boot, and hence the early boot firmware cannot program these pins to be GPIOs (they are SFIO by default). Adding them as pin ranges for the pin controller allows the pin controller to be involved when these pins are requested as GPIOs and allows the proper programming to take place. Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://lore.kernel.org/r/20200319122737.3063291-4-thierry.reding@gmail.com Tested-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
| * | gpio: tegra186: Add support for pin rangesThierry Reding2020-03-271-0/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for Tegra SoC generations to specify a list of pin ranges that map GPIOs to ranges of pins in the pin controller. Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://lore.kernel.org/r/20200319122737.3063291-3-thierry.reding@gmail.com Tested-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
| * | gpio: Support GPIO controllers without pin-rangesThierry Reding2020-03-271-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Wake gpiochip_generic_request() call into the pinctrl helpers only if a GPIO controller had any pin-ranges assigned to it. This allows a driver to unconditionally use this helper if it supports multiple devices of which only a subset have pin-ranges assigned to them. Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://lore.kernel.org/r/20200319122737.3063291-2-thierry.reding@gmail.com Tested-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
| * | gpio: brcmstb: support gpio-line-names propertyDoug Berger2020-03-261-0/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The default handling of the gpio-line-names property by the gpiolib-of implementation does not work with the multiple gpiochip banks per device structure used by the gpio-brcmstb driver. This commit adds driver level support for the device tree property so that GPIO lines can be assigned friendly names. Signed-off-by: Doug Berger <opendmb@gmail.com> Link: https://lore.kernel.org/r/1583780521-45702-1-git-send-email-opendmb@gmail.com Acked-by: Gregory Fong <gregory.0xf0@gmail.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
| * | gpiolib: gpio_name_to_desc: factor out !name checkMichał Mirosław2020-03-251-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | Since name == NULL can't ever match, move the check out of IRQ-disabled region. Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
| * | gpio: mt7621: add BGPIOF_NO_SET_ON_INPUT flagChuanhong Guo2020-03-251-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DSET/DCLR registers only works on output pins. Add corresponding BGPIOF_NO_SET_ON_INPUT flag to bgpio_init call to fix direction_out behavior. Signed-off-by: Chuanhong Guo <gch981213@gmail.com> Tested-by: René van Dorst <opensource@vdorst.com> Reviewed-by: Sergio Paracuellos <sergio.paracuellos@gmail.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
| * | gpio: mmio: introduce BGPIOF_NO_SET_ON_INPUTChuanhong Guo2020-03-251-4/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some gpio controllers ignores pin value writing when that pin is configured as input mode. As a result, bgpio_dir_out should set pin to output before configuring pin values or gpio pin values can't be set up properly. Introduce two variants of bgpio_dir_out: bgpio_dir_out_val_first and bgpio_dir_out_dir_first, and assign direction_output according to a new flag: BGPIOF_NO_SET_ON_INPUT. Signed-off-by: Chuanhong Guo <gch981213@gmail.com> Tested-by: René van Dorst <opensource@vdorst.com> Reviewed-by: Sergio Paracuellos <sergio.paracuellos@gmail.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
| * | gpio: mvebu: avoid error message for optional IRQChris Packham2020-03-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | platform_get_irq() will generate an error message if the requested irq is not present mvebu-gpio f1010140.gpio: IRQ index 3 not found use platform_get_irq_optional() to avoid the error message being generated. Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
| * | gpio: mxs: add COMPILE_TEST support for GPIO_MXSAnson Huang2020-03-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Add COMPILE_TEST support to GPIO_MXS driver for better compile testing coverage. Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
| * | gpio: mxc: Add COMPILE_TEST support for GPIO_MXCAnson Huang2020-03-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Add COMPILE_TEST support to GPIO_MXC driver for better compile testing coverage. Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
| * | gpio: pl061: Warn when IRQ line has not been configuredAlexander Sverdlin2020-03-251-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Existing (irq < 0) condition is always false because adev->irq has unsigned type and contains 0 in case of failed irq_of_parse_and_map(). Up to now all the mapping errors were silently ignored. Seems that repairing this check would be backwards-incompatible and might break the probe() for the implementations without IRQ support. Therefore warn the user instead. Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nokia.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
| * | gpio: Move devres calls to devres fileLinus Walleij2020-03-202-46/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These two devres functions devm_gpiochip_[add|remove]() were in the wrong file. They should be in gpiolib-devres.c not gpiolib.c. Link: https://lore.kernel.org/r/20200313081522.35143-1-linus.walleij@linaro.org Reviewed-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
| * | Merge branch 'ib-omap-block-idle' into develLinus Walleij2020-03-091-15/+14
| |\ \
| | * | Revert "gpio: omap: Fix lost edge wake-up interrupts"Tony Lindgren2020-03-091-11/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit a522f1d0c381c42f3ace13b8bbeeccabdd6d2e5c. With cpu_pm handling fixed for omaps, and with gpio-omap now returning notify error on pending interrupts, we can drop the old workaround for seeing if there may be pending edge interrupts. Depends-on: ARM: OMAP2+: Handle errors for cpu_pm Depends-on: gpio: omap: Block idle on pending gpio interrupts Cc: Aaro Koskinen <aaro.koskinen@iki.fi> Cc: Grygorii Strashko <grygorii.strashko@ti.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Ladislav Michl <ladis@linux-mips.org> Cc: Peter Ujfalusi <peter.ujfalusi@ti.com> Cc: Russell King <rmk+kernel@armlinux.org.uk> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20200304225433.37336-4-tony@atomide.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
generated by cgit v1.2.3 (git 2.25.1) at 2025-04-08 12:58:14 +0000