u-boot.git/drivers/gpio, branch v2025.10 Unnamed repository; edit this file 'description' to name the repository. gpio: zynq: Fix the documentation warning in zynq_gpio_get_bank_pin 2025-07-24T06:54:16+00:00 Venkatesh Yadav Abbarapu venkatesh.abbarapu@amd.com 2025-07-17T04:46:32+00:00 62c2c5d2479801f8d9a8c2e4c2d07c564010ea33 The 'dev' parameter in the zynq_gpio_get_bank_pin function was not described in its kernel-doc comment block, leading to a Sparse warning. drivers/gpio/zynq_gpio.c:194: warning: Function parameter or member 'dev' not described in 'zynq_gpio_get_bank_pin' Add a description for the 'dev' parameter to satisfy the documentation requirements and improve code clarity for this function. Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com> Link: https://lore.kernel.org/r/20250717044632.1353588-1-venkatesh.abbarapu@amd.com Signed-off-by: Michal Simek <michal.simek@amd.com> 
The 'dev' parameter in the zynq_gpio_get_bank_pin function was not
described in its kernel-doc comment block, leading to a Sparse warning.

drivers/gpio/zynq_gpio.c:194: warning: Function parameter or member 'dev'
not described in 'zynq_gpio_get_bank_pin'

Add a description for the 'dev' parameter to satisfy the documentation
requirements and improve code clarity for this function.

Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Link: https://lore.kernel.org/r/20250717044632.1353588-1-venkatesh.abbarapu@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
gpio: add PolarFire SoC GPIO and Core GPIO driver 2025-07-17T06:37:36+00:00 Eoin Dickson eoin.dickson@microchip.com 2025-07-08T13:01:20+00:00 63e8a80cb360a85b9c22f9b5bdb45eee9eeb8a40 This driver adds GPIO support for PolarFire SoC family, this is required to add sd card support on the Beagle-V-Fire as it uses GPIO chip selects Signed-off-by: Eoin Dickson <eoin.dickson@microchip.com> Acked-by: Leo Yu-Chi Liang <ycliang@andestech.com> 
This driver adds GPIO support for PolarFire SoC family, this is required
to add sd card support on the Beagle-V-Fire as it uses GPIO chip selects

Signed-off-by: Eoin Dickson <eoin.dickson@microchip.com>
Acked-by: Leo Yu-Chi Liang <ycliang@andestech.com>
gpio: add SPL to Kconfig option description 2025-07-14T18:44:04+00:00 Philip Molloy philip.molloy@analog.com 2025-07-07T13:06:38+00:00 b4c65b337aab7446b03dab6f22b289c88e4c0053 DM_GPIO_LOOKUP_LABEL and SPL_DM_GPIO_LOOKUP_LABEL had the same description and therefore appeared to be duplicates in Kconfig frontends Signed-off-by: Philip Molloy <philip.molloy@analog.com> 
DM_GPIO_LOOKUP_LABEL and SPL_DM_GPIO_LOOKUP_LABEL had the same
description and therefore appeared to be duplicates in Kconfig frontends

Signed-off-by: Philip Molloy <philip.molloy@analog.com>
Merge tag 'qcom-main-20250714' of https://source.denx.de/u-boot/custodians/u-boot-snapdragon 2025-07-14T14:54:19+00:00 Tom Rini trini@konsulko.com 2025-07-14T14:54:19+00:00 235e14b0f1ad7cfd46e18635f22a3cba7209c766 CI: https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/pipelines/27056 - Fix unused access in ufetch - Add missing clock for SM8650 - Port the Linux SPMI GPIO driver and port over SM8550 (other platforms should follow) 
CI: https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/pipelines/27056

- Fix unused access in ufetch
- Add missing clock for SM8650
- Port the Linux SPMI GPIO driver and port over SM8550 (other platforms
  should follow)
gpio: qcom: move pm8550 gpio to new driver 2025-07-14T13:35:24+00:00 Neil Armstrong neil.armstrong@linaro.org 2025-06-30T16:04:45+00:00 d8da51a87c2a73b3f6aa2bf38a8db91b16cc30a9 Move support of the pm8550 gpios to the newly introduced driver and drop the compatible entry and the read-only quirk at the same time from the old driver. Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Rui Miguel Silva <rui.silva@linaro.org> Acked-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250630-topic-sm8x50-pmic-gpio-pinctrl-new-v2-2-cc1512931197@linaro.org Signed-off-by: Casey Connolly <casey.connolly@linaro.org> 
Move support of the pm8550 gpios to the newly introduced
driver and drop the compatible entry and the read-only quirk
at the same time from the old driver.

Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Rui Miguel Silva <rui.silva@linaro.org>
Acked-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250630-topic-sm8x50-pmic-gpio-pinctrl-new-v2-2-cc1512931197@linaro.org
Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
gpio: qcom: add new driver for SPMI gpios 2025-07-14T13:35:24+00:00 Neil Armstrong neil.armstrong@linaro.org 2025-06-30T16:04:44+00:00 d0ceeb944a4dba7f6893616cd80da7e95db72ba4 The current qcom_pmic_gpio driver is too limited and doesn't support state tracking for all pins like the Linux driver. Adding full pinconf support would require adding the state and it's much simpler to restart from scratch with a new driver based on the Linux one adapted to the U-Boot GPIO and Pinctrl APIs. For now only the PMICs I've been able to validate are added in the compatible list but we should be able to add the entire list from the Linux driver. There's a few difference from the Linux driver: - no IRQ support - uses the U-Boot GPIO flags that maps very well - uses the gpio-ranges to get the pins count - no debugfs but prints the pin state via pinmux callback It uses the same CONFIG entry as the old one, since the ultimate goal is to migrate entirely on this new driver once we verify it doesn't break the older platforms. Tested-by: Alexey Minnekhanov <alexeymin@postmarketos.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Rui Miguel Silva <rui.silva@linaro.org> Acked-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250630-topic-sm8x50-pmic-gpio-pinctrl-new-v2-1-cc1512931197@linaro.org Signed-off-by: Casey Connolly <casey.connolly@linaro.org> 
The current qcom_pmic_gpio driver is too limited and doesn't
support state tracking for all pins like the Linux driver.

