u-boot.git/drivers/gpio, branch v2026.07

gpio: qcom_spmi_gpio: move PM8998 GPIO from legacy pmic driver

2026-06-10T11:36:18Z

Move the "qcom,pm8998-gpio" compatible from the legacy driver qcom_pmic_gpio.c to qcom_spmi_gpio.c. Enables on PM8998-based boards (sdm845: SHIFT 6mq, Pixel 3, OnePlus 6, Poco F1, Sony Xperia Akatsuki) the Volume UP gpio-key. Signed-off-by: Petr Hodina Reviewed-by: Casey Connolly Link: https://patch.msgid.link/20260605-qcom-gpio-v2-1-c34093041c66@protonmail.com Signed-off-by: Casey Connolly

gpio: 74x164: use dev_read_* APIs for live-tree compatibility

2026-04-30T19:57:49Z

With CONFIG_OF_LIVE=y, dev_of_offset(dev) does not return a valid flat-FDT offset, so fdtdec_get_int(gd->fdt_blob, offset, ...) inside gen_74x164_probe() fails to locate the "registers-number" property and always falls back to the default value of 1. This results in a 4-chip 74HC595 daisy chain being exposed as only 8 GPIOs instead of 32, and any consumer referencing offsets >= 8 fails to bind with -ENOENT ("GPIO ... not found" / Error -22). The "registers-default" property is ignored for the same reason, so any configured power-on output pattern is silently discarded. Replace the flat-FDT helpers with dev_read_u32_default() and dev_read_u8_array_ptr(), which correctly walk both live and flat trees. This matches how other DM GPIO drivers (e.g. pca953x_gpio.c) read their per-device properties. With gd->fdt_blob no longer referenced, also drop the now-unused DECLARE_GLOBAL_DATA_PTR and include. Tested on stm32mp153d-ssonic (CONFIG_OF_LIVE=y) with a 4-chip 74HC595 chain: all 32 GPIOs are now exposed, and 16 consumer LED nodes at offsets 0..31 bind successfully. Fixes: 9300f711baac ("dm: gpio: introduce 74x164 driver") Signed-off-by: Chanhong Jung Reviewed-by: Simon Glass

gpio: qcom: Support GPIOs on PM7550 PMIC

2026-04-27T10:38:44Z

The GPIOs on PM7550 work fine using the qcom_spmi_gpio driver and enables the use of the Volume Up button on the Fairphone (Gen. 6) smartphone. Reviewed-by: Sumit Garg Signed-off-by: Luca Weiss Link: https://patch.msgid.link/20260318-milos-bringup-v2-5-650b91dd75d8@fairphone.com Signed-off-by: Casey Connolly

gpio: scmi: Add gpio_scmi driver

2026-04-09T02:14:39Z

This provides GPIO support over SCMI. It is built on top of the pinctrl-scmi driver. A typical device tree entry might look like this: gpio1 { compatible = "scmi-pinctrl-gpio"; gpio-controller; #gpio-cells = <2>; ngpios = <10>; gpio-ranges = <&scmi_pinctrl 0 8 4>, <&scmi_pinctrl 4 12 1>, <&scmi_pinctrl 5 15 1>, <&scmi_pinctrl 6 17 4>; pinctrl-names = "default"; pinctrl-0 = <&i2c2_pins>; }; In this GPIO driver the one thing which is different is that in the gpio-ranges the first numbers which represent how the pins are exposed to the users have to start at zero and it can't have gaps. Signed-off-by: Dan Carpenter Signed-off-by: Peng Fan

gpio: Correct dependencies for legacy CMD_PCA953X

2026-04-03T19:42:50Z

The legacy CMD_PCA953X command can only be built when the matching legacy driver is enabled, add that dependency to Kconfig. Signed-off-by: Tom Rini

Merge tag 'v2026.04-rc4' into next

2026-03-09T21:26:34Z

Prepare v2026.04-rc4

treewide: Remove Timesys from ADI ADSP maintenance

2026-03-04T20:25:27Z

After years of developing the ADI ADSP platform, Timesys was purchased by another company and is no longer contracted to maintain the platform. Signed-off-by: Philip Molloy Reviewed-by: Greg Malysa

gpio: stm32-gpio: prevent the use of the secure protected pins

2026-02-24T13:09:45Z

The hardware denies any access from the U-Boot non-secure world to the secure-protected pins. Hence, prevent any driver to request such a pin. Signed-off-by: Fabien Dessenne Signed-off-by: Patrice Chotard Reviewed-by: Patrick Delaunay

Merge patch series "treewide: Clean up usage of DECLARE_GLOBAL_DATA_PTR"

2026-02-17T19:51:26Z

Peng Fan (OSS) says: This patch set primarily removes unused DECLARE_GLOBAL_DATA_PTR instances. Many files declare DECLARE_GLOBAL_DATA_PTR and include asm/global_data.h even though gd is never used. In these cases, asm/global_data.h is effectively treated as a proxy header, which is not a good practice. Following the Include What You Use principle, files should include only the headers they actually depend on, rather than relying on global_data.h indirectly. This approach is also adopted in Linux kernel [1]. The first few patches are prepartion to avoid building break after remove the including of global_data.h. A script is for filtering the files: list=`find . -name "*.[ch]"` for source in ${list} do result=`sed -n '/DECLARE_GLOBAL_DATA_PTR/p' ${source}` if [ "${result}" == "DECLARE_GLOBAL_DATA_PTR;" ]; then echo "Found in ${source}" result=`sed -n '/\/p' ${source}` result2=`sed -n '/\/p' ${source}` if [ "${result}" == "" ] && [ "${result2}" == "" ] && [ "${result3}" == "" ];then echo "Cleanup ${source}" sed -i '/DECLARE_GLOBAL_DATA_PTR/{N;/\n[[:space:]]*$/d;s/.*\n//;}' ${source} sed -i '/DECLARE_GLOBAL_DATA_PTR/d' ${source} sed -i '/global_data.h/d' ${source} git add ${source} fi fi done [1] https://lpc.events/event/17/contributions/1620/attachments/1228/2520/Linux%20Kernel%20Header%20Optimization.pdf CI: https://github.com/u-boot/u-boot/pull/865 Link: https://lore.kernel.org/r/20260209-cleanup-v2-0-73a3a84ddbdb@nxp.com

treewide: Clean up DECLARE_GLOBAL_DATA_PTR usage

2026-02-17T19:50:22Z

Remove DECLARE_GLOBAL_DATA_PTR from files where gd is not used, and drop the unnecessary inclusion of asm/global_data.h. Headers should be included directly by the files that need them, rather than indirectly via global_data.h. Reviewed-by: Patrice Chotard #STMicroelectronics boards and STM32MP1 ram test driver Tested-by: Anshul Dalal #TI boards Acked-by: Yao Zi #TH1520 Signed-off-by: Peng Fan