kernel/linux.git/drivers/gpio/Kconfig, branch v7.0.10

Merge tag 'ib-mfd-clk-gpio-power-regulator-rtc-v6.20' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd into gpio/for-next

2026-01-15T15:37:34+00:00

Immutable branch between MFD, Clk, GPIO, Power, Regulator and RTC due for the v6.20 merge window

gpio: Support ROHM BD72720 gpios

2026-01-13T12:50:08+00:00

The ROHM BD72720 has 6 pins which may be configured as GPIOs. The GPIO1 ... GPIO5 and EPDEN pins. The configuration is done to OTP at the manufacturing, and it can't be read at runtime. The device-tree is required to tell the software which of the pins are used as GPIOs. Keep the pin mapping static regardless the OTP. This way the user-space can always access the BASE+N for GPIO(N+1) (N = 0 to 4), and BASE + 5 for the EPDEN pin. Do this by setting always the number of GPIOs to 6, and by using the valid-mask to invalidate the pins which aren't configured as GPIOs. First two pins can be set to be either input or output by OTP. Direction can't be changed by software. Rest of the pins can be set as outputs only. All of the pins support generating interrupts. Support the Input/Output state getting/setting and the output mode configuration (open-drain/push-pull). Signed-off-by: Matti Vaittinen Reviewed-by: Linus Walleij Acked-by: Bartosz Golaszewski Link: https://patch.msgid.link/22e095ca92f0677ca3d3a768ad749629fc3c2006.1765804226.git.mazziesaccount@gmail.com Signed-off-by: Lee Jones

gpio: add gpio-line-mux driver

2026-01-02T09:59:50+00:00

Add a new driver which provides a 1-to-many mapping for a single real GPIO using a multiplexer. Each virtual GPIO corresponds to a multiplexer state which, if set for the multiplexer, connects the real GPIO to the corresponding virtual GPIO. This can help in various usecases. One practical case is the special hardware design of the Realtek-based XS1930-10 switch from Zyxel. It features two SFP+ ports/cages whose signals are wired directly to the switch SoC. Although Realtek SoCs are short on GPIOs, there are usually enough the fit the SFP signals without any hacks. However, Zyxel did some weird design and connected RX_LOS, MOD_ABS and TX_FAULT of one SFP cage onto a single GPIO line controlled by a multiplexer (the same for the other SFP cage). The single multiplexer controls the lines for both SFP and depending on the state, the designated 'signal GPIO lines' are connected to one of the three SFP signals. Because the SFP core/driver doesn't support multiplexer but needs single GPIOs for each of the signals, this driver fills the gap between both. It registers a gpio_chip, provides multiple virtual GPIOs and sets the backing multiplexer accordingly. Due to several practical issues, this is input-only and doesn't support IRQs. Signed-off-by: Jonas Jelonek Reviewed-by: Thomas Richard Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20251227180134.1262138-3-jelonek.jonas@gmail.com Signed-off-by: Bartosz Golaszewski

gpio: pca953x: Add support for TCAL6408 TCAL6416

2025-12-18T10:27:05+00:00

TCAL6408 and TCAL6416 supports latchable inputs and maskable interrupt. Tested on a TCAL6416, checked datasheets for the TCAL6408. They use the same programming model ad the NXP PCAL64xx, but support a lower supply power (1.08V to 3.6V) compared to PCAL (1.65V to 5.5V) Datasheet: https://www.ti.com/lit/ds/symlink/tcal6408.pdf Datasheet: https://www.ti.com/lit/ds/symlink/tcal6416.pdf Signed-off-by: Jan Remmet Link: https://lore.kernel.org/r/20251216-wip-jremmet-tcal6416rtw-v2-3-6516d98a9836@phytec.de Signed-off-by: Bartosz Golaszewski

gpio: realtek-otto: add COMPILE_TEST

2025-12-17T09:34:54+00:00

Allows the buildbots to test compilation. Signed-off-by: Rosen Penev Link: https://lore.kernel.org/r/20251217063229.38175-3-rosenp@gmail.com Signed-off-by: Bartosz Golaszewski

gpio: tb10x: fix OF_GPIO dependency

2025-12-06T10:48:19+00:00

Selecting OF_GPIO is generally not allowed, it always gets enabled when both GPIOLIB and OF are turned on. The tb10x driver now warns about this after it was enabled for compile-testing: WARNING: unmet direct dependencies detected for OF_GPIO Depends on [n]: GPIOLIB [=y] && OF [=n] && HAS_IOMEM [=y] Selected by [y]: - GPIO_TB10X [=y] && GPIOLIB [=y] && HAS_IOMEM [=y] && (ARC_PLAT_TB10X || COMPILE_TEST [=y]) OF_GPIO is not required for compile-testing and is already enabled when the driver is usable, so just drop the 'select' line. Fixes: 682fbb18e14c ("gpio: tb10x: allow building the module with COMPILE_TEST=y") Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20251205095429.1291866-1-arnd@kernel.org Signed-off-by: Bartosz Golaszewski

gpio: qixis: select CONFIG_REGMAP_MMIO

2025-12-05T08:51:27+00:00

The regmap drivers need to be selected by each user, without that there can be configurations that fail to link: x86_64-linux-ld: drivers/gpio/gpio-qixis-fpga.o: in function `qixis_cpld_gpio_probe': gpio-qixis-fpga.c:(.text+0x13a): undefined reference to `__devm_regmap_init_mmio_clk' Fixes: e88500247dc3 ("gpio: add QIXIS FPGA GPIO controller") Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20251204094928.1031494-1-arnd@kernel.org Signed-off-by: Bartosz Golaszewski

gpio: elkhartlake: Convert to auxiliary driver

2025-11-19T13:08:51+00:00

Since PCI device should not be abusing platform device, MFD parent to platform child path is no longer being pursued for this driver. Convert it to auxiliary driver, which will be used by EHL PSE auxiliary device. Signed-off-by: Raag Jadav Acked-by: Bartosz Golaszewski Reviewed-by: Andy Shevchenko Reviewed-by: Ilpo Järvinen Link: https://lore.kernel.org/r/20251112034040.457801-3-raag.jadav@intel.com Signed-off-by: Bartosz Golaszewski

Merge tag 'gpio/shared-gpios-for-v6.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git into gpio/for-next

2025-11-17T09:37:37+00:00

Immutable branch between the GPIO, ASoC and regulator trees for v6.19-rc1 Add better support for GPIOs shared by multiple consumers.

gpio: shared-proxy: implement the shared GPIO proxy driver

2025-11-17T09:16:51+00:00

Add a virtual GPIO proxy driver which arbitrates access to a single shared GPIO by multiple users. It works together with the core shared GPIO support from GPIOLIB and functions by acquiring a reference to a shared GPIO descriptor exposed by gpiolib-shared and making sure that the state of the GPIO stays consistent. In general: if there's only one user at the moment: allow it to do anything as if this was a normal GPIO (in essence: just propagate calls to the underlying real hardware driver). If there are more users: don't allow to change the direction set by the initial user, allow to change configuration options but warn about possible conflicts and finally: treat the output-high value as a reference counted, logical "GPIO enabled" setting, meaning: the GPIO value is set to high when the first user requests it to be high and back to low once the last user stops "voting" for high. Reviewed-by: Linus Walleij Acked-by: Linus Walleij Link: https://lore.kernel.org/r/20251112-gpio-shared-v4-4-b51f97b1abd8@linaro.org Signed-off-by: Bartosz Golaszewski