- Jan 03, 2022
-
-
Steven Lee authored
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>
-
- Dec 21, 2021
-
-
Vincent Whitchurch authored
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: 3a29355a ("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>
-
- Dec 19, 2021
-
-
Noralf Trønnes authored
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>
-
- Nov 16, 2021
-
-
Randy Dunlap authored
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: 936ee267 ("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>
-
- Nov 15, 2021
-
-
Yang Li authored
Eliminate the following coccicheck warning: ./drivers/gpio/gpio-virtio.c:437:2-3: Unneeded semicolon Reported-by:
Abaci Robot <abaci@linux.alibaba.com> Signed-off-by:
Yang Li <yang.lee@linux.alibaba.com> Acked-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
Bartosz Golaszewski <brgl@bgdev.pl>
-
- Nov 04, 2021
-
-
Viresh Kumar authored
This patch adds IRQ support for the virtio GPIO driver. Note that this uses the irq_bus_lock/unlock() callbacks, since those operations over virtio may sleep. Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Viresh Kumar <viresh.kumar@linaro.org> Acked-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
Bartosz Golaszewski <brgl@bgdev.pl>
-
- Oct 30, 2021
-
-
Sander Vanheule authored
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: 0d82fb11 ("gpio: Add Realtek Otto GPIO support") Signed-off-by:
Sander Vanheule <sander@svanheule.net> Signed-off-by:
Bartosz Golaszewski <brgl@bgdev.pl>
-
Randy Dunlap authored
Fix multiple problems in punctuation, capitalization, grammar, wording, and typos in the GPIO Kconfig file. Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Bartosz Golaszewski <brgl@bgdev.pl> Cc: linux-gpio@vger.kernel.org Cc: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Sean Young <sean@mess.org> Cc: Bamvor Jian Zhang <bamv2005@gmail.com> Cc: Michael Walle <michael@walle.cc> Acked-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by:
Bartosz Golaszewski <brgl@bgdev.pl>
-
- Oct 29, 2021
-
-
Asmaa Mnebhi authored
Introduce standard IRQ handling in the gpio-mlxbf2.c driver. Signed-off-by:
Asmaa Mnebhi <asmaa@nvidia.com> Acked-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Bartosz Golaszewski <brgl@bgdev.pl>
-
- Oct 26, 2021
-
-
The core gpiolib code is able to deal with multiple interrupt parents for a single gpio irqchip. It however only allows a single piece of data to be conveyed to all flow handlers (either the gpio_chip or some other, driver-specific data). This means that drivers have to go through some interesting dance to find the correct context, something that isn't great in interrupt context (see aebdc8ab for a prime example). Instead, offer an optional way for a pinctrl/gpio driver to provide an array of pointers which gets used to provide the correct context to the flow handler. Signed-off-by:
Marc Zyngier <maz@kernel.org> Signed-off-by:
Joey Gouly <joey.gouly@arm.com> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20211026175815.52703-2-joey.gouly@arm.com Signed-off-by:
Linus Walleij <linus.walleij@linaro.org>
-
Rafael J. Wysocki authored
The ACPI_HANDLE() macro is a wrapper arond the ACPI_COMPANION() macro and the ACPI handle produced by the former comes from the ACPI device object produced by the latter, so it is way more straightforward to evaluate the latter directly instead of passing the handle produced by the former to acpi_bus_get_device(). Modify pt_gpio_probe() accordingly (no intentional functional impact). Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by:
Bartosz Golaszewski <brgl@bgdev.pl>
-
- Oct 25, 2021
-
-
Asmaa Mnebhi authored
Add a check if bgpio_init fails. Signed-off-by:
Asmaa Mnebhi <asmaa@nvidia.com> Signed-off-by:
Bartosz Golaszewski <brgl@bgdev.pl>
-
Jonas Gorski authored
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: 6a41b6c5 ("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>
-
- Oct 20, 2021
-
-
Andy Shevchenko authored
Since driver core provides a generic device_match_acpi_handle() we may replace the custom code with it. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/20211014134756.39092-3-andriy.shevchenko@linux.intel.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- Oct 13, 2021
-
-
Uwe Kleine-König authored
An spi remove callback is only called for devices that probed successfully. In this case this implies that mc33880_probe() set a non-NULL driver data. So the check for mc being NULL is never true and the check can be dropped. Also the return value ofspi remove callbacks is ignored anyway. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Bartosz Golaszewski <brgl@bgdev.pl>
-
Uwe Kleine-König authored
An spi or i2c remove callback is only called for devices that probed successfully. In this case this implies that __max730x_probe() set a non-NULL driver data. So the check ts == NULL is never true. With this check dropped, __max730x_remove() returns zero unconditionally. Make it return void instead which makes it easier to see in the callers that there is no error to handle. Also the return value of i2c and spi remove callbacks is ignored anyway. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Bartosz Golaszewski <brgl@bgdev.pl>
-
Geert Uytterhoeven authored
The tmp[] member of the gpiochip_fwd structure is used to store both the temporary values bitmap and the desc pointers for operations on multiple GPIOs. As both are arrays with sizes unknown at compile-time, accessing them requires offset calculations, which are currently duplicated in gpio_fwd_get_multiple() and gpio_fwd_set_multiple(). Introduce (a) accessors for both arrays and (b) a macro to calculate the needed storage size. This confines the layout of the tmp[] member into a single spot, to ease maintenance. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
Bartosz Golaszewski <brgl@bgdev.pl>
-
- Oct 06, 2021
-
-
Andy Shevchenko authored
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 bd1e336a ("driver core: platform: Remove platform_device_add_properties()"). Hence, it's used as a landmark for backporting. Fixes: bd1e336a ("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>
-
Andy Shevchenko authored
The commit 15add068 ("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: 15add068 ("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>
-
Mark Brown authored
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: 96c8395e ("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>
-
- Sep 29, 2021
-
-
Andrey Gusakov authored
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>
-
- Sep 23, 2021
-
-
Piyush Mehta authored
This patch adds driver support for the zynqmp modepin GPIO controller. GPIO modepin driver set and get the value and status of the PS_MODE pin, based on device-tree pin configuration. These four mode pins are configurable as input/output. The mode pin has a control register, which have lower four-bits [0:3] are configurable as input/output, next four-bits can be used for reading the data as input[4:7], and next setting the output pin state output[8:11]. By default value of mode pin register is 0. Signed-off-by:
Piyush Mehta <piyush.mehta@xilinx.com> Acked-by:
Michal Simek <michal.simek@xilinx.com> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Bartosz Golaszewski <brgl@bgdev.pl>
-
- Sep 22, 2021
-
-
Krzysztof Kozlowski authored
The MODULE_DEVICE_TABLE already creates proper alias for platform driver. Having another MODULE_ALIAS causes the alias to be duplicated. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by:
Bartosz Golaszewski <brgl@bgdev.pl>
-
Krzysztof Kozlowski authored
The MODULE_DEVICE_TABLE already creates proper alias for platform driver. Having another MODULE_ALIAS causes the alias to be duplicated. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by:
Bartosz Golaszewski <brgl@bgdev.pl>
-
Wolfram Sang authored
We should get 'driver_data' from 'struct device' directly. Going via platform_device is an unneeded step back and forth. Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by:
Bartosz Golaszewski <brgl@bgdev.pl>
-
Heiko Stuebner authored
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: 3bcbd1a8 ("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>
-
Heiko Stuebner authored
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: 3bcbd1a8 ("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>
-
Thierry Reding authored
Tegra194 and later support more than a single interrupt per bank. This is primarily useful for virtualization but can also be helpful for more fine-grained CPU affinity control. To keep things simple for now, route all pins to the first interrupt. For backwards-compatibility, support old device trees that specify only one interrupt per bank by counting the interrupts at probe time. Signed-off-by:
Thierry Reding <treding@nvidia.com> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Bartosz Golaszewski <brgl@bgdev.pl>
-
Thierry Reding authored
Newer chips support up to 8 interrupts per bank, which can be useful to balance the load and decrease latency. However, it also required a very complicated interrupt routing to be set up. To keep things simple for now, ensure that a single interrupt per bank is enforced, even if all possible interrupts are described in device tree. Signed-off-by:
Thierry Reding <treding@nvidia.com> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Bartosz Golaszewski <brgl@bgdev.pl>
-
Steven Lee authored
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>
-
Kunihiko Hayashi authored
Use helper functions to get private data from IRQ data instead of direct access. No functional changes intended. Signed-off-by:
Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Signed-off-by:
Bartosz Golaszewski <brgl@bgdev.pl>
-
Kunihiko Hayashi authored
Use helper function to get IRQ hardware number instead of direct access. No functional changes intended. Signed-off-by:
Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Signed-off-by:
Bartosz Golaszewski <brgl@bgdev.pl>
-
Kunihiko Hayashi authored
The return type of irq_chip.irq_mask() and irq_chip.irq_unmask() should be void. Fixes: dbe776c2 ("gpio: uniphier: add UniPhier GPIO controller driver") Signed-off-by:
Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Signed-off-by:
Bartosz Golaszewski <brgl@bgdev.pl>
-
Hans de Goede authored
Commit 8dcb7a15 ("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: 8dcb7a15 ("gpiolib: acpi: Take into account debounce settings") Depends-on: 2e2b496c ("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>
-
- Sep 17, 2021
-
-
Fetch the output settings the pinctrl driver may have created for pinctrl hogs and set the relevant pins as requested. Fixes: 9ce9a020 ("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>
-
- Aug 31, 2021
-
-
Christophe JAILLET authored
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: 698b8eea ("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>
-
Christophe JAILLET authored
Commit 76c47d14 ("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: 76c47d14 ("gpio: mpc8xxx: Add ACPI support") Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
Bartosz Golaszewski <bgolaszewski@baylibre.com>
-
Christophe JAILLET authored
Commit 698b8eea ("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: 698b8eea ("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>
-
Alexandru Ardelean authored
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>
-
Viresh Kumar authored
Fix warnings reported by sparse, related to type mismatch between u16 and __le16. Reported-by:
kernel test robot <lkp@intel.com> Fixes: 3a29355a ("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>
-