kernel/drivers/gpio, branch linux-6.9.y

gpio: pca953x: fix pca953x_irq_bus_sync_unlock race

2024-07-25T07:53:34Z

[ Upstream commit bfc6444b57dc7186b6acc964705d7516cbaf3904 ] Ensure that `i2c_lock' is held when setting interrupt latch and mask in pca953x_irq_bus_sync_unlock() in order to avoid races. The other (non-probe) call site pca953x_gpio_set_multiple() ensures the lock is held before calling pca953x_write_regs(). The problem occurred when a request raced against irq_bus_sync_unlock() approximately once per thousand reboots on an i.MX8MP based system. * Normal case 0-0022: write register AI|3a {03,02,00,00,01} Input latch P0 0-0022: write register AI|49 {fc,fd,ff,ff,fe} Interrupt mask P0 0-0022: write register AI|08 {ff,00,00,00,00} Output P3 0-0022: write register AI|12 {fc,00,00,00,00} Config P3 * Race case 0-0022: write register AI|08 {ff,00,00,00,00} Output P3 0-0022: write register AI|08 {03,02,00,00,01} *** Wrong register *** 0-0022: write register AI|12 {fc,00,00,00,00} Config P3 0-0022: write register AI|49 {fc,fd,ff,ff,fe} Interrupt mask P0 Signed-off-by: Ian Ray Link: https://lore.kernel.org/r/20240620042915.2173-1-ian.ray@gehealthcare.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin

gpiolib: of: add polarity quirk for TSC2005

2024-07-11T10:51:14Z

[ Upstream commit f8d76c2c313c56d5cb894a243dff4550f048278d ] DTS for Nokia N900 incorrectly specifies "active high" polarity for the reset line, while the chip documentation actually specifies it as "active low". In the past the driver fudged gpiod API and inverted the logic internally, but it was changed in d0d89493bff8. Fixes: d0d89493bff8 ("Input: tsc2004/5 - switch to using generic device properties") Signed-off-by: Dmitry Torokhov Acked-by: Linus Walleij Link: https://lore.kernel.org/r/ZoWXwYtwgJIxi-hD@google.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin

gpio: mmio: do not calculate bgpio_bits via "ngpios"

2024-07-11T10:51:11Z

[ Upstream commit f07798d7bb9c46d17d80103fb772fd2c75d47919 ] bgpio_bits must be aligned with the data bus width. For example, on a 32 bit big endian system and we only have 16 GPIOs. If we only assume bgpio_bits=16 we can never control the GPIO because the base address is the lowest address. low address high address ------------------------------------------------- | byte3 | byte2 | byte1 | byte0 | ------------------------------------------------- | NaN | NaN | gpio8-15 | gpio0-7 | ------------------------------------------------- Fixes: 55b2395e4e92 ("gpio: mmio: handle "ngpios" properly in bgpio_init()") Fixes: https://github.com/openwrt/openwrt/issues/15739 Reported-by: Mark Mentovai Signed-off-by: Shiji Yang Suggested-By: Mark Mentovai Reviewed-by: Jonas Gorski Tested-by: Lóránd Horváth Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/TYCP286MB089577B47D70F0AB25ABA6F5BCD52@TYCP286MB0895.JPNP286.PROD.OUTLOOK.COM Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin

gpiolib: of: fix lookup quirk for MIPS Lantiq

2024-07-11T10:51:10Z

[ Upstream commit 3645ffaf2b334abaf5f53e5ca0f47465d91e69d2 ] As it turns out, there is a large number of out-of-tree DTSes (in OpenWrt project) that used to specify incorrect (active high) polarity for the Lantiq reset GPIO, so to keep compatibility while they are being updated a quirk for force the polarity low is needed. Luckily these old DTSes used nonstandard name for the property ("gpio-reset" vs "reset-gpios") so the quirk will not hurt if there are any new devices that need inverted polarity as they can specify the right polarity in their DTS when using the standard "reset-gpios" property. Additionally the condition to enable the transition from standard to non-standard reset GPIO property name was inverted and the replacement name for the property was not correct. Fix this as well. Fixes: fbbbcd177a27 ("gpiolib: of: add quirk for locating reset lines with legacy bindings") Fixes: 90c2d2eb7ab5 ("MIPS: pci: lantiq: switch to using gpiod API") Reported-by: Martin Schiller Acked-by: Martin Schiller Signed-off-by: Dmitry Torokhov Link: https://lore.kernel.org/r/ZoLpqv1PN08xHioh@google.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin

gpiolib: cdev: Ignore reconfiguration without direction

2024-07-05T07:38:03Z

[ Upstream commit b440396387418fe2feaacd41ca16080e7a8bc9ad ] linereq_set_config() behaves badly when direction is not set. The configuration validation is borrowed from linereq_create(), where, to verify the intent of the user, the direction must be set to in order to effect a change to the electrical configuration of a line. But, when applied to reconfiguration, that validation does not allow for the unset direction case, making it possible to clear flags set previously without specifying the line direction. Adding to the inconsistency, those changes are not immediately applied by linereq_set_config(), but will take effect when the line value is next get or set. For example, by requesting a configuration with no flags set, an output line with GPIO_V2_LINE_FLAG_ACTIVE_LOW and GPIO_V2_LINE_FLAG_OPEN_DRAIN set could have those flags cleared, inverting the sense of the line and changing the line drive to push-pull on the next line value set. Skip the reconfiguration of lines for which the direction is not set, and only reconfigure the lines for which direction is set. Fixes: a54756cb24ea ("gpiolib: cdev: support GPIO_V2_LINE_SET_CONFIG_IOCTL") Signed-off-by: Kent Gibson Link: https://lore.kernel.org/r/20240626052925.174272-3-warthog618@gmail.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin

gpiolib: cdev: Disallow reconfiguration without direction (uAPI v1)

2024-07-05T07:38:03Z

[ Upstream commit 9919cce62f68e6ab68dc2a975b5dc670f8ca7d40 ] linehandle_set_config() behaves badly when direction is not set. The configuration validation is borrowed from linehandle_create(), where, to verify the intent of the user, the direction must be set to in order to effect a change to the electrical configuration of a line. But, when applied to reconfiguration, that validation does not allow for the unset direction case, making it possible to clear flags set previously without specifying the line direction. Adding to the inconsistency, those changes are not immediately applied by linehandle_set_config(), but will take effect when the line value is next get or set. For example, by requesting a configuration with no flags set, an output line with GPIOHANDLE_REQUEST_ACTIVE_LOW and GPIOHANDLE_REQUEST_OPEN_DRAIN requested could have those flags cleared, inverting the sense of the line and changing the line drive to push-pull on the next line value set. Ensure the intent of the user by disallowing configurations which do not have direction set, returning an error to userspace to indicate that the configuration is invalid. And, for clarity, use lflags, a local copy of gcnf.flags, throughout when dealing with the requested flags, rather than a mixture of both. Fixes: e588bb1eae31 ("gpio: add new SET_CONFIG ioctl() to gpio chardev") Signed-off-by: Kent Gibson Link: https://lore.kernel.org/r/20240626052925.174272-2-warthog618@gmail.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin

gpio: davinci: Validate the obtained number of IRQs

2024-07-05T07:38:01Z

[ Upstream commit 7aa9b96e9a73e4ec1771492d0527bd5fc5ef9164 ] Value of pdata->gpio_unbanked is taken from Device Tree. In case of broken DT due to any error this value can be any. Without this value validation there can be out of chips->irqs array boundaries access in davinci_gpio_probe(). Validate the obtained nirq value so that it won't exceed the maximum number of IRQs per bank. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: eb3744a2dd01 ("gpio: davinci: Do not assume continuous IRQ numbering") Signed-off-by: Aleksandr Mishin Link: https://lore.kernel.org/r/20240618144344.16943-1-amishin@t-argos.ru Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin

gpio: tqmx86: fix broken IRQ_TYPE_EDGE_BOTH interrupt type

2024-06-21T12:40:18Z

[ Upstream commit 90dd7de4ef7ba584823dfbeba834c2919a4bb55b ] The TQMx86 GPIO controller only supports falling and rising edge triggers, but not both. Fix this by implementing a software both-edge mode that toggles the edge type after every interrupt. Fixes: b868db94a6a7 ("gpio: tqmx86: Add GPIO from for this IO controller") Co-developed-by: Gregor Herburger Signed-off-by: Gregor Herburger Signed-off-by: Matthias Schiffer Link: https://lore.kernel.org/r/515324f0491c4d44f4ef49f170354aca002d81ef.1717063994.git.matthias.schiffer@ew.tq-group.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin

gpio: tqmx86: store IRQ trigger type and unmask status separately

2024-06-21T12:40:18Z

[ Upstream commit 08af509efdf8dad08e972b48de0e2c2a7919ea8b ] irq_set_type() should not implicitly unmask the IRQ. All accesses to the interrupt configuration register are moved to a new helper tqmx86_gpio_irq_config(). We also introduce the new rule that accessing irq_type must happen while locked, which will become significant for fixing EDGE_BOTH handling. Fixes: b868db94a6a7 ("gpio: tqmx86: Add GPIO from for this IO controller") Signed-off-by: Matthias Schiffer Link: https://lore.kernel.org/r/6aa4f207f77cb58ef64ffb947e91949b0f753ccd.1717063994.git.matthias.schiffer@ew.tq-group.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin

gpio: tqmx86: introduce shadow register for GPIO output value

2024-06-21T12:40:18Z

[ Upstream commit 9d6a811b522ba558bcb4ec01d12e72a0af8e9f6e ] The TQMx86 GPIO controller uses the same register address for input and output data. Reading the register will always return current inputs rather than the previously set outputs (regardless of the current direction setting). Therefore, using a RMW pattern does not make sense when setting output values. Instead, the previously set output register value needs to be stored as a shadow register. As there is no reliable way to get the current output values from the hardware, also initialize all channels to 0, to ensure that stored and actual output values match. This should usually not have any effect in practise, as the TQMx86 UEFI sets all outputs to 0 during boot. Also prepare for extension of the driver to more than 8 GPIOs by using DECLARE_BITMAP. Fixes: b868db94a6a7 ("gpio: tqmx86: Add GPIO from for this IO controller") Signed-off-by: Matthias Schiffer Reviewed-by: Andrew Lunn Link: https://lore.kernel.org/r/d0555933becd45fa92a85675d26e4d59343ddc01.1717063994.git.matthias.schiffer@ew.tq-group.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin