u-boot.git/drivers/gpio, branch next

Merge patch series "gpio: improve claim diagnostics and fix gpio-delay offset handling"

2026-08-19T14:48:18Z

Pranav Sanwal says: This series improves diagnosability of GPIO offset collisions and fixes four related bugs in the gpio-delay driver that were uncovered while debugging such a collision. Patch 1 logs, at dev_dbg() level, which label already holds a GPIO offset when a new request collides with it, from within dm_gpio_request() itself, so a collision can be root-caused from the uclass layer when actively debugging. Patch 2 adds the same diagnostic to the "gpio" command, at printf() level. -EBUSY from gpio_request() is a normal, expected result there (a pin already owned by a driver or hog), so the command already tolerates it silently; this patch only prints which label holds the pin on that already-tolerated path. Patch 3 fixes gpio_delay_probe()/gpio_delay_xlate() to size and validate against the driver's actual GPIO count (from its "gpios" property) instead of a hardcoded 32, correctly sizing the claimed/name tracking arrays and matching the pattern used by the generic uclass xlate implementation. Patch 4 fixes gpio_delay_xlate() to propagate the requested index into desc->offset. Previously every consumer's descriptor came back with offset 0 regardless of which index was requested, so on boards where gpio-delay wraps more than one real GPIO line, every consumer past the first silently collided with the first consumer's already-claimed offset 0 and was never toggled. This was the root cause behind the series; the other patches are diagnostic and robustness fixes found along the way. Patch 5 adds a .remove hook to gpio-delay to release the real GPIOs it wraps. The driver requests them via gpio_request_by_name_nodev(), which strdup()s a label into the wrapped device's own uc_priv->name[]; with no .remove, those requests and labels were never released on teardown. Patch 6 fixes a related pre-existing leak: gpio_delay_probe() bailed out on the first failed GPIO request without freeing the ones it had already requested, and patch 5's new .remove hook doesn't cover this either since .remove is only called for devices that finished probing. Patches 3-6 are tagged Fixes: c866f2f197e2 ("gpio: Add GPIO delay driver"). Link: https://lore.kernel.org/r/20260811105314.3837228-1-pranav.sanwal@amd.com

gpio: delay: free already-requested GPIOs on probe failure

2026-08-19T14:48:14Z

gpio_delay_probe() requests each wrapped real GPIO in a loop and returns immediately if gpio_request_by_name_nodev() fails partway through, without freeing the GPIOs it already successfully requested. gpio_delay_remove() does not cover this either, since .remove is only called for devices that finished probing. Free what was already requested via the same gpio_delay_free_wrapped() helper gpio_delay_remove() uses, bounded by the number of GPIOs actually requested so far rather than the full gpio_count. Fixes: b86fa3fd24cb ("gpio: Add GPIO delay driver") Suggested-by: Simon Glass Signed-off-by: Pranav Sanwal Reviewed-by: Simon Glass

gpio: delay: free wrapped real GPIOs on remove

2026-08-19T14:48:11Z

gpio_delay_probe() requests the real GPIOs it wraps via gpio_request_by_name_nodev(), which strdup()s a label into the real GPIO device's own uc_priv->name[] array. The driver had no .remove hook, so those requests, and their strdup'd labels, were never released when the gpio-delay device was torn down. Add gpio_delay_remove() to free each wrapped real GPIO. Guard each free with device_active() on the real GPIO's device: generic DM teardown (e.g. dm_leak_check_end()'s uclass-by-uclass destroy) does not guarantee a consumer is removed before the provider it wraps, so the real GPIO device may already be inactive with its uclass_priv freed by the time this runs. Fixes: b86fa3fd24cb ("gpio: Add GPIO delay driver") Signed-off-by: Pranav Sanwal Reviewed-by: Simon Glass

gpio: delay: fix offset propagation in gpio_delay_xlate()

2026-08-19T14:48:08Z

gpio_delay_xlate() indexed priv->descs[] correctly using args->args[0], but never propagated that same index into desc->offset. Since gpio_desc_init() initializes offset to 0 before xlate() runs, every consumer's returned descriptor ended up with offset 0 regardless of which index it actually requested. On boards where gpio-delay wraps more than one real GPIO line, this caused every consumer past the first to silently collide with the first consumer's already-claimed offset 0 in dm_gpio_request(), which returns -EBUSY. The second consumer's real GPIO line was therefore never toggled. Fix gpio_delay_xlate() to record the requested index into desc->offset so each consumer's descriptor is routed to the correct underlying real GPIO. Fixes: b86fa3fd24cb ("gpio: Add GPIO delay driver") Signed-off-by: Pranav Sanwal Reviewed-by: Simon Glass