Adding full pinconf support would require adding the state
and it's much simpler to restart from scratch with a new
driver based on the Linux one adapted to the U-Boot GPIO
and Pinctrl APIs.

For now only the PMICs I've been able to validate are
added in the compatible list but we should be able to
add the entire list from the Linux driver.

There's a few difference from the Linux driver:
- no IRQ support
- uses the U-Boot GPIO flags that maps very well
- uses the gpio-ranges to get the pins count
- no debugfs but prints the pin state via pinmux callback

It uses the same CONFIG entry as the old one, since
the ultimate goal is to migrate entirely on this new
driver once we verify it doesn't break the older
platforms.

Tested-by: Alexey Minnekhanov <alexeymin@postmarketos.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Rui Miguel Silva <rui.silva@linaro.org>
Acked-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250630-topic-sm8x50-pmic-gpio-pinctrl-new-v2-1-cc1512931197@linaro.org
Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
gpio: Tighten some gpio driver dependencies 2025-07-10T14:40:50+00:00 Tom Rini trini@konsulko.com 2025-07-02T01:04:02+00:00 8a31f18269e28b3201630e96e4d2821dbba0eb70 A large number of gpio drivers cannot build without access to some platform specific header files. Express those requirements in Kconfig as well. Signed-off-by: Tom Rini <trini@konsulko.com> 
A large number of gpio drivers cannot build without access to some platform
specific header files. Express those requirements in Kconfig as well.

Signed-off-by: Tom Rini <trini@konsulko.com>
gpio: Remove tca642x support 2025-07-09T16:39:25+00:00 Tom Rini trini@konsulko.com 2025-07-01T18:42:28+00:00 e6d7477103bc94a58460bbf2f12290f4f327fbc8 This driver has no users after we removed the last supported platform in 2023. Fixes: 7a3ee61f5551 ("arm: Remove omap5_uevm board") Signed-off-by: Tom Rini <trini@konsulko.com> 
This driver has no users after we removed the last supported platform in
2023.

Fixes: 7a3ee61f5551 ("arm: Remove omap5_uevm board")
Signed-off-by: Tom Rini <trini@konsulko.com>
gpio: msm_gpio: return correct value for gpio read 2025-06-24T13:53:33+00:00 Aswin Murugan aswin.murugan@oss.qualcomm.com 2025-05-08T11:36:46+00:00 ddc527ac4331b3cc73f29d30127944f477d6a6f0 In the current implementation, the GPIO read operation considers both the input and outbut bits (bits 0 and 1). It should only consider the state of input bit, i.e bit 0. To address this, mask input bit alone and read it. Signed-off-by: Aswin Murugan <aswin.murugan@oss.qualcomm.com> Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Reviewed-by: Casey Connolly <casey.connolly@linaro.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250508113646.1462518-1-aswin.murugan@oss.qualcomm.com Signed-off-by: Casey Connolly <casey.connolly@linaro.org> 
In the current implementation, the GPIO read operation considers
both the input and outbut bits (bits 0 and 1). It should only consider
the state of input bit, i.e bit 0. To address this, mask input bit
alone and read it.

Signed-off-by: Aswin Murugan <aswin.murugan@oss.qualcomm.com>
Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Reviewed-by: Casey Connolly <casey.connolly@linaro.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20250508113646.1462518-1-aswin.murugan@oss.qualcomm.com
Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
Merge patch series "Start removing <env.h> from headers when not required" 2025-05-29T14:29:24+00:00 Tom Rini trini@konsulko.com 2025-05-29T14:29:24+00:00 e50dbb3a0a31e6c41a752605e136c09df98d8800 Tom Rini <trini@konsulko.com> says: Given Simon's series at [1] I started looking in to what brings in <env.h> when not strictly required and in turn has some unintended implicit includes. This series takes care of the places where, commonly, <linux/string.h> or <env.h> itself were required along with a few other less common cases. This sets aside for the moment what to do about net-common.h and env_get_ip() as I'm not entirely sure what's best there. [1]: https://patchwork.ozlabs.org/project/uboot/list/?series=454939&state=* Link: https://lore.kernel.org/r/20250514225002.15361-1-trini@konsulko.com 
Tom Rini <trini@konsulko.com> says:

Given Simon's series at [1] I started looking in to what brings in
<env.h> when not strictly required and in turn has some unintended
implicit includes. This series takes care of the places where, commonly,
<linux/string.h> or <env.h> itself were required along with a few other
less common cases. This sets aside for the moment what to do about
net-common.h and env_get_ip() as I'm not entirely sure what's best
there.

[1]: https://patchwork.ozlabs.org/project/uboot/list/?series=454939&state=*
Link: https://lore.kernel.org/r/20250514225002.15361-1-trini@konsulko.com