summaryrefslogtreecommitdiff
path: root/drivers/power/regulator
AgeCommit message (Collapse)Author
35 hourspower: regulator: Correct Kconfig for PFUZE100Peng Fan
Use CONFIG_$(PHASE_)DM_REGULATOR_PFUZE100 as the build condition for pfuze100 regulator driver. Add Kconfig option for SPL_DM_REGULATOR_PFUZE100. To avoid break current platforms, set the Kconfig default value same as PMIC_PFUZE100. Signed-off-by: Peng Fan <peng.fan@nxp.com>
35 hourspower: regulator: pfuze100: support non-independent modePeng Fan
Some BUCKs could work in single/dual phase mode, not in independent mode. In single/dual phase mode, registers of both regulators, must be identically set. So configure mode and value for both BUCKs. CONF registers are not touched, leave them as default OTP settings. PFUZE100/200 SW3A/B, could work in single/dual phase mode, so introduce a new macro by adding a pointer to the SW3B descriptor. Signed-off-by: Peng Fan <peng.fan@nxp.com>
35 hourspower: regulator: pfuze100: support high output voltage modePeng Fan
Some PFUZE regulators can operate in either low or high output voltage mode, with different minimum voltages and voltage step sizes selected by a hardware control bit. However, the current PFUZE100 regulator driver assumes low output voltage mode only, resulting in incorrect voltage calculation and programming when high voltage mode is enabled. Extend the regulator descriptor to describe high output voltage mode by adding a mask to detect the mode and a dedicated voltage description (min_uV and step size). Update voltage get/set handling to dynamically select the correct voltage parameters based on the high voltage mode bit. Signed-off-by: Peng Fan <peng.fan@nxp.com>
35 hourspower: regulator: pfuze100: Fix min_uV usagePeng Fan
regulator-min-microvolt in device tree is not always match the minimal voltage in the pmic datasheet, direclty using the min value from device tree as base may cause wrong voltage settings being written. Directly use the min_uV from datasheet to avoid wrong settings. Signed-off-by: Peng Fan <peng.fan@nxp.com>
35 hourspower: regulator: tps65941: Enable FPWM bitsNeha Malcom Francis
Depending on the phase selection (single or multi), the FPWM bits configured forces the regulator to operate in PWM mode. In case of multi-phase selection, the FPWM_MP bits enforce the regulator to also operate in multi-phase. This fixes correct multi-phase operation. While at this, correct incorrect macro alignment as well. Fixes: 065a452ae6a1 ("power: regulator: tps65941: add regulator support") Link: https://www.ti.com/lit/ds/symlink/tps6594-q1.pdf Signed-off-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Takuma Fujiwara <t-fujiwara1@ti.com> Signed-off-by: Neha Malcom Francis <n-francis@ti.com> Reviewed-by: Udit Kumar <u-kumar1@ti.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
10 daysregulator: qcom-rpmh-regulator: add support for PM7550 regulatorsLuca Weiss
Add the PM7550 regulator data found on Qualcomm Milos devices. The tables are imported from the Linux driver (tag v7.0-rc4). The SMPS regulators were not added now. Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> Link: https://patch.msgid.link/20260318-milos-bringup-v2-4-650b91dd75d8@fairphone.com Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
2026-04-06Merge branch 'next'Tom Rini
2026-03-25Merge branch 'staging' of ↵Tom Rini
https://source.denx.de/u-boot/custodians/u-boot-tegra into next
2026-03-24power: regulator: qcom: Correct dependenecies for DM_REGULATOR_QCOM_USB_VBUSTom Rini
The DM_REGULATOR_QCOM_USB_VBUS functionality can only work with DM_PMIC enabled as well, so express this dependency in Kconfig. Signed-off-by: Tom Rini <trini@konsulko.com> Link: https://patch.msgid.link/20260323195302.2363577-1-trini@konsulko.com Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
2026-03-23dm: regulator: fix missing quote in error messageDavid Lechner
Fix a missing closing quote in the error message when a regulator name is not unique. Signed-off-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Julien Stephan <jstephan@baylibre.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
2026-03-22power: cpcap: make regulator node names case independentSvyatoslav Ryhel
The Linux kernel CPCAP driver uses uppercase regulator node names, while this driver uses lowercase. Since regulator names can be case-insensitive, update the driver to support both uppercase and lowercase node names. Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
2026-03-22power: regulator: cpcap: remove bit_offset_from_cpcap_lowest_voltageSvyatoslav Ryhel
The bit_offset_from_cpcap_lowest_voltage value was inherited from the downstream kernel as a quirk. With the correct voltage table, it is no longer needed. An additional benefit is that SW1, SW2, and SW4 now share the same voltage table. Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
2026-02-25power: regulator: Kconfig: add SPL_DM_REGULATOR_FAN53555Heinrich Schuchardt
Symbol CONFIG_SPL_DM_REGULATOR_FAN53555 is selected by SPL_DM_PMIC_FAN53555 and used in a Makefile. But the symbol definition is missing. Add the missing configuration symbol. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
2026-02-25power: regulator: mt6359: add driver for MT6359PBo-Chen Chen
Add a new regulator driver for MT6359P and similar PMIC chips. The MT6359P is a eco version for MT6359 regulator. For the MT8391 platform, we use the MT6359P (MT6365) as the main PMIC. The MT6359 and MT6359P have different register maps. Therefore, on the MT8391 platform, we only provide support for the MT6359P. If support for the MT6359 PMIC it can be added later. Signed-off-by: Bo-Chen Chen <rex-bc.chen@mediatek.com> Signed-off-by: David Lechner <dlechner@baylibre.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
2026-02-25power: regulator: add MediaTek MT6357 driverJulien Masson
Add a driver for the power regulators of the MediaTek MT6357 PMIC chip. Signed-off-by: Julien Masson <jmasson@baylibre.com> Co-developed-by: Macpaul Lin <macpaul.lin@mediatek.com> Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com> Signed-off-by: David Lechner <dlechner@baylibre.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
2026-02-17treewide: Clean up DECLARE_GLOBAL_DATA_PTR usagePeng Fan
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 <patrice.chotard@foss.st.com> #STMicroelectronics boards and STM32MP1 ram test driver Tested-by: Anshul Dalal <anshuld@ti.com> #TI boards Acked-by: Yao Zi <me@ziyao.cc> #TH1520 Signed-off-by: Peng Fan <peng.fan@nxp.com>
2026-01-25power: regulator: add AXP318W supportYixun Lan
The PMIC is also known as AXP819 in vendor pmu code For DCDC6, 8, 9, the underlying hardware support more than two levels voltage step tuning, but for now only first two levels are implemented in this driver, hence highest voltage will be limited at seccond level. It actual meets board requirement in current design, and we've verified it in Radxa Cubie A7A board. Following are detail explanation of voltage tuning stpes for those DCDCs: DCDC | voltage range | units | steps | implemented 6 | 0.5 - 1.2 | 10 mV | 71 | Y . | 1.22 - 1.54 | 20 mV | 17 | Y . | 1.8 - 2.4 | 20 mV | 31 | N . | 2.44 - 2.76 | 40 mV | 9 | N -------------------------------------------------- 8/9 | 0.5 - 1.2 | 10 mV | 71 | Y . | 1.22 - 1.84 | 20 mV | 32 | Y . | 1.9 - 3.4 | 100mV | 16 | N Signed-off-by: Yixun Lan <dlan@gentoo.org> Reviewed-by: Andre Przywara <andre.przywara@arm.com>
2026-01-22power: regulator: common: fix compilation issueJulien Stephan
If CONFIG_DM_GPIO is not enabled, compilation fails with the following errors: aarch64-none-linux-gnu-ld: drivers/power/regulator/regulator_common.o: in function `regulator_common_of_to_plat': <...>/u-boot/drivers/power/regulator/regulator_common.c:30: undefined reference to `gpio_request_by_name' aarch64-none-linux-gnu-ld: drivers/power/regulator/regulator_common.o: in function `regulator_common_get_enable': <...>/u-boot/drivers/power/regulator/regulator_common.c:57: undefined reference to `dm_gpio_get_value' aarch64-none-linux-gnu-ld: drivers/power/regulator/regulator_common.o: in function `regulator_common_set_enable': <...>/u-boot/drivers/power/regulator/regulator_common.c:92: undefined reference to `dm_gpio_set_value' make: *** [Makefile:2029: u-boot] Error 139 Since the enable gpio is optional we can conditionally skip these calls. Reviewed-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Julien Stephan <jstephan@baylibre.com> Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de> Signed-off-by: Peng Fan <peng.fan@nxp.com>
2026-01-22power: regulator: common: use dm_gpio_is_valid helperJulien Stephan
Use dm_gpio_is_valid() helper function instead of manually checking the gpio. Reviewed-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Julien Stephan <jstephan@baylibre.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
2026-01-22power: regulator: common: remove unnecessary debug traceJulien Stephan
Drop the ftrace like debug() that checkpatch --strict complains about: WARNING: Unnecessary ftrace-like logging - prefer using ftrace Reviewed-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Julien Stephan <jstephan@baylibre.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
2026-01-14power: regulator: qcom-rpmh: correctly map pmic modeCasey Connolly
Currently we don't properly map between the regulator mode ID enum and the appropriate register values in the mode map, as a result we always unintentionally vote for retention mode if we actually attempt to set it. In the set_mode path we did find the appropriate entry in the mode map but we wrote the id instead of the register values. Clean this up and properly map id -> mode and vice versa. Link: https://patch.msgid.link/20260108-rpmh-regulator-fixes-v1-6-d1b5b300b665@linaro.org Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
2026-01-14power: regulator: qcom-rpmh: read votes from rpmhCasey Connolly
Make use of the new RPMh read support to fetch regulator values that may have been voted on by a previous bootloader stage. This allows commands like "regulator status" to report the actual votes programmed into hardware (though not necessarily the actual states of the regulators once the votes have been aggregated). Link: https://patch.msgid.link/20260108-rpmh-regulator-fixes-v1-5-d1b5b300b665@linaro.org Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
2026-01-14regulator: qcom-rpmh-regulator: add support for PM8150 PM8350 PM7325Aswin Murugan
Add the PM8150, PM8350, and PM7325 regulator data found on Qualcomm platforms. These regulator tables are imported from the Linux driver to enable support for these PMICs in U-Boot. Signed-off-by: Aswin Murugan <aswin.murugan@oss.qualcomm.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20251112164204.1557934-1-aswin.murugan@oss.qualcomm.com Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
2026-01-09dm: core: Default to using DEVRES outside of xPLTom Rini
The devm alloc functions that we have may follow the Linux kernel model where allocations are (almost always) automatically free()'d. However, quite often we don't enable, in full U-Boot, the tracking and free()'ing functionality. This in turn leads to memory leaks because the driver author expects that since the functions have the same name as in the Linux Kernel they have the same behavior. In turn we then get functionally correct commits such as commit 00e1fed93c8c ("firmware: ti_sci: Fix memory leaks in devm_ti_sci_get_of_resource") that manually add these calls. Rather than manually tracking allocations and implementing free()s, rework things so that we follow expectations by enabling the DEVRES functionality (outside of xPL phases). This turns DEVRES from a prompted symbol to a symbol that must be select'd, and we now remove our non-managed alloc/free functions from outside of xPL builds. Reviewed-by: Michael Trimarchi <michael@amarulasolutions.com> Signed-off-by: Tom Rini <trini@konsulko.com>
2025-12-24power: regulator: Fix dependency of SPL_DM_REGULATOR_GPIOPeng Fan
gpio-regulator uses dm gpio API, so it depends on SPL_DM_GPIO, not SPL_GPIO. Reported-by: Tom Rini <trini@konsulko.com> Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
2025-12-24power: regulator: remove SPL_REGULATOR_PWM due to unmeetable SPL_DM_PWM ↵Quentin Schulz
dependency SPL_DM_PWM option simply doesn't exist. Moreover, drivers/pwm is only included by drivers/Makefile for non-xPL stages so making SPL_REGULATOR_PWM properly build for SPL/xPL is more involved than just adding an SPL_DM_PWM option. Reading the original commit (ddc824f89aa8 ("power: regulator: Allow PWM regulator to be omitted from SPL."), the intent seemingly wasn't to allow building support in XPL but rather to allow removing it which is done by using $(PHASE_) ($(SPL_) at that time) in the Makefile. If anyone needs that, let them figure out what they need to do without misleading potential users of this symbol by simply removing it. Fixes: 2a846e04c622 ("power: regulator: Correct dependencies on SPL_REGULATOR_PWM") Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Anshul Dalal <anshuld@ti.com> Reviewed-by: Kory Maincent <kory.maincent@bootlin.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
2025-12-24power: regulator: fix dependency for REGULATOR_PWMQuentin Schulz
The PWM regulator driver is a uclass driver, thus requiring DM_PWM to be enabled to be actually usable (and with the appropriate PWM controller driver enabled as well, but that we cannot enforce easily), so let's add this missing dependency. Fixes: 1a01695615f9 ("power: regulator: add pwm regulator") Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Udit Kumar <u-kumar1@ti.com> Reviewed-by: Anshul Dalal <anshuld@ti.com> Reviewed-by: Kory Maincent <kory.maincent@bootlin.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
2025-11-06Revert "power: regulator: Add vin-supply for GPIO and Fixed regulators"Jonas Karlman
Rockchip boards may depend on a working MMC regulator in SPL to successfully load FIT payload from MMC. Typically, these boards only include the vmmc-supply regulator and not its vin-supply in SPL control FDT. The commit f98d812e5353 ("power: regulator: Add vin-supply for GPIO and Fixed regulators") breaks loading FIT from MMC in SPL on some of these boards due to now requiring the vin-supply to be included in the SPL control FDT. The commit also strangely enables any found vin-supply in regulator_common_of_to_plat() and not when a regulator is enabled or as part of regulator_autoset(). Revert the commit to fix FIT loading in SPL on broken boards. If a board needs to have its vin-supply enabled, two options come to mind: - Add regulator-always-on prop to the regulator in the -u-boot.dtsi for any board. - Implement full support for reference counting of regulators and then update the regulator-uclass to enable any found vin-supply when a regulator is enabled. This reverts commit f98d812e5353408ef77a46bad1f1cdc793ff8a03. Reported-by: Dang Huynh <danct12@riseup.net> Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Dragan Simic <dsimic@manjaro.org>
2025-10-30Merge tag 'qcom-for-2026.01-rc2' of ↵Tom Rini
https://source.denx.de/u-boot/custodians/u-boot-snapdragon A variety of Qualcomm features/fixes for this cycle, notably with a few new platforms gaining support: * Initial support for SDM670 (similar to SDM845), SM6350, and SM7150 platforms is added * USB and UART issues on MSM8916 are addressed (improving stability/ reliability) * Firmware loading is implemented for the GENI serial engine, this is used on some platforms to load firmware for i2c/spi/uart to work Some additional patches like binman support for building MBN files still need some additional work. CI: https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/commit/8ef6ac07b35e39a57501554680bbf452e818d3e3/pipelines?ref=qcom-main
2025-10-30power: regulator: Remove duplicate include of regulator_common.hTanmay Kathpalia
Remove duplicate #include "regulator_common.h" statements from regulator driver files. Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
2025-10-30power: regulator: s2mps11: add support for S2MPU05 PMICKaustabh Chakraborty
Samsung's S2MPU05 PMIC is used by Exynos7870 SoC. It has 5 buck and 38 LDO regulators. Add support for this device variant in the driver. Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
2025-10-30power: regulator: s2mps11: declaratively get/set regulator modeKaustabh Chakraborty
The functions s2mps11_{buck,ldo}_mode use the s2mps11_{buck,ldo}_modes arrays directly in order to extract the mode of a certain register. This approach does not allow similar devices of other variants (which may support a different set of modes) to work with the same driver. Instead of using these arrays hardcoded, extract them from the device's uclass platform data. Now the responsibility of setting these arrays properly is done by functions s2mps11_{buck,ldo}_probe, by implementing a switch-case block which can support modes of multiple variants if and when added. Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
2025-10-30power: regulator: s2mps11: declaratively define LDOs and BUCKsKaustabh Chakraborty
In the Linux kernel driver, all information related to LDO and BUCK regulators are stored in descriptive arrays. This also allows multiple variants to be supported by the same driver. Define a struct sec_regulator_desc which holds all values required by a regulator. Create an array of said struct containing all regulators. The descriptors are designed to follow a style similar to what's seen in the Linux driver, so comparing one with the other is simple. In functions such as s2mps11_{buck,ldo}_{val,mode} these values are to be used, make necessary modifications to pull them from the descriptors. Since multiple variants have varying descriptors, select them from within a switch-case block. Functions s2mps11_{buck,ldo}_{volt2hex,hex2volt} and arrays s2mps11_buck_{ctrl,out} are phased out as the calculations are now hardcoded in descriptors, thusly, it reduces clutter and enhances readability. Two macros in s2mps11.h, S2MPS11_LDO_NUM and S2MPS11_BUCK_NUM are removed as they are no longer being used. Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
2025-10-29regulator: qcom-rpmh-regulator: add support for pm6150l regulatorsLuca Weiss
Add the pm6150l regulator data found on the Qualcomm SM6350 platform. The tables are imported from the Linux driver. The SMPS regulators were not added now. Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
2025-10-10power: regulator: Correct dependencies on SPL_REGULATOR_PWMTom Rini
In order to enable and build with SPL_REGULATOR_PWM we need to have both SPL_DM_REGULATOR and SPL_DM_PWM enabled. Build-wise, we can have SPL have PWM regulator support without enabling it in U-Boot itself so drop that dependency. Signed-off-by: Tom Rini <trini@konsulko.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
2025-09-25power: regulator: Fix incorrect use of binary andAndrew Goodbody
In regulator_list_autoset there is a test for ret being non-zero and error being zero but it uses the binary '&' instead of the logical '&&' which could well lead to unexpected results. Correct this to use the logical '&&' instead. This issue found by Smatch. Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
2025-09-20power: regulator: pfuze100: Fix accessing the regulator descPeng Fan
se_desc loop check is wrong, it relies on the desc always has the expected name to end of the loop. It works because the device tree has the expected name as of now, but this may not be always true. Drop se_desc by moving the check into probe and fix the loop check. Reported-by: Andrew Goodbody <andrew.goodbody@linaro.org> Cc: Tom Rini <trini@konsulko.com> Cc: Fabio Estevam <festevam@gmail.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
2025-09-20power: regulator: Add vin-supply for GPIO and Fixed regulatorsYe Li
Enable the vin-supply when probing the regulator device. Signed-off-by: Ye Li <ye.li@nxp.com>
2025-09-01pmic: pca9450: Handle hardware with fixed SD_VSEL for LDO5Frieder Schrempf
There are two ways to set the output voltage of the LD05 regulator. First by writing to the voltage selection registers and second by toggling the SD_VSEL signal. Usually board designers connect SD_VSEL to the VSELECT signal controlled by the USDHC controller, but in some cases the signal is hardwired to a fixed low level (therefore selecting 3.3V as initial value for allowing to boot from the SD card). In these cases, the voltage is only determined by the value of the LDO5CTRL_L register. Introduce a property nxp,sd-vsel-fixed-low to let the driver know that SD_VSEL is low and there is no GPIO to actually get that information from dynamically. This is equivalent to the following change in Linux: c8c1ab2c5cb7 ("regulator: pca9450: Handle hardware with fixed SD_VSEL for LDO5") Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de> Signed-off-by: Peng Fan <peng.fan@nxp.com>
2025-09-01pmic: pca9450: Fix control register for LDO5Frieder Schrempf
For LDO5 we need to be able to check the status of the SD_VSEL input in order to know which control register is used. Read the status of the SD_VSEL signal via GPIO and use the correct register accordingly. To use this, the LDO5 node in the devicetree needs the sd-vsel-gpios property to reference the GPIO that is used to read back the SD_VSEL status internally. Please note that the SION bit in the IOMUX must be set if the signal is muxed as VSELECT and controlled by the USDHC controller. This is equivalent to the following change in Linux: 3ce6f4f943dd ("regulator: pca9450: Fix control register for LDO5") Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de> Signed-off-by: Peng Fan <peng.fan@nxp.com>
2025-09-01pmic: pca9450: Fix enable register for LDO5Frieder Schrempf
The LDO5 regulator has two configuration registers, but only LDO5CTRL_L contains the bits for enabling/disabling the regulator. This is equivalent to the following change in Linux: f5aab0438ef1 ("regulator: pca9450: Fix enable register for LDO5") Fixes: 326337fb005f ("pmic: pca9450: Add regulator driver") Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de> Signed-off-by: Peng Fan <peng.fan@nxp.com>
2025-08-29power: regulator: tps65941: Cannot test unsigned for being negativeAndrew Goodbody
In tps65941_buck_val and tps65941_ldo_val hex is an unsigned variable being assigned the return value from a function that returns int. Change hex to be an int so that the following test for an error as a negative value will work as expected. This issue was found by Smatch. Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org> Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
2025-08-29power: regulator: rzg2l-usbphy: Add parenthesis to return expressionAndrew Goodbody
In order to get the expected result from rzg2l_usbphy_regulator_get_enable the return expression needs parenthesis so that the binary and is performed before the double logical not. This issue was found by Smatch. Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org> Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
2025-08-29power: regulator: palmas: Cannot test unsigned for being negativeAndrew Goodbody
In palmas_smps_val and palmas_ldo_val hex is an unsigned variable being assigned the return value from a function that returns int. Change hex to be an int so that the following test for an error as a negative value will work as expected. This issue was found by Smatch. Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org> Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
2025-08-29power: regulator: lp87565: Cannot test unsigned for being negativeAndrew Goodbody
In lp87565_buck_val hex is an unsigned variable being assigned the return value from a function that returns int. Change hex to be an int so that the following test for an error as a negative value will work as expected. This issue was found by Smatch. Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org> Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
2025-08-29power: regulator: lp873x: Cannot test unsigned for being negativeAndrew Goodbody
In lp873x_buck_val and lp873x_ldo_val hex is an unsigned variable being assigned the return value from a function that returns int. Change hex to be an int so that the following test for an error as a negative value will work as expected. This issue was found by Smatch. Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org> Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
2025-07-27power: regulator: add AXP323 supportAndre Przywara
The X-Powers AXP323 is very close sibling to the AXP313A, only that it adds support for dual-phasing the first two DC/DC converters. We do not really care about this particular feature, so just add the new compatible string and tie it to the existing AXP313A support code. Signed-off-by: Andre Przywara <andre.przywara@arm.com>
2025-07-24uclass: Cleanup uclass_find_next_deviceAndrew Goodbody
uclass_find_next_device always returns 0, so instead make it a void and update calling sites. Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
2025-06-14Merge patch series "Hex value prefix case cleanup"Tom Rini
E Shattow <e@freeshell.de> says: Make consistent use of lowercase hexadecimal prefix '0x' throughout U-Boot. There are a few remaining uses of uppercase 'X' to denote hexadecimal prefix or placeholder in documentation and error messages. External devicetree-rebasing dts/upstream and the generated code of xilinx/zynq are ignored for the series. Link: https://lore.kernel.org/r/20250606224558.1117422-1-e@freeshell.de
2025-06-14drivers: use lowercase hex prefix styleE Shattow
Use consistent lowercase hex prefix style in drivers/* Does not change hex prefix case in allcaps uppercase style error messages Signed-off-by: E Shattow <e@freeshell.de>