gpio: delay: set gpio_count and validate index against it

2026-08-19T14:47:32Z

gpio_delay_probe() never set the uclass's gpio_count for this device, leaving it at 0. This left gpio_post_probe()'s claimed/name tracking arrays sized for zero entries, and left gpio_delay_xlate()'s bounds check validating the requested index against a hardcoded 32 that has no relation to how many lines this instance actually manages (ngpio, from its own "gpios" property). Set gpio_count in probe() to the real count, and validate against it in xlate(), matching the pattern already used by the generic gpio_xlate_offs_flags() default implementation. Fixes: b86fa3fd24cb ("gpio: Add GPIO delay driver") Signed-off-by: Pranav Sanwal Reviewed-by: Simon Glass

gpio: uclass: log when a gpio offset is already claimed

2026-08-19T01:11:15Z

dm_gpio_request() returns -EBUSY when the requested offset is already claimed, but gives no indication of which label already holds it. Any caller going through the uclass API directly, rather than the "gpio" command, has no way to see this at all. Log it at dev_dbg() level: silent by default, available when actively debugging with this device's debug output enabled. Signed-off-by: Pranav Sanwal Reviewed-by: Simon Glass

gpio: vybrid: read and write the GPIO block, not the PORT block

2026-08-14T19:14:01Z

The Vybrid GPIO node describes two register ranges: the PORT block, which holds the pin control and interrupt registers, and the GPIO block, which holds the registers this driver touches (PDOR, PSOR, PCOR, PTOR, PDIR): gpio0: gpio@40049000 { compatible = "fsl,vf610-gpio"; reg = <0x40049000 0x1000 0x400ff000 0x40>; vybrid_gpio_odata_to_plat() takes the first range, so every set, clear and read goes to the PORT block: an output never changes level, an input returns a pin control register, and the write lands on the pin control register of an unrelated pad. The gpio command reports success either way. The direction is not affected. imx_iomux_gpio_set_direction() applies IOMUXC itself, so a pin requested as an output is driven, but always to the reset value of PDOR. The single range device tree this driver was written against described the GPIO block alone: gpio1: gpio@400ff000 { compatible = "fsl,vf610-gpio"; reg = <0x400ff000 0x40>; so the first range was the right one until the device trees were synchronised with Linux. Take the second range when the node has one and keep the first as the fallback, which is what the Linux driver does for the single range imx7ulp binding. Tested on a Colibri VF50: with the fix "gpio set 50" sets bit 18 of PDOR in the GPIO block at 0x400ff040 and the pin drives its load, and the display reset and backlight lines the board wires to GPIOs work again. Without it the register never changes. Fixes: e8a9521e649f ("vf500/vf610: synchronise device trees with linux") Signed-off-by: Mehmet Fide

gpio: add gpio driver for Spacemit K1 SoC

2026-07-21T09:42:44Z

Enable gpio driver for Spacemit K1 SoC. Signed-off-by: Raymond Mao Signed-off-by: Guodong Xu

gpio: mpc8xxx: add set_flags/get_flags ops

2026-07-06T01:59:58Z

mpc8xxx_gpio_open_drain_on() / _off() helpers can program GPODR (open-drain enable) on QorIQ silicon, but they are not called. The open-drain capability is therefore unreachable from the GPIO uclass. Adding a set_flags op for the GPIOD_OPEN_DRAIN, plus a get_flags for the reports of state by reading GPDIR and GPODR back. For existing callers, it is unchanged: direction_input, direction_output, get_value, set_value and get_function still drive the same registers as before. The new ops only become observable when a caller explicitly asks for the GPIOD_OPEN_DRAIN flag (or queries flags via the uclass). Signed-off-by: Vincent Jardin Signed-off-by: Peng Fan

treewide: Staticize and constify acpi ops

2026-06-29T21:29:44Z

Set the acpi_ops structure as static const where applicable. The The structure is not accessible from outside of drivers and is not going to be modified at runtime. The structure may be unused in a couple of drivers depending on their configuration, mark those sites with __maybe_unused . Signed-off-by: Marek Vasut Reviewed-by: Simon Glass