OMAP GPIO driver needs TI_SYSC to initialize its clocks when
using a devicetree-based setup.
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Add support for the GPIO controller block in the R-Car Gen5 SoC family.
The GPIO controller has a General Input Enable Register (INEN), whose
reset state is to have all input disabled. The GPIO controller also has
updated offsets for its control registers. U-Boot uses three registers,
INDT, POSNEG, INEN, which have updated offsets, those are handled by the
driver.
Signed-off-by: Huy Bui <huy.bui.wm@renesas.com>
Signed-off-by: Hai Pham <hai.pham.ud@renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
[Marek: - Access Gen5 specific registers via driver data offsets,
- Update commit message]
The Renesas R-Car Gen5 GPIO controller has INDT, POSNEG, INEN registers
at different offsets compared to previous generations. Introduce three
new entries in struct rcar_gpio_data {} match data to describe these
register offsets for each GPIO controller. Update the driver to access
these three registers through the match data offsets. No functional
change.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Wrap the RCAR_GPIO_HAS_INEN quirk in more flexible struct rcar_gpio_data {}
in preparation for addition of Renesas R-Car Gen5 GPIO controller support.
The Renesas R-Car Gen5 GPIO controller requires more than a single quirk
to properly describe it, therefore increase the flexibility and introduce
full match data structure, and use it throughout the driver. No functional
change.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Remove register macros for registers which are not used by this driver.
This makes it easier to get an overview of which registers are really
used by the driver. No functional change.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
The PFC offset is no longer used directly in the driver since commit
fbf26bea3964 ("gpio: renesas: Migrate to pinctrl GPIO accessors")
Drop the pfc_offset parsing.
Fixes: fbf26bea3964 ("gpio: renesas: Migrate to pinctrl GPIO accessors")
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
If CONFIG_GPIO_HOG is not set, then gpio_hog_lookup_name() is empty,
and thus does not initialize any of its parameters. It does still
return 0 though, and so any calling function might assume that the
parameters have been initialized successfully.
Change the return value to -ENODEV in this case, as the function
would in the case when CONFIG_GPIO_HOG is set but the gpio hog
could not be found.
Signed-off-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
Reviewed-by: Heiko Schocher <hs@nabladev.com>
The GPIOs on PM7325 work fine using the qcom_spmi_gpio driver and
enables the use of the Volume Up button Fairphone 5 smartphone.
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20250917-spmi-gpio-pm7325-v1-1-6b75c2c62d8b@fairphone.com
Signed-off-by: Casey Connolly <kcxt@postmarketos.org>
The GPIOs on PM6350 work fine using the qcom_spmi_gpio driver and
enables the use of the Volume Up button Fairphone 4 smartphone.
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
This is used for the volume keys on some SDM670 devices.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: David Wronek <david.wronek@mainlining.org>
Link: https://lore.kernel.org/r/20251003-sdm670-v2-5-52c0fa481286@mainlining.org
Signed-off-by: Casey Connolly <kcxt@postmarketos.org>
Add support for the GPIOs in the PM6150L to the new driver.
Signed-off-by: Jens Reidel <adrian@mainlining.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Casey Connolly <casey.connolly@linaro.org>
Link: https://lore.kernel.org/r/20251005154443.71477-1-adrian@mainlining.org
Signed-off-by: Casey Connolly <kcxt@postmarketos.org>
In intel_gpio_set_flags the two variables or0 and or1 may be used
uninitialised. Correct this by setting initial values in the
declaration.
Also there is no need to use '|=' when the initial value is 0 and there
is only one assignment performed to each variable so just use '='
instead.
This issue was found by Smatch.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
This driver has never been enabled and currently has build problems
related in part to incorrect out_le32 calls. Remove it.
Signed-off-by: Tom Rini <trini@konsulko.com>
Currently xilinx_pm_request API supports four u32 payloads. However the
legacy SMC format supports five u32 request payloads and extended SMC
format supports six u32 request payloads. Add support for the same in
xilinx_pm_request API. Also add two dummy arguments to all the callers
of xilinx_pm_request.
The TF-A always fills seven u32 return payload so add support
for the same in xilinx_pm_request API.
Signed-off-by: Naman Trivedi <naman.trivedimanojbhai@amd.com>
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Acked-by: Senthil Nathan Thangaraj <senthilnathan.thangaraj@amd.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/5ae6b560741f3ca8b89059c4ebb87acf75b4718e.1756388537.git.michal.simek@amd.com
All instances of the U_BOOT_DRIVER must use a unique name or they will
lead to link time failures due to name space conflicts when both are
present. In this case gpio-aspeed-g7 was using the same name as
gpio-aspeed.
Signed-off-by: Tom Rini <trini@konsulko.com>
mchp_gpio_get_value() should return int instead of bool, and some casts
are needed.
Signed-off-by: Eoin Dickson <eoin.dickson@microchip.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
The ADP5587 is a simpler version of the ADP5588. The ADP5588 can
configure two pins, C8 and C9, as GPIOs or light sensors. The ADP5587
does not include the light sensors.
Signed-off-by: Philip Molloy <philip@philipmolloy.com>
In gpio_dwapb_bind plat is used to reference memory allocated by
devm_kcalloc but it is attempted to be freed using kfree. Instead free
this memory using the correct devm_kfree function.
This issue was found by Smatch.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Acked-by: Quentin Schulz <quentin.schulz@cherry.de>
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>
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>
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>
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>
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>
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>
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>
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>
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
Releasing a GPIO on Tegra necessitates changing its configuration to SFIO
to activate its special function. Without this reconfiguration, the special
function will be unavailable.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Now that this functionality is modeled using the device tree and
regulator uclass, the named GPIO is not referenced anywhere. Remove
it, along with the rest of the support for AXP virtual GPIOs.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Tom Rini <trini@konsulko.com> says:
This series switches to always using $(PHASE_) in Makefiles when
building rather than $(PHASE_) or $(XPL_). It also starts on documenting
this part of the build, but as a follow-up we need to rename
doc/develop/spl.rst and expand on explaining things a bit.
Link: https://lore.kernel.org/r/20250401225851.1125678-1-trini@konsulko.com
It is confusing to have both "$(PHASE_)" and "$(XPL_)" be used in our
Makefiles as part of the macros to determine when to do something in our
Makefiles based on what phase of the build we are in. For consistency,
bring this down to a single macro and use "$(PHASE_)" only.
Signed-off-by: Tom Rini <trini@konsulko.com>
Some Qualcomm boards feature reserved ranges of pins which are protected
by firmware. Attempting to read or write any registers associated with
these pins results the board resetting.
Add support for parsing these ranges from devicetree and ensure that the
pinctrl and GPIO drivers don't try to interact with these pins.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250410-topic-sm8x50-pinctrl-reserved-ranges-v2-1-654488392b9a@linaro.org
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
When a special pin is output only, the current code would return 0,
but if the pin is output only we can get the output value.
Try to return the output value and in all the other cases return
an error instead of 0.
Fixes: f9bb539460d ("gpio: msm: add support for special pins")
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20250401-topic-sm8x50-msm-gpio-special-fixes-v1-2-a1148a02bb16@linaro.org
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
The get_function callback wrongly returns 0 for special pins,
return the appropriate pin function by probing into the special
pins data fields to find if the pin is gpio capable.
Fixes: f9bb539460d ("gpio: msm: add support for special pins")
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20250401-topic-sm8x50-msm-gpio-special-fixes-v1-1-a1148a02bb16@linaro.org
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
Greg Malysa <malysagreg@gmail.com> says:
This series adds all of the supported peripheral drivers for the sc5xx
series of SoCs from Analog Devices and other drivers that are used by
the evaluation kits, such as a GPIO expander used by the EZLITE carrier
boards. This series passes gitlab CI tests.
Link: https://lore.kernel.org/r/20250226173150.13198-1-malysagreg@gmail.com
This adds support for the ADP588 GPIO expander from Analog Devices. It
is accessed over I2C and provides up to 18 pins. It is largely a port of
the Linux driver developed by Michael Hennerich
<michael.hennerich@analog.com>
Signed-off-by: Ian Roberts <ian.roberts@timesys.com>
Signed-off-by: Greg Malysa <malysagreg@gmail.com>
Signed-off-by: Vasileios Bimpikas <vasileios.bimpikas@analog.com>
Signed-off-by: Utsav Agarwal <utsav.agarwal@analog.com>
Signed-off-by: Arturs Artamonovs <arturs.artamonovs@analog.com>
Signed-off-by: Oliver Gaskell <Oliver.Gaskell@analog.com>
Signed-off-by: Nathan Barrett-Morrison <nathan.morrison@timesys.com>
This adds support for using the GPIO pins on the SC5XX family of SoCs
from Analog Devices.
Co-developed-by: Nathan Barrett-Morrison <nathan.morrison@timesys.com>
Signed-off-by: Nathan Barrett-Morrison <nathan.morrison@timesys.com>
Co-developed-by: Ian Roberts <ian.roberts@timesys.com>
Signed-off-by: Ian Roberts <ian.roberts@timesys.com>
Signed-off-by: Vasileios Bimpikas <vasileios.bimpikas@analog.com>
Signed-off-by: Utsav Agarwal <utsav.agarwal@analog.com>
Signed-off-by: Arturs Artamonovs <arturs.artamonovs@analog.com>
Signed-off-by: Oliver Gaskell <Oliver.Gaskell@analog.com>
Signed-off-by: Greg Malysa <malysagreg@gmail.com>
-----BEGIN PGP SIGNATURE-----
iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmfPdnYACgkQFHw5/5Y0
tyw17wv+KqFxDoJKTGVWeP4fu+zhTQlFo0f2tAlWylAdJnDP6nR/I49zid2mjRbZ
2Bq3mE3G2Ag1efJ3UGHck0Zn1O9OpqVvk734IHSJFygN77l2xmNSMXZd8MLOsbaU
4JXhxbLUdumCSkwVjjc9/sN+kJUfpwmFBwjqPWmE8rVU+IjApdZP0hBmfxACivl3
p0JJZ870JkgSd5KuAGO/MUbinl/QYOdpitbo2EinOyqnLnivw5PzlcAYF0STNcgJ
XfsT7Ap9T3woPTkT1mXGo+0gBs1OPxXcXp6nywFY75EVIGYRetDEXr8/jf74Jg83
XK8+mqFP+bhlLOMydCdRHyQU8+WGNPfWtcOa7ekC3DjR9Kf7VwoTujqa9B9ILg6m
UBagI/zUIWGAHi4oe2vMV16nR1cPT1ZexPoswZJrj/iDC6WaN0gWwDQgcPODm0UL
rPYYNPWne/iGYgbkhy1zqZMEj7ytnvtjaVMRFdbTSwWUR3s23q9btqjlOwfXbtYZ
0ENfAAu0
=xGcd
-----END PGP SIGNATURE-----
Merge tag 'v2025.04-rc4' into next
This uses Heinrich's merge of lib/efi_loader/efi_net.c which results in
no changes.
Currently, Kconfig allows building CONFIG_DM_74X164 without
CONFIG_DM_SPI, which results in linker errors because this driver
actually uses dm_spi_* functions:
drivers/gpio/74x164_gpio.o: in function `gen_74x164_write_conf':
undefined reference to `dm_spi_claim_bus'
undefined reference to `dm_spi_xfer'
undefined reference to `dm_spi_release_bus'
Signed-off-by: J. Neuschäfer <j.ne@posteo.net>
Requesting of PMIC's GPIO child should be done by binding
GPIO driver to PMIC's node is GPIO driver does not have
its own node.
This reverts commit c03cd98d1a163666b4addcdd9a34fc0c77dfd0a5.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
i.MX93-11x11-EVK has switched to use upstream device tree, and use
"adi,adp5585". Since i.MX93-11x11-EVK is the only user of this driver,
so it is safe to drop "adp5585".
Signed-off-by: Peng Fan <peng.fan@nxp.com>
The mpc8xxx_gpio driver contains a workaround for certain chips
where the previously written state of outputs cannot be read back
from the GPIO data (GPDAT) register (MPC8572/MPC8536). This workaround
consists of tracking the state of GPDAT in a "shadow register" (i.e. a
software variable). The shadow register is initialized to zero.
This results in a problem w.r.t. outputs that are configured to a
high (1) state before U-Boot runs, but not touched by U-Boot itself:
Due to the zero-initialization, these GPIOs end up being set to zero,
the first time that any other output is set.
To avoid such issues initialize the GPDAT shadow register to the value
previously held by any outputs, if possible. On MPC8572/MPC8536 this
should make no difference, i.e. the shadow register should be
initialized to zero on these chips.
This patch has been tested on a MPC8314E-based board.
Reviewed-by: Sinan Akman <sinan@writeme.com>
Signed-off-by: J. Neuschäfer <j.ne@posteo.net>
