Pull regulator updates from Mark Brown:
"This has been a very quiet release, we've got support for one device
added, another removed, and some smaller fixes and API improvements.
The main thing of note is the rework of the PCA9450 LDO5 handling.
- A rework of the handling of LDO5 on the PCA9450, this was quite
wrong in how it handled the SD_VSEL conrol and only worked for some
system designs. This includes a DTS update since there was a not
quite ABI compatible change as part of the fix
- A devres change introducing devm_kmemdup_array() was pulled in so
it could be used with some regulator conversions to that function,
this pulled in some other devres and IIO stuff that was part of the
same pull request
- Removal of the PCF50633 driver, the SoC for the OpenMoko platform
that used it has been removed
- Support for the NXP PF9453"
* tag 'regulator-v6.15' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: (24 commits)
regulator: axp20x: AXP717: dcdc4 doesn't have delay
regulator: dt-bindings: rtq2208: Cleanup whitespace
regulator: dt-bindings: rtq2208: Mark fixed LDO VOUT property as deprecated
regulator: rtq6752: make const read-only array fault_mask static
regulator: pf9453: add PMIC PF9453 support
regulator: dt-bindings: pca9450: Add nxp,pf9453 compatible string
regulator: pcf50633-regulator: Remove
regulator: pca9450: Handle hardware with fixed SD_VSEL for LDO5
regulator: cros-ec: use devm_kmemdup_array()
regulator: devres: use devm_kmemdup_array()
regulator: Add (devm_)of_regulator_get()
devres: Introduce devm_kmemdup_array()
iio: imu: st_lsm9ds0: Replace device.h with what is needed
driver core: Split devres APIs to device/devres.h
err.h: move IOMEM_ERR_PTR() to err.h
regulator: pca9450: Remove duplicate code in probe
regulator: ad5398: Fix incorrect power down bit mask
regulator: pca9450: Fix enable register for LDO5
regulator: pca9450: Fix control register for LDO5
Revert "regulator: pca9450: Add SD_VSEL GPIO for LDO5"
...
Support new PMIC PF9453, which is totally difference with PCA9450. So
create new file for it.
The PF9453 is a single chip Power Management IC (PMIC) specifically
designed for i.MX 91 processor. It provides power supply solutions for IoT
(Internet of Things), smart appliance, and portable applications where size
and efficiency are critical. The device provides four high efficiency
step-down regulators, three LDOs, one 400 mA load switch and 32.768 kHz
crystal oscillator driver.
Signed-off-by: Joy Zou <joy.zou@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20250314-pf9453-v5-2-ab0cf1f871b0@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Sometimes I get a NULL pointer dereference at boot time in kobject_get()
with the following call stack:
anatop_regulator_probe()
devm_regulator_register()
regulator_register()
regulator_resolve_supply()
kobject_get()
By placing some extra BUG_ON() statements I could verify that this is
raised because probing of the 'dummy' regulator driver is not completed
('dummy_regulator_rdev' is still NULL).
In the JTAG debugger I can see that dummy_regulator_probe() and
anatop_regulator_probe() can be run by different kernel threads
(kworker/u4:*). I haven't further investigated whether this can be
changed or if there are other possibilities to force synchronization
between these two probe routines. On the other hand I don't expect much
boot time penalty by probing the 'dummy' regulator synchronously.
Cc: stable@vger.kernel.org
Fixes: 259b93b21a ("regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in 4.14")
Signed-off-by: Christian Eggers <ceggers@arri.de>
Link: https://patch.msgid.link/20250311091803.31026-1-ceggers@arri.de
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently, we are unnecessarily holding a regulator_ww_class_mutex lock
when creating debugfs entries for a newly created regulator. This was
brought up as a concern in the discussion in commit cba6cfdc7c
("regulator: core: Avoid lockdep reports when resolving supplies").
This causes the following lockdep splat after executing
`ls /sys/kernel/debug` on my platform:
======================================================
WARNING: possible circular locking dependency detected
5.15.167-axis9-devel #1 Tainted: G O
------------------------------------------------------
ls/2146 is trying to acquire lock:
ffffff803a562918 (&mm->mmap_lock){++++}-{3:3}, at: __might_fault+0x40/0x88
but task is already holding lock:
ffffff80014497f8 (&sb->s_type->i_mutex_key#3){++++}-{3:3}, at: iterate_dir+0x50/0x1f4
which lock already depends on the new lock.
[...]
Chain exists of:
&mm->mmap_lock --> regulator_ww_class_mutex --> &sb->s_type->i_mutex_key#3
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&sb->s_type->i_mutex_key#3);
lock(regulator_ww_class_mutex);
lock(&sb->s_type->i_mutex_key#3);
lock(&mm->mmap_lock);
*** DEADLOCK ***
This lock dependency still exists on the latest kernel and using a newer
non-tainted kernel would still cause this problem.
Fix by moving sysfs symlinking and creation of debugfs entries to after
the release of the regulator lock.
Fixes: cba6cfdc7c ("regulator: core: Avoid lockdep reports when resolving supplies")
Fixes: eaa7995c52 ("regulator: core: avoid regulator_resolve_supply() race condition")
Signed-off-by: Ludvig Pärsson <ludvig.parsson@axis.com>
Link: https://patch.msgid.link/20250305-regulator_lockdep_fix-v1-1-ab938b12e790@axis.com
Signed-off-by: Mark Brown <broonie@kernel.org>
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.
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Link: https://patch.msgid.link/20250303132258.50204-1-frieder@fris.de
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Sebastian Reichel <sebastian.reichel@collabora.com>:
This introduces devm_of_regulator_get without the _optional suffix, since
that is more sensible for the Rockchip usecase.
The Rockchip power-domain controller also plans to make use of
per-domain regulators similar to the MediaTek power-domain controller.
Since existing DTs are missing the regulator information, the kernel
should fallback to the automatically created dummy regulator if
necessary. Thus the version without the _optional suffix is needed.
The Rockchip driver plans to use the managed version, but to be
consistent with existing code the unmanaged version is added at the
same time.
Tested-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Link: https://patch.msgid.link/20250220-rk3588-gpu-pwr-domain-regulator-v6-1-a4f9c24e5b81@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
This reverts commit cd7a38c40b.
When submitting the change above, it was thought that the origin of the
init_data should be a clear choice, from the driver or from DT but not
both.
It turns out some devices, such as qcom-msm8974-lge-nexus5-hammerhead,
relied on the old behaviour to override the init_data provided by the
driver, making it some kind of default if none is provided by the platform.
Using the init_data provided by the driver when it is present broke these
devices so revert the change to fixup the situation and add a comment
to make things a bit more clear
Reported-by: Luca Weiss <luca@lucaweiss.eu>
Closes: https://lore.kernel.org/lkml/5857103.DvuYhMxLoT@lucaweiss.eu
Fixes: cd7a38c40b ("regulator: core: do not silently ignore provided init_data")
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Link: https://patch.msgid.link/20250211-regulator-init-data-fixup-v1-1-5ce1c6cff990@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
AD5398_SW_POWER_DOWN was defined with a bit position outside the valid
range of the device's 16-bit register. The bitwise operation with an
unsigned short would always evaluate to 0, making the power down check
ineffective.
Update AD5398_SW_POWER_DOWN to use a valid bit position within the
16-bit range of the register.
Fixes: 19d022d67d ("regulator: ad5398: change enable bit name to improve readibility")
Signed-off-by: Dheeraj Reddy Jonnalagadda <dheeraj.linuxdev@gmail.com>
Link: https://patch.msgid.link/20250206103153.59114-1-dheeraj.linuxdev@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Isaac Scott <isaac.scott@ideasonboard.com>:
The AD5398 is a DAC that can be used to control current flow in circuits
in a wide variety of applications such as motor control, or in my case,
LED control. I found when working with the current driver that it did
not work for my use case. It transpired that it only had support for
platform_data, and didn't appear to be correctly implemented according
to the datasheet, which can be found here:
https://www.analog.com/media/en/technical-documentation/data-sheets/ad5398.pdf
One example of this is the "soft power-down" bit being referred to in
the driver as simply "enable", which gives the impression that the
setting that bit will allow current through the regulator, which it does
not.
This series allows the regulator to be given its constraints via the
device tree, and makes the function of the enable register much more
obvious.
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.
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Link: https://patch.msgid.link/20241218152842.97483-5-frieder@fris.de
Signed-off-by: Mark Brown <broonie@kernel.org>
This reverts commit 8c67a11bae.
It turns out that all boards using the PCA9450 actually have the
SD_VSEL input connected to the VSELECT signal of the SoCs SD/MMC
interface or use a fixed level.
The assumptions on which this was implemented were wrong. There
is no need for a GPIO-only-based approach and keeping this will
cause confusion and lead people to implement non-standard setups.
All in-tree users of this have been migrated and we can savely
remove this now and allow for a more future-proof approach
of syncing the actual status of SD_VSEL and the PMIC driver.
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Link: https://patch.msgid.link/20241218152842.97483-4-frieder@fris.de
Signed-off-by: Mark Brown <broonie@kernel.org>
The mask name AD5398_CURRENT_EN_MASK is misleading, as it implies that
setting bit 16 of the AD5398 enables current flow. In fact, setting this
bit prevents current flow, due to this bit being a software power down
control. This bit is referred to as "soft power down" in the datasheet.
As such, change the name of the bit and modify its use in the driver to
make the regulator more intuitively usable.
(When calling ad5398_enable, current will start flowing, and vice
versa).
Signed-off-by: Isaac Scott <isaac.scott@ideasonboard.com>
Acked-by: Michael Hennerich <michael.hennerich@analog.com>
Link: https://patch.msgid.link/20250128173143.959600-2-isaac.scott@ideasonboard.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Pull regulator fixes from Mark Brown:
"A couple of fixes that have come in during the merge window: one that
operates the TPS6287x devices more within the design spec and can
prevent current surges when changing voltages and another more trivial
one for error message formatting"
* tag 'regulator-fix-v6.14-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: core: Add missing newline character
regulator: TPS6287X: Use min/max uV to get VRANGE
Pull regulator updates from Mark Brown:
"This was a very quiet release, aside from some smaller improvements we
have:
- Support for power budgeting on regulators, initially targeted at
some still in review support for PSE controllers but generally
useful
- Support for error interrupts from ROHM BD96801 devices
- Support for NXP PCA9452"
* tag 'regulator-v6.14' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: dt-bindings: Add regulator-power-budget-milliwatt property
regulator: Add support for power budget
regulator: core: Resolve supply using of_node from regulator_config
regulator: of: Implement the unwind path of of_regulator_match()
regulator: tps65219: Remove debugging helper function
regulator: tps65219: Remove MODULE_ALIAS
regulator: tps65219: Update driver name
regulator: tps65219: Use dev_err_probe() instead of dev_err()
regulator: dt-bindings: mt6315: Drop regulator-compatible property
regulator: pca9450: Add PMIC pca9452 support
regulator: dt-bindings: pca9450: Add pca9452 support
regulator: pca9450: Use dev_err_probe() to simplify code
regulator: pca9450: add enable_value for all bucks
regulator: bd96801: Add ERRB IRQ
Changing voltage might ignore slew rate and cause a current surge.
With current implementation the driver will get the regulator to change
the voltage range used during run time. According to communication I
have had with Texas Instruments, this is not intended, since the
Dynamic Voltage Scaling in the hardware is only designed to work
within a voltage range. The current implementation will therefore
ignore the slew rate that is defined in devicetree when the voltage
range is changed during use.
The current implementation will always select a voltage in the most
accurate range that can reach that voltage even though multiple ranges
are able to reach that voltage. There are 4 Voltage ranges with the
following reach:
0b00: 0.4-0.71875V (1.25mV step size)
0b01: 0.4-1.0375V (2.5mV)
0b10: 0.4-1.675V (5mV)
0b11: 0.8-3.3V (10mV)
This in practice means that a change from below to above 0.71875V will
use the smallest range(0b00) for the values below and the second
smallest range(0b01) for the voltages above (Up to 1.675V). I have
timed how long it takes to go from below 0.71875V to above. The
increase was 100mV which, with the slew rate set to 1250µV/µs. This
in theory should take 80µs to do. With the current implementation, it
takes 10µs on my hardware. Doing the same test with the slew rate set
to 5000µV/µs, which should take 20µs, also only takes 10µs to do on
my hardware. Not only is this not in line with the technical
specification for the regulator. It also causes a current surge. Which
when calculating the output current, as described in the technical
specification, compared to what I could observe on my hardware the real
output is ~1A higher (~1.2A) than what I calculated it to be(~0.2A).
I tested also transitioning from a bigger to a smaller range, and the
results were the same.
Instead, let's limit the voltage range to a single one, which is in
line with the intended use of the regulator. This is done by looking
up the minimum and maximum requested voltage specified in devicetree.
Signed-off-by: Jonas Andreasson <jonas.andreasson@axis.com>
Link: https://patch.msgid.link/20250121-tps-fix-v2-1-50cc4d0f1635@axis.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Previously, the regulator core resolved its supply only from the parent
device or its children, ignoring the of_node specified in the
regulator_config structure.
This behavior causes issues in scenarios where multiple regulator devices
are registered for components described as children of a controller, each
with their own specific regulator supply.
For instance, in a PSE controller with multiple PIs (Power Interfaces),
each PI may have a distinct regulator supply. However, the regulator core
would incorrectly use the PSE controller node or its first child to look up
the regulator supply, rather than the node specified by the
regulator_config->of_node for the PI.
This update modifies the behavior to prioritize the of_node in
regulator_config for resolving the supply. This ensures correct resolution
of the power supply for each device. If no supply is found in the provided
of_node, the core falls back to searching within the parent device as
before.
Reviewed-by: Oleksij Rempel <o.rempel@pengutronix.de>
Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
Link: https://patch.msgid.link/20250109-b4-feature_poe_arrange-v2-13-55ded947b510@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
of_regulator_match() does not release the OF node reference in the error
path, resulting in an OF node leak. Therefore, call of_node_put() on the
obtained nodes before returning the EINVAL error.
Since it is possible that some drivers call this function and do not
exit on failure, such as s2mps11_pmic_driver, clear the init_data and
of_node in the error path.
This was reported by an experimental verification tool that I am
developing. As I do not have access to actual devices nor the QEMU board
configuration to test drivers that call this function, no runtime test
was able to be performed.
Fixes: 1c8fa58f47 ("regulator: Add generic DT parsing for regulators")
Signed-off-by: Joe Hattori <joe@pf.is.s.u-tokyo.ac.jp>
Link: https://patch.msgid.link/20250104080453.2153592-1-joe@pf.is.s.u-tokyo.ac.jp
Signed-off-by: Mark Brown <broonie@kernel.org>
This helper function is primarily used by developers for debugging & is
not a standard feature included in other PMIC drivers. The purpose of
debugging function is to check if rdev is determine if the regulator has
been registered prior to requesting a threaded irq. This case is already
handled with the ISERR(rdev) check because the error code is returned.
Signed-off-by: Shree Ramamoorthy <s-ramamoorthy@ti.com>
Link: https://patch.msgid.link/20241217204526.1010989-5-s-ramamoorthy@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Set 'enable_value' in the regulator descriptor for different bucks to
manage their enable modes:
- 00b: OFF
- 01b: ON when PMIC_ON_REQ = H
- 10b: ON when PMIC_ON_REQ = H && PMIC_STBY_REQ = L
- 11b: Always ON
Ensure appropriate behavior based on the intended design. For example:
- Buck2, designed for vddarm, should be set to '10b' (ON when
PMIC_STBY_REQ = L) since it can be off when `PMIC_STBY_REQ = H` after the
kernel enters suspend.
- Other bucks remain '01b' (ON when PMIC_ON_REQ = H), matching the default
setting. This avoids the need to re-enable them during kernel boot as they
are already enabled after PMIC initialization.
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20241205-pca9450-v1-1-aab448b74e78@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
AXP717 datasheet says that regulator ramp delay is 15.625 us/step,
which is 10mV in our case.
Add a AXP_DESC_RANGES_DELAY macro and update AXP_DESC_RANGES macro to
expand to AXP_DESC_RANGES_DELAY with ramp_delay = 0
For DCDC4, steps is 100mv
Add a AXP_DESC_DELAY macro and update AXP_DESC macro to
expand to AXP_DESC_DELAY with ramp_delay = 0
This patch fix crashes when using CPU DVFS.
Signed-off-by: Philippe Simons <simons.philippe@gmail.com>
Tested-by: Hironori KIKUCHI <kikuchan98@gmail.com>
Tested-by: Chris Morgan <macromorgan@hotmail.com>
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
Fixes: d2ac3df75c ("regulator: axp20x: add support for the AXP717")
Link: https://patch.msgid.link/20241208124308.5630-1-simons.philippe@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The ROHM BD96801 "scalable PMIC" provides two physical IRQs. The ERRB
handling can in many cases be omitted because it is used to inform fatal
IRQs, which usually kill the power from the SOC.
There may however be use-cases where the SOC has a 'back-up' emergency
power source which allows some very short time of operation to try to
gracefully shut down sensitive hardware. Furthermore, it is possible the
processor controlling the PMIC is not powered by the PMIC. In such cases
handling the ERRB IRQs may be beneficial.
Add support for ERRB IRQs.
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
Link: https://patch.msgid.link/ZzWkny4lKpY09SX5@mva-rohm
Signed-off-by: Mark Brown <broonie@kernel.org>
Pull regulator fixes from Mark Brown:
"A couple of fixes that came in during the merge window, plus
documetation of a new device ID for the Qualcomm LABIBB driver.
There's a core fix for the rarely used current constraints and a fix
for the Qualcomm RPMH driver which had described only one of the two
voltage ranges that the hardware could control, creating a potential
incompatibility with the configuration left by firmware"
* tag 'regulator-fix-v6.13-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: core: Ignore unset max_uA constraints in current limit check
dt-bindings: regulator: qcom-labibb-regulator: document the pmi8950 labibb regulator
regulator: qcom-rpmh: Update ranges for FTSMPS525
Pull MFD updates from Lee Jones:
- Several drivers, including atmel-flexcom/rk8xx-core, palmas, and
tps65010, have undergone minor code improvements to enhance
consistency and fix race conditions.
- The syscon driver now utilizes the regmap max_register_is_0
capability for consistent register map configuration across syscons
of all sizes.
- New device support has been added for QCS8300, qcs615, SA8255p, and
samsung,s2dos05, expanding the range of compatible hardware.
- The cros_ec driver now supports loading cros_ec_ucsi on supported ECs
and avoids loading the charger with UCSI, streamlining functionality.
- The bd96801 driver now utilizes the more modern maple tree register
cache, improving performance.
- The da9052-spi driver has undergone a fix to change the read-mask to
write-mask, preventing potential issues.
- Unused declarations in max77693 have been removed, and support for
samsung,s2dos05 has been added, enhancing code clarity and device
compatibility.
- Error handling in cs42l43 has been fixed to avoid unbalanced
regulator put and ensure proper synchronization during driver
removal.
- The wcd934x driver now uses MODULE_DEVICE_TABLE() instead of
MODULE_ALIAS(), improving code consistency.
- Documentation for qcom,tcsr, syscon, and atmel-smc has been updated
and reorganized for better clarity and maintainability.
- The intel_soc_pmic_bxtwc driver has undergone significant
improvements, including the use of IRQ domains for various devices,
fixing IRQ domain names duplication, and code refactoring for better
consistency and maintainability.
- The ipaq-micro driver has received a fix for a missing break
statement in the default case, enhancing code robustness.
- Support for the AXP323 PMIC has been added to the axp20x driver,
along with ensuring a clear relationship between IDs and model names,
and allowing multiple regulators, broadening hardware compatibility.
- The cs42l43 driver now disables IRQs during suspend for improved
power management.
- The adp5585 driver has reduced its dependencies by dropping the
obsolete dependency on COMPILE_TEST.
- Initial support for the MT6328 PMIC has been added to the mt6397
driver, expanding the range of supported hardware.
- The rtc-bd70528 driver has been simplified by dropping the IC name
from IRQ, improving code readability.
- Documentation for qcom,spmi-pmic, ti,twl, and zii,rave-sp has been
updated to enhance clarity and incorporate new features.
- The rt5033 driver has received a fix for a missing
regmap_del_irq_chip() in the error handling path.
- New device support has been added for MSM8917, and the
intel_soc_pmic_crc driver now supports non-ACPI instantiated
i2c_client.
- The 88pm886 driver has added support for the RTC cell, and the tqmx86
driver has improved its GPIO IRQ setup and added I2C IRQ support,
increasing functionality.
- The sprd,sc2731 DT schema has been updated and converted to YAML
format for better readability and maintainability.
* tag 'mfd-next-6.13' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd: (62 commits)
dt-bindings: mfd: bd71828: Use charger resistor in mOhm instead of MOhm
dt-bindings: mfd: sprd,sc2731: Convert to YAML
mfd: tqmx86: Add I2C IRQ support
mfd: tqmx86: Make IRQ setup errors non-fatal
mfd: tqmx86: Refactor GPIO IRQ setup
mfd: tqmx86: Improve gpio_irq module parameter description
mfd: tqmx86: Add board definitions for TQMx120UC, TQMx130UC and TQMxE41S
mfd: 88pm886: Add the RTC cell
dt-bindings: mfd: Add Realtek RTL9300 switch peripherals
mfd: intel_soc_pmic_crc: Add support for non ACPI instantiated i2c_client
mfd: intel_soc_pmic_*: Consistently use filename as driver name
dt-bindings: mfd: qcom,tcsr: Add compatible for MSM8917
mfd: rt5033: Fix missing regmap_del_irq_chip()
mfd: cgbc-core: Fix error handling paths in cgbc_init_device()
dt-bindings: mfd: aspeed: Support for AST2700
mfd: Switch back to struct platform_driver::remove()
dt-bindings: mfd: qcom,spmi-pmic: Document PMICs added in SM8750
mfd: rtc: bd7xxxx Drop IC name from IRQ
mfd: mt6397: Add initial support for MT6328
mfd: adp5585: Drop obsolete dependency on COMPILE_TEST
...
Pull regulator updates from Mark Brown:
"This was a quite quiet release for regulators on the drivers front,
but we do have two small but useful core improvements:
- Improve handling of cases where DT platforms specify both DT and
init_data based configuration for a single regulator.
- A helper of_regulator_get_optional() to simplify writing generic
bindings for regulator consumers in subsystems.
There's also some YAML conversions for the DT bindings which are a big
part of the diffstat"
* tag 'regulator-v6.13' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: dt-bindings: qcom,rpmh: Correct PM8550VE supplies
regulator: Switch back to struct platform_driver::remove()
regulator: doc: remove documentation comment for regulator_init
regulator: doc: add missing documentation for init_cb
regulator: rk808: Restrict DVS GPIOs to the RK808 variant only
regulator: rk808: Use dev_err_probe() in the probe path
regulator: rk808: Perform trivial code cleanups
regulator: dt-bindings: qcom,qca6390-pmu: add more properties for wcn6855
regulator: dt-bindings: lltc,ltc3676: convert to YAML
regulator: core: Use fsleep() to get best sleep mechanism
regulator: core: remove machine init callback from config
regulator: core: add callback to perform runtime init
regulator: core: do not silently ignore provided init_data
regulator: max5970: Drop unused structs
regulator: dt-bindings: vctrl-regulator: convert to YAML
regulator: qcom-smd: make smd_vreg_rpm static
regulator: Call of_node_put() only once in rzg2l_usb_vbus_regulator_probe()
regulator: isl6271a: Drop explicit initialization of struct i2c_device_id::driver_data to 0
regulator: Add devres version of of_regulator_get_optional()
regulator: Add of_regulator_get_optional() for pure DT regulator lookup
All FTSMPS525 regulators support LV and MV ranges; however,
the boot loader firmware will determine which range to use as
the device boots.
Nonetheless, the driver cannot determine which range was selected,
so hardcoding the ranges as either LV or MV will not cover all cases
as it's possible for the firmware to select a range not supported by
the driver's current hardcoded values.
To this end, combine the ranges for the FTSMPS525s into one struct
and point all regulators to the updated combined struct. This should
work on all boards regardless of which range is selected by the firmware
and more accurately caputres the capability of this regulator on a
hardware level.
Signed-off-by: Melody Olvera <quic_molvera@quicinc.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://patch.msgid.link/20241112002645.2803506-1-quic_molvera@quicinc.com
Signed-off-by: Mark Brown <broonie@kernel.org>
After commit 0edb555a65 ("platform: Make platform_driver::remove()
return void") .remove() is (again) the right callback to implement for
platform drivers.
Convert all platform drivers below drivers/regulator to use .remove(),
with the eventual goal to drop struct platform_driver::remove_new(). As
.remove() and .remove_new() have the same prototypes, conversion is done
by just changing the structure member name in the driver initializer.
A few whitespace changes are done en passant to make indention
consistent.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Link: https://patch.msgid.link/ab85510f83fa901e44d5d563fe6e768054229bfe.1731398433.git.u.kleine-koenig@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
