Higher voltage settings were unusable due to incorrect n_voltages values
causing registration failures. For example, setting aldo4 to 3.3V failed
with -EINVAL because the required selector (123) exceeded the allowed
range (n_voltages=117).
Fix by aligning n_voltages with the hardware register widths per the P1
datasheet [1]:
- BUCK: 255 (was 254), allows selectors 0-254, selector 255 is reserved
- LDO: 128 (was 117), allows selectors 0-127, selectors 0-10 are for
suspend mode, valid operational range is 11-127
This enables the full voltage range supported by the hardware.
Fixes: 8b84d712ad ("regulator: spacemit: support SpacemiT P1 regulators")
Link: https://developer.spacemit.com/documentation [1]
Signed-off-by: Guodong Xu <guodong@riscstar.com>
Link: https://patch.msgid.link/20260122-spacemit-p1-v1-1-309be27fbff9@riscstar.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add support for rk801 to the existing rk808 regulator driver.
It provides 4 BUCK, 2 LDO and 1 SWITCH.
Signed-off-by: Joseph Chen <chenjh@rock-chips.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
Link: https://patch.msgid.link/20260112124351.17707-4-chenjh@rock-chips.com
Signed-off-by: Lee Jones <lee@kernel.org>
ROHM BD72720 is a power management IC which integrates 10 buck and 11 LDO
regulators. This PMIC has plenty of commonalities with the BD71828 and
BD71879.
The BD72720 does also have similar 'run-level'-concept as the BD71828 had.
It allows controlling the regulator's 'en masse', although only BUCK1
and LDO1 can utilize this in BD72720. Similar to BD71828, this 'en
masse' -control is not supported by this driver.
Support the voltage and enable/disable state control for the BD72720.
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
Link: https://patch.msgid.link/88b82128648516d9dbb173044042f2a7a5dfdf1c.1765804226.git.mazziesaccount@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
The new ROHM BD72720 PMIC has similarities with the BD71828. It makes
sense to support the regulator control for both PMICs using the same
driver. It is often more clear to have the IC specific functions and
globals named starting with the chip-name. So, as a preparatory step,
prefix the BD71828 specific functions and globals with the bd71828.
It would be tempting to try also removing the chip ID from those
functions which will be common for both PMICs. I have bad experiences on
this as it tends to lead to problems when yet another IC is being
supported with the same driver, and we will have some functions used for
all, some for two of the three, and some for just one. At this point
I used to start inventing wildcards like BD718XX or BD7272X. This
approach is pretty much always failing as we tend to eventually have
something like BD73900 - where all the wildcard stuff will break down.
So, my approach these days is to:
- keep the original chip-id prefix for anything that had it already
(and avoid the churn).
- use same prefix for all things that are used by multiple ICs -
typically the chip-ID of the first chip. This typically matches also
the driver and file names.
- use specific chip-ID as a prefix for anything which is specific to
just one chip.
As a preparatory step to adding the BD72720, add bd71828 prefix to all
commonly usable functions and globals.
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Acked-by: Mark Brown <broonie@kernel.org>
Link: https://patch.msgid.link/df5c98c6392c3b52cd41e3d98d60b65a1585b2dd.1765804226.git.mazziesaccount@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
Merge series from Andreas Kemnade <andreas@kemnade.info>:
Add a driver for the TPS65185 regulator which provides the
comparatively high voltages needed for electronic paper displays.
Datasheet for the TPS65185 is at https://www.ti.com/lit/gpn/tps65185
To simplify things, include the hwmon part directly which is only
one temperature sensor and there are no other functions besides regulators
in this chip.
When converting to faux_device the dummy_regulator_driver was
made non-static however it isn't exported or defined anywhere
outside the file it is in. Make it static to avoid the following
sparse warning:
drivers/regulator/dummy.c:59:24: warning: symbol 'dummy_regulator_driver' was not declared. Should it be static?
Fixes: dcd2a9a555 ("regulator: dummy: convert to use the faux device interface")
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Link: https://patch.msgid.link/20260112154909.601987-1-ben.dooks@codethink.co.uk
Signed-off-by: Mark Brown <broonie@kernel.org>
Add a driver for the TPS65185 regulator. Implement handling of the various
gpio pins. Because the PWRUP (=enable) pin functionality can be achieved
by just using two bits instead, just ensure that it is set to a stable
value.
Implement the pair of symmetric LDOs as a single regulator because they
share a single voltage set register. As the VCOM regulator sits behind that
machinery, just define that one as a supply.
For simplicity, just add the temperature sensor (depending on external NTC)
directly.
There is a mechanism to measure some kick-back voltage during a defined EPD
operation, to calibrate the VCOM voltage setting and store that
non-volatile in the chip to be the power up default setup. That is not
implemented yet in the driver, but that also means that there is a
non-factory default value in these registers after power-up.
Tested-by: Josua Mayer <josua.mayer@jm0.eu>
Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
Link: https://patch.msgid.link/20260102-tps65185-submit-v3-2-23bda35772f2@kemnade.info
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from André Draszik <andre.draszik@linaro.org>:
With these attached patches it becomes possible again to support
hardware designs with multiple PMICs where individual rails of each act
as required supplies for rails of the other (due to the latter being
e.g. always-on), and vice-versa.
Google Pixel 6 and 6 Pro (oriole and raven) are examples of such
designs.
Rather than returning -EPORBE_DEFER in regulator_register() when
set_machine_constraints() fails with -EPROBE_DEFER (due to missing
required supplies), we still allow rail registration and try to
reresolve supplies each time a new rail gets registered.
This is implemented using a bus (regulator bus), which allows the core
to reresolve supplies for regulators that still need them whenever new
regulators (i.e. devices) are added.
Using a bus also solves existing problems around late resolution of
supplies as mentioned in the commit message introducing that bus.
The series starts with a few bug fixes and the last two commits
implement the changes mentioned above, but do depend on the bug fixes.
Since commit 98e48cd928 ("regulator: core: resolve supply for
boot-on/always-on regulators"), the regulator core returns
-EPROBE_DEFER if a supply can not be resolved at regulator_register()
time due to set_machine_constraints() requiring that supply (e.g.
because of always-on or boot-on).
In some hardware designs, multiple PMICs are used where individual
rails of each act as supplies for rails of the other, and vice-versa.
In such a design no PMIC driver can probe when registering one top-
level regulator device (as is common practice for almost all regulator
drivers in Linux) since that commit. Supplies are only considered when
their driver has fully bound, but because in a design like the above
two drivers / devices depend on each other, neither will have fully
bound while the other probes. The Google Pixel 6 and 6 Pro (oriole and
raven) are examples of such a design.
One way to make this work would be to register each rail as an
individual device, rather than just one top-level regulator device.
Then, fw-devlink and Linux' driver core could do their usual handling
of deferred device probe as each rail would be probed individually.
This approach was dismissed in [1] as each regulator driver would have
to take care of this itself.
Alternatively, we can change the regulator core to not fail
regulator_register() if a rail's required supply can not be resolved
while keeping the intended change from above mentioned commit, and
instead retry whenever a new rail is registered. This commit implements
such an approach:
If set_machine_constraints() requests probe deferral,
regulator_register() still succeeds and we retry setting
constraints as part of regulator_resolve_supply().
We still do not enable the regulator or allow consumers to use it
until constraints have been set (including resolution of the
supply) to prevent enabling of a regulator before its supply.
With this change, we keep track of regulators with missing required
supplies and can therefore try to resolve them again and try to set
the constraints again once more regulators become available.
Care has to be taken to not allow consumers to use regulators that
haven't had their constraints set yet. regulator_get() ensures that
and now returns -EPROBE_DEFER in that case.
The implementation is straight-forward, thanks to our newly introduced
regulator-bus. Locking in regulator_resolve_supply() has to be done
carefully, as a combination of regulator_(un)lock_two() and
regulator_(un)lock_dependent() is needed. The reason is that
set_machine_constraints() might call regulator_enable() which needs
rdev and all its dependents locked, but everything else requires to
only have rdev and its supply locked.
Link: https://lore.kernel.org/all/aRn_-o-vie_QoDXD@sirena.co.uk/ [1]
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Link: https://patch.msgid.link/20260109-regulators-defer-v2-8-1a25dc968e60@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
When a regulator A and its supply B are provided by different devices,
the driver implementing B might be last to probe (with A still
pending resolution of its supply B). While we try to resolve all
pending supplies for all regulators (including A) during
regulator_register() of B via regulator_register_resolve_supply(),
supply resolution will still not work for A as the driver for B hasn't
finished binding to the PMIC device corresponding to B at that stage
yet. The regulator core explicitly only allows supplies from other
devices to be used once the relevant driver has fully bound, mainly to
avoid having to deal with cases where B itself might -EPROBE_DEFER.
In this case, A's supply will only be resolved as part of the core's
regulator_init_complete_work_function(), which currently is scheduled
to run after 30s. This was added as a work-around in
commit 3827b64dba ("regulator: core: Resolve supplies before
disabling unused regulators") to cover this situation.
There are two problems with that approach:
* it potentially runs long after all our consumers have probed
* an upcoming change will allow regulator_register() to complete
successfully even when required supplies (e.g. due to always-on or
boot-on) are missing at register time, deferring full configuration
of the regulator (and usability by consumers, i.e. usually consumer
probe) until the supply becomes available.
Resolving supplies in the late work func can therefore make it
impossible for consumers to probe at all, as the driver core will not
know to reprobe consumers when supplies have resolved.
We could schedule an earlier work to try to resolve supplies sooner,
but that'd be racy as consumers of A might try to probe before A's
supply gets fully resolved via this extra work.
Instead, add a very simple regulator bus and add a dummy device with a
corresponding driver to it for each regulator that is missing its
supply during regulator_register(). This way, the driver core will call
our bus' probe whenever a new (regulator) device was successfully
bound, allowing us to retry resolving the supply during (our bus) probe
and to bind this dummy device if successful. In turn this means the
driver core will see a newly bound device and retry probing of all
pending consumers, if any.
With that in place, we can avoid walking the full list of all known
regulators to try resolve missing supplies during regulator_register(),
as the driver core will invoke the bus probe for regulators that are
still pending their supplies. We can also drop the code trying to
resolve supplies one last time before unused regulators get disabled,
as all supplies should have resolved at that point in time, and if they
haven't then there's no point in trying again, as the outcome won't
change.
Note: We can not reuse the existing struct device created for each
rail, as a device can not be part of a class and a bus simultaneously.
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Link: https://patch.msgid.link/20260109-regulators-defer-v2-7-1a25dc968e60@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Receiving and forwarding critical supply events seems like they're
important information and we shouldn't ignore errors occurring during
registration for such events.
With this change the supply is unset on event registration failure,
allowing us to potentially retry another time.
Fixes: 433e294c3c ("regulator: core: forward undervoltage events downstream by default")
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Link: https://patch.msgid.link/20260109-regulators-defer-v2-6-1a25dc968e60@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Since commit 98e48cd928 ("regulator: core: resolve supply for
boot-on/always-on regulators") we require that a regulator's supply has
been resolved before enabling the regulator. Furthermore,
regulator_get() also fails if the supply hasn't been resolved yet
(preventing consumers from enabling a regulator without its supply
known). In combination this means that regulator_resolve_supply() now
always runs before the regulator has been enabled via
set_machine_constraints().
The code here was meant to run after enabling the regulator in case the
supply hadn't been resolved at that time and can therefore never
execute anymore since that commit.
Remove it.
No functional change intended.
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Link: https://patch.msgid.link/20260109-regulators-defer-v2-5-1a25dc968e60@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
For always-on and boot-on regulators, regulator_register() is currently
trying to anticipate the requirement to resolve a supply early.
Unfortunately, this code executes too early, before we have potentially
updated the regulator's always_on constraint as part of
set_machine_constraints(), causing it to miss cases.
Rather than trying to hack it more, just defer to the outcome of
set_machine_constraints(). The latter returns early (without doing any
regulator initialisation) with -EPROBE_DEFER as of commit 'regulator:
core: move supply check earlier in set_machine_constraints()' and is
therefore safe to call multiple times to determine if supplies need to
be resolved early.
Commit 8a866d527a ("regulator: core: Resolve supply name earlier to
prevent double-init") (later updated by
commit 520fb17821 ("regulator: core: Fix regulator supply
registration with sysfs")) added these tests originally to avoid
calling set_machine_constraints() multiple times to try to avoid
voltage glitches due to all the regulator initialisation happening each
time. This isn't an issue anymore as per above.
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Link: https://patch.msgid.link/20260109-regulators-defer-v2-4-1a25dc968e60@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Since commit 98e48cd928 ("regulator: core: resolve supply for
boot-on/always-on regulators"), set_machine_constraints() can return
-EPROBE_DEFER very late, after it has done a lot of work and
configuration of the regulator.
This means that configuration will happen multiple times for no
benefit in that case. Furthermore, this can lead to timing-dependent
voltage glitches as mentioned e.g. in commit 8a866d527a ("regulator:
core: Resolve supply name earlier to prevent double-init").
We can know that it's going to fail very early, in particular before
going through the complete regulator configuration by moving some code
around a little.
Do so to avoid re-configuring the regulator multiple times, also
avoiding the voltage glitches if we can.
Fixes: 98e48cd928 ("regulator: core: resolve supply for boot-on/always-on regulators")
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Link: https://patch.msgid.link/20260109-regulators-defer-v2-3-1a25dc968e60@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
If late enabling of a supply regulator fails in
regulator_resolve_supply(), the code currently triggers a lockdep
warning:
WARNING: drivers/regulator/core.c:2649 at _regulator_put+0x80/0xa0, CPU#6: kworker/u32:4/596
...
Call trace:
_regulator_put+0x80/0xa0 (P)
regulator_resolve_supply+0x7cc/0xbe0
regulator_register_resolve_supply+0x28/0xb8
as the regulator_list_mutex must be held when calling _regulator_put().
To solve this, simply switch to using regulator_put().
While at it, we should also make sure that no concurrent access happens
to our rdev while we clear out the supply pointer. Add appropriate
locking to ensure that.
While the code in question will be removed altogether in a follow-up
commit, I believe it is still beneficial to have this corrected before
removal for future reference.
Fixes: 36a1f1b6dd ("regulator: core: Fix memory leak in regulator_resolve_supply()")
Fixes: 8e5356a736 ("regulator: core: Clear the supply pointer if enabling fails")
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Link: https://patch.msgid.link/20260109-regulators-defer-v2-2-1a25dc968e60@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
1)
In print_constraints_debug(), the power budget is printed as:
lldo2: 450 <--> 1300 mV at 900 mV 2147483647 mW budge, enabled
(note the missing t in budget). This is because there is a --count just
below the call to scnprintf(), to make space for the comma. All similar
calls to scnprintf() above add an extra space to the format string to
allow for that, but this one doesn't, so the last character t is
stripped instead. Update the format string to fix the message.
2)
Add the name of the supply to the failure message printed when the
supply can not be resolved when debug messages are enabled to help with
debug.
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Link: https://patch.msgid.link/20260109-regulators-defer-v2-1-1a25dc968e60@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Sync the driver with the binding. During review process a regulators
subnode was requested but neither driver nor test setup was updated.
Fixes: 12d821bd13 ("regulator: Add FP9931/JD9930 driver")
Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
Link: https://patch.msgid.link/20251223-fp9931-fix-v1-1-b19b4c1e7056@kemnade.info
Signed-off-by: Mark Brown <broonie@kernel.org>
Add support for the Maxim Integrated MAX77675 PMIC regulator.
The MAX77675 is a compact, highly efficient SIMO (Single Inductor Multiple Output)
power management IC that provides four programmable buck-boost switching regulators
with only one inductor. It supports up to 700mA total output current and operates
from a single-cell Li-ion battery.
An integrated power-up sequencer and I2C interface allow flexible startup
configuration and runtime control.
Signed-off-by: Joan Na <joan.na@analog.com>
Link: https://patch.msgid.link/20251207032907.4850-3-joan.na@analog.com
Signed-off-by: Mark Brown <broonie@kernel.org>
A few fixes that came in during the merge window, nothing too exciting -
the one core fix improves error propagation from gpiolib which hopefully
shouldn't actually happen but is safer.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmk6FNQACgkQJNaLcl1U
h9C3qgf9E7YZXR3nfhg/VgK7kqo5Q+5Wpn3FUF9WvZWcvHqAMf1muCUzq+KaA0yB
AGPEspSH+YmC1fYAVCDagBFp/cT/NSdzyP7GwtN75V88V4qbu28wpMAFNjSnoP7w
N3T4VhJQCqnHCyBbYUFcOemT3H6lzEsqAsnDvSJsSxOiH7w8H/0dYvbpv+X8wiWZ
R0DWolVBgqM3zjn7Dt2n4VM6jSpeDzg3zM+xWD9svVDVoRrcL0dWIaJLQMTcbu4e
63sHWn9148oza10dNMPXuMN78pNBpZRBE/aTu3uD1N9+8qJMCMu29UKokCbEsVfR
mbQ+AzymoRprRe78m2dfKvxi023mBQ==
=Zpyb
-----END PGP SIGNATURE-----
Merge tag 'regulator-fix-v6.19-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator fixes from Mark Brown:
"A few fixes that came in during the merge window, nothing too
exciting - the one core fix improves error propagation from gpiolib
which hopefully shouldn't actually happen but is safer"
* tag 'regulator-fix-v6.19-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: spacemit: Align input supply name with the DT binding
regulator: fixed: Rely on the core freeing the enable GPIO
regulator: check the return value of gpiod_set_value_cansleep()
In order to simplify ownership rules for enable GPIOs supplied by drivers
regulator_register() always takes ownership of them, even if it ends up
failing for some other reason. We therefore should not free the GPIO if
registration fails but just let the core worry about things.
Fixes: 636f4618b1 (regulator: fixed: fix GPIO descriptor leak on register failure)
Reported-by: Diederik de Haas <diederik@cknow-tech.com>
Closes: https://lore.kernel.org/r/DEPEYUF5BRGY.UKFBWRRE8HNP@cknow-tech.com
Tested-by: Diederik de Haas <diederik@cknow-tech.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://patch.msgid.link/20251204-regulator-fixed-fix-gpiod-leak-v1-1-48efea5b82c2@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
This is a relatively busy release for the regulator API, as well as a
good collection of new drivers we've got a little bit of core work and a
bunch of cleanup throughout the subsystem:
- Support for propagating undervoltage events to child regulators.
- Undo enables done on supplies when setting enabling regulators via
constraints fails.
- Pull in some gpiolib changes adding support for shared GPIOs to
the gpiolib core, using them to replace the open coded variant of this
that we've had in the regulator API for a long time.
- Support for Fitipower FP9931 and JD9330, Mediatek MT6316, MT6363 and
MT6373, NXP PF1550 and Qualcomm PMH01XX and PMCX0102
The PF1550 support was originally going to go via the MFD tree but
Krzysztof's cleanup work overlapped with it so I pulled in Lee's signed
tag with support for the device.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmkt72UACgkQJNaLcl1U
h9Dm2wf+JhjBLxviOozOhSv17wKnCYpApL12vPIHhv3lGu4J9wPiqqe3eB6PrTPo
xkuIb8u68wOveh7uLgr/kprH/YUxofrkCEwZjy57geSanuqIEzVoqU//4NKca9ND
UeoDiTYLx5JQVzlo12tSFhLCvDsFgdnemWFfubRPQGTJA/RElMxrNySf3yUQbYBE
ODpTGbXqt4LnYQTJRvVM8/0KzREpxD0X8fSISKpA3KYBFntMexZcgrs5pqijwfMS
Euxff2UpFzjodmYEusWfKOFeZXmd/cClF26Tol7oaeaurr1pNu1i0nBUprbd/rzL
YTV8QeiftLqER/h2iDX4f8iTmvVhzA==
=9IkF
-----END PGP SIGNATURE-----
Merge tag 'regulator-v6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator updates from Mark Brown:
"This is a relatively busy release for the regulator API, as well as a
good collection of new drivers we've got a little bit of core work and
a bunch of cleanup throughout the subsystem:
- Support for propagating undervoltage events to child regulators
- Undo enables done on supplies when setting enabling regulators via
constraints fails
- Pull in some gpiolib changes adding support for shared GPIOs to the
gpiolib core, using them to replace the open coded variant of this
that we've had in the regulator API for a long time
- Support for Fitipower FP9931 and JD9330, Mediatek MT6316, MT6363
and MT6373, NXP PF1550 and Qualcomm PMH01XX and PMCX0102
The PF1550 support was originally going to go via the MFD tree but
Krzysztof's cleanup work overlapped with it so I pulled in Lee's
signed tag with support for the device"
* tag 'regulator-v6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: (50 commits)
regulator: fp9931: Fix spelling mistake "failid" -> "failed"
regulator: core: Protect regulator_supply_alias_list with regulator_list_mutex
regulator: pf9453: Constify pointers to 'regulator_desc' wrap struct
regulator: pca9450: Constify pointers to 'regulator_desc' wrap struct
regulator: mt6358: Constify pointers to 'regulator_desc' wrap struct
regulator: bd96801: Constify pointers to 'regulator_desc' wrap struct
regulator: bd718x7: Constify pointers to 'regulator_desc' wrap struct
regulator: bd71828: Constify pointers to 'regulator_desc' wrap struct
regulator: bd71815: Constify pointers to 'regulator_desc' wrap struct
regulator: Use container_of_const() when all types are const
regulator: pca9450: Fix error code in probe()
regulator: qcomm-labibb: replace use of system_wq with system_dfl_wq
regulator: Add FP9931/JD9930 driver
dt-bindings: regulator: Add Fitipower FP9931/JD9930
dt-bindings: vendor-prefixes: Add Fitipower
regulator: make the subsystem aware of shared GPIOs
regulator: renesas-usb-vbus-regulator: Remove unused headers
regulator: pca9450: Add support for setting debounce settings
regulator: dt-bindings: pca9540: add debounce timer configuration
regulator: core: disable supply if enabling main regulator fails
...
The majority of changes at this time were about ASoC with a lot of
code refactoring works. From the functionality POV, there aren't much
to see, but we have a wide range of device-specific fixes and updates.
Here are some highlights:
- Continued ASoC API clean works, spanned over many files
- Added a SoundWire SCDA generic class driver with regmap support
- Enhancements and fixes for Cirrus, Intel, Maxim and Qualcomm.
- Support for ASoC Allwinner A523, Mediatek MT8189, Qualcomm QCM2290,
QRB2210 and SM6115, SpacemiT K1, and TI TAS2568, TAS5802, TAS5806,
TAS5815, TAS5828 and TAS5830
- Usual HD-audio and USB-audio quirks and fixups
- Support for Onkyo SE-300PCIE, TASCAM IF-FW/DM MkII
Some gpiolib changes for shared GPIOs are included along with this PR
for covering ASoC drivers changes.
-----BEGIN PGP SIGNATURE-----
iQJCBAABCAAsFiEEIXTw5fNLNI7mMiVaLtJE4w1nLE8FAmkwQ2UOHHRpd2FpQHN1
c2UuZGUACgkQLtJE4w1nLE8tIRAAjCHdIlMejNTCzGRlhsRSQVD6bo1wASXcjfJ6
COH84akbnA0oT5z7H7JnzTOmfjzxLJpwC8j6IpZ/9CQazanT5IIVE41FZquXZ1JB
RhQVzuGw9Pl4MaYVdFuRqIXjiP+msY1jpbo9/QXQo8D/B41wpmVTgzkFVW2rxPMy
0aBOu4Wpu+11aBpNBy6dXDiKQ5kDqn7zOLoFGgcf5wlFIvOGZJ0Wg/i0kvCjl+ia
xYiP+/F6xKOyTY1c98iqExbKzSSy4ddGFUwrkevm6bWpu8hkXiL1O0zMWOe769x6
0wy0b5zvsbtOQOxbtK5+8gdjJw7ycgDa441hDtsaXBBROYZEV3D6+XZJCfq8Tz8F
+vLH5lfZeLg+59eqt3GOMGlwBfuhH91qzukIYG3q9EQGOkNkZ19ySJnFMLom68Ei
TCfNzh/ggSGXA9qAmfBcPoizgC/j9o+v4kbLRQteuRRWxES1FxqeN9Ba3d5JcHT3
BQpz1bhUli73477D6voPcwXLiQlM+Alv4QUKTFr2nUnWUQKwMvkZFwiv2jTqVdDf
f71Usv7xdyM7XijgmXuLg+3n0UvCwUPBB+bv3a1Bu7G4iTB1deNKU8t9k+sBJpcX
aRs5ych3MiU/zG+KRMB5FEx31KzpKu+Kk9NQ207/1HLaNhTgD3cg2wS3T3qdRUPv
Yf6wFHs=
=1JUI
-----END PGP SIGNATURE-----
Merge tag 'sound-6.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound updates from Takashi Iwai:
"The majority of changes at this time were about ASoC with a lot of
code refactoring works. From the functionality POV, there isn't much
to see, but we have a wide range of device-specific fixes and updates.
Here are some highlights:
- Continued ASoC API cleanup work, spanned over many files
- Added a SoundWire SCDA generic class driver with regmap support
- Enhancements and fixes for Cirrus, Intel, Maxim and Qualcomm.
- Support for ASoC Allwinner A523, Mediatek MT8189, Qualcomm QCM2290,
QRB2210 and SM6115, SpacemiT K1, and TI TAS2568, TAS5802, TAS5806,
TAS5815, TAS5828 and TAS5830
- Usual HD-audio and USB-audio quirks and fixups
- Support for Onkyo SE-300PCIE, TASCAM IF-FW/DM MkII
Some gpiolib changes for shared GPIOs are included along with this PR
for covering ASoC drivers changes"
* tag 'sound-6.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (739 commits)
ALSA: hda/realtek: Add PCI SSIDs to HP ProBook quirks
ALSA: usb-audio: Simplify with usb_endpoint_max_periodic_payload()
ALSA: hda/realtek: fix mute/micmute LEDs don't work for more HP laptops
ALSA: rawmidi: Fix inconsistent indenting warning reported by smatch
ALSA: dice: fix buffer overflow in detect_stream_formats()
ASoC: codecs: Modify awinic amplifier dsp read and write functions
ASoC: SDCA: Fixup some more Kconfig issues
ASoC: cs35l56: Log a message if firmware is missing
ASoC: nau8325: Delete a stray tab
firmware: cs_dsp: Add test cases for client_ops == NULL
firmware: cs_dsp: Don't require client to provide a struct cs_dsp_client_ops
ASoC: fsl_micfil: Set channel range control
ASoC: fsl_micfil: Add default quality for different platforms
ASoC: intel: sof_sdw: Add codec_info for cs42l45
ASoC: sdw_utils: Add cs42l45 support functions
ASoC: intel: sof_sdw: Add ability to have auxiliary devices
ASoC: sdw_utils: Move codec_name to dai info
ASoC: sdw_utils: Add codec_conf for every DAI
ASoC: SDCA: Add terminal type into input/output widget name
ASoC: SDCA: Align mute controls to ALSA expectations
...
gpiod_set_value_cansleep() now returns an integer and can indicate
failures in the GPIO layer. Propagate any potential errors to regulator
core.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Link: https://patch.msgid.link/20251203084737.15891-1-bartosz.golaszewski@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
regulator_supply_alias_list was accessed without any locking in
regulator_supply_alias(), regulator_register_supply_alias(), and
regulator_unregister_supply_alias(). Concurrent registration,
unregistration and lookups can race, leading to:
1 use-after-free if an alias entry is removed while being read,
2 duplicate entries when two threads register the same alias,
3 inconsistent alias mappings observed by consumers.
Protect all traversals, insertions and deletions on
regulator_supply_alias_list with the existing regulator_list_mutex.
Fixes: a06ccd9c37 ("regulator: core: Add ability to create a lookup alias for supply")
Signed-off-by: sparkhuang <huangshaobo3@xiaomi.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20251127025716.5440-1-huangshaobo3@xiaomi.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>:
Use container_of_const(), which is preferred over container_of(), when
the argument 'ptr' and returned pointer are already const, for better
code safety and readability.
Some drivers already have const everywhere, so container_of_const can be
directly used. In few other drivers, the final pointer can be constified
that way.
Pointer to 'struct regulator_desc' is a pointer to const and the
wrapping structure (container) is not being modified, thus entire syntax
can be replaced to preferred and safer container_of_const().
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20251126-container-of-const-regulator-v1-8-eeec378144d4@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Pointer to 'struct regulator_desc' is a pointer to const and the
wrapping structure (container) is not being modified, thus entire syntax
can be replaced to preferred and safer container_of_const().
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20251126-container-of-const-regulator-v1-7-eeec378144d4@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Pointer to 'struct regulator_desc' is a pointer to const and the
wrapping structure (container) is not being modified, thus entire syntax
can be replaced to preferred and safer container_of_const().
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20251126-container-of-const-regulator-v1-6-eeec378144d4@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Pointer to 'struct regulator_desc' is a pointer to const and the
wrapping structure (container) is not being modified, thus entire syntax
can be replaced to preferred and safer container_of_const().
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20251126-container-of-const-regulator-v1-5-eeec378144d4@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Pointer to 'struct regulator_desc' is a pointer to const and the
wrapping structure (container) is not being modified, thus entire syntax
can be replaced to preferred and safer container_of_const().
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20251126-container-of-const-regulator-v1-4-eeec378144d4@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Pointer to 'struct regulator_desc' is a pointer to const and the
wrapping structure (container) is not being modified, thus entire syntax
can be replaced to preferred and safer container_of_const().
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20251126-container-of-const-regulator-v1-3-eeec378144d4@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Pointer to 'struct regulator_desc' is a pointer to const and the
wrapping structure (container) is not being modified, thus entire syntax
can be replaced to preferred and safer container_of_const().
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20251126-container-of-const-regulator-v1-2-eeec378144d4@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Use container_of_const(), which is preferred over container_of(), when
the argument 'ptr' and returned pointer are already const, for better
code safety and readability.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20251126-container-of-const-regulator-v1-1-eeec378144d4@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Andreas Kemnade <andreas@kemnade.info>:
Add a driver for the FP9931/JD9930 regulator which provides the
comparatively high voltages needed for electronic paper displays.
Datasheet for the FP9931 is at
https://www.fitipower.com/dl/file/flXa6hIchVeu0W3K
Although it is in English, it seems to be only downloadable
from the Chinese part of that website.
For the JD9930 there can be a datasheet found at
https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/196/JD9930_2D00_0.7_2D00_JUN_2D00_2019.pdf
To simplify things, include the hwmon part directly which is only
one register read and there are not other functions besides
regulators in this chip.
Return "PTR_ERR(pca9450->sd_vsel_gpio)" instead of "ret". The "ret"
variable is success at this point.
Fixes: 3ce6f4f943 ("regulator: pca9450: Fix control register for LDO5")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Link: https://patch.msgid.link/aSBqnPoBrsNB1Ale@stanley.mountain
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently if a user enqueues a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.
This lack of consistency cannot be addressed without refactoring the API.
This patch continues the effort to refactor worqueue APIs, which has begun
with the change introducing new workqueues and a new alloc_workqueue flag:
commit 128ea9f6cc ("workqueue: Add system_percpu_wq and system_dfl_wq")
commit 930c2ea566 ("workqueue: Add new WQ_PERCPU flag")
This specific workload do not benefit from a per-cpu workqueue, so use
the default unbound workqueue (system_dfl_wq) instead.
Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
Link: https://patch.msgid.link/20251106145003.245866-1-marco.crivellari@suse.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add a driver for the FP9931/JD9930 regulator. Implement handling of the PG
(power good), TS_EN (temperature sensor enable), and EN (enable regulators)
pins. Implement the pair of symmetric LDOs as a single regulator because
they share a single voltage set register. For simplicity, just add the
temperature sensor (depending on external NTC) directly.
Limitations:
- As these regulators are controlled together with the VCOM regulator via
the EN pin, some kind of management must be in place. As the enable op
is not called when the regulator is already enabled, simple refcounting
seems not to work to avoid clearing EN when one regulator is still
enabled. As these regulators are typically used together, this
limitation should not hurt hard, just provide the is_enabled op.
- As the VCOM step is quite odd (5V/255 steps), rounding is needed.
Due to some limitations in the regulator core, the max/min voltages in
the devicetree must match the idea of the driver how to round things
exactly.
- Night mode is not implemented, so only the FP9931 compatible is needed in
the driver, there is no REGULATOR_MODE_NIGHT and no clear definition in
the datasheet what it does, also the XON pin which seems to be an input
related to that night mode is not used.
Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
Link: https://patch.msgid.link/20251115-fp9931-submit-v3-3-92f5d0772b68@kemnade.info
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Bartosz Golaszewski <brgl@bgdev.pl>:
Problem statement: GPIOs are implemented as a strictly exclusive
resource in the kernel but there are lots of platforms on which single
pin is shared by multiple devices which don't communicate so need some
way of properly sharing access to a GPIO. What we have now is the
GPIOD_FLAGS_BIT_NONEXCLUSIVE flag which was introduced as a hack and
doesn't do any locking or arbitration of access - it literally just hand
the same GPIO descriptor to all interested users.
The proposed solution is composed of three major parts: the high-level,
shared GPIO proxy driver that arbitrates access to the shared pin and
exposes a regular GPIO chip interface to consumers, a low-level shared
GPIOLIB module that scans firmware nodes and creates auxiliary devices
that attach to the proxy driver and finally a set of core GPIOLIB
changes that plug the former into the GPIO lookup path.
The changes are implemented in a way that allows to seamlessly compile
out any code related to sharing GPIOs for systems that don't need it.
The practical use-case for this are the powerdown GPIOs shared by
speakers on Qualcomm db845c platform, however I have also extensively
tested it using gpio-virtuser on arm64 qemu with various DT
configurations.
GPIOLIB is now aware of shared GPIOs and - for platforms where access to
such pins is managed internally - we don't need to keep track of the
enable count.
Once all users in the kernel switch to using the new mechanism, we'll be
able to drop the internal counting of users from the regulator code.
Acked-by: Mark Brown <broonie@kernel.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Link: https://patch.msgid.link/20251112-gpio-shared-v4-10-b51f97b1abd8@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Make the different debounce timers configurable from the devicetree.
Depending on the board design, these have to be set different than the
default register values.
Signed-off-by: Martijn de Gouw <martijn.de.gouw@prodrive-technologies.com>
Link: https://patch.msgid.link/20251117202215.1936139-2-martijn.de.gouw@prodrive-technologies.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>:
This patch-set convert many functions to snd_soc_dapm_xxx().
This is preparation to move struct snd_soc_dapm_context into soc-dapm.c.
For backport easy, this patch-set is added for each drivers.
For 'always-on' and 'boot-on' regulators, the set_machine_constraints()
may enable supply before enabling the main regulator, however if the
latter fails, the function returns with an error but the supply remains
enabled.
When this happens, the regulator_register() function continues on the
error path where it puts the supply regulator. Since enabling the supply
is not balanced with a disable call, a warning similar to the following
gets issued from _regulator_put():
[ 1.603889] WARNING: CPU: 2 PID: 44 at _regulator_put+0x8c/0xa0
[ 1.603908] Modules linked in:
[ 1.603926] CPU: 2 UID: 0 PID: 44 Comm: kworker/u16:3 Not tainted 6.18.0-rc4 #0 NONE
[ 1.603938] Hardware name: Qualcomm Technologies, Inc. IPQ9574/AP-AL02-C7 (DT)
[ 1.603945] Workqueue: async async_run_entry_fn
[ 1.603958] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 1.603967] pc : _regulator_put+0x8c/0xa0
[ 1.603976] lr : _regulator_put+0x7c/0xa0
...
[ 1.604140] Call trace:
[ 1.604145] _regulator_put+0x8c/0xa0 (P)
[ 1.604156] regulator_register+0x2ec/0xbf0
[ 1.604166] devm_regulator_register+0x60/0xb0
[ 1.604178] rpm_reg_probe+0x120/0x208
[ 1.604187] platform_probe+0x64/0xa8
...
In order to avoid this, change the set_machine_constraints() function to
disable the supply if enabling the main regulator fails.
Fixes: 05f224ca66 ("regulator: core: Clean enabling always-on regulators + their supplies")
Signed-off-by: Gabor Juhos <j4g8y7@gmail.com>
Link: https://patch.msgid.link/20251107-regulator-disable-supply-v1-1-c95f0536f1b5@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Remove unnecessary semicolons reported by Coccinelle/coccicheck and the
semantic patch at scripts/coccinelle/misc/semicolon.cocci.
Signed-off-by: Chen Ni <nichen@iscas.ac.cn>
Link: https://patch.msgid.link/20251107085109.2316999-1-nichen@iscas.ac.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently if a user enqueues a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.
This lack of consistency cannot be addressed without refactoring the API.
This continues the effort to refactor worqueue APIs, which has begun
with the change introducing new workqueues and a new alloc_workqueue flag:
commit 128ea9f6cc ("workqueue: Add system_percpu_wq and system_dfl_wq")
commit 930c2ea566 ("workqueue: Add new WQ_PERCPU flag")
This specific workload do not benefit from a per-cpu workqueue, so use
the default unbound workqueue (system_dfl_wq) instead.
Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
Link: https://patch.msgid.link/20251106142914.227875-1-marco.crivellari@suse.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The validator is not happy:
Warning: drivers/regulator/pf9453-regulator.c:303 This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
Update the kernel-doc accordingly.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20251106114628.2302762-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>:
This series adds support for three new MediaTek PMICs: MT6316, MT6363
and MT6373 and their variants - used in board designs featuring the
MediaTek MT8196 Chromebook SoC, or the MT6991 Dimensity 9400 Smartphone
SoC.
In particular, MT6316 is a regulator, but the MT6363 and MT6373 PMICs
are multi-function devices, as they have and expose multiple sub-devices;
moreover, some of those also contain an interrupt controller, managing
internal IPs interrupts: for those, a chained interrupt handler is
registered, which parent is the SPMI controller itself.
This series adds support for all of the MT6316 regulator variants and
for MT6363, MT6373 SPMI PMICs and their interrupt controller.
Add a driver for the regulators found on the MT6363 PMIC, fully
controlled by SPMI interface.
This PMIC regulates voltage with an input range of 2.6-5.0V, and
features 10 buck converters and 26 LDOs.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://patch.msgid.link/20251027110527.21002-5-angelogioacchino.delregno@collabora.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add a driver for the regulators found on all types of the MediaTek
MT6316 SPMI PMIC, fully controlled by SPMI interface and featuring
four step down DCDC (buck) converters.
In particular, this includes support for:
- MT6316(BP/VP): 2+2 Phase (Phase 1: buck1+2, Phase 2: buck3+4)
- MT6316(CP/HP/KP): 3+1 Phase (Phase 1: buck1+2+4, Phase 2: buck3)
- MT6316(DP/TP): 4+0 Phase (Single phase, buck1+2+3+4)
Please note that the set/clear registers for the enable bits are
not documented in the datasheet version that I used as reference,
but those are used in the downstream driver and I verified that
are actually working as expected.
Besides, it's also worth clearly mentioning that the MT6316 PMICs
voltage selector register uses a weird 9-bits Big Endian format,
for which a driver-private helper is provided.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://patch.msgid.link/20251027110527.21002-3-angelogioacchino.delregno@collabora.com
Signed-off-by: Mark Brown <broonie@kernel.org>
In the commit referenced by the Fixes tag,
devm_gpiod_get_optional() was replaced by manual
GPIO management, relying on the regulator core to release the
GPIO descriptor. However, this approach does not account for the
error path: when regulator registration fails, the core never
takes over the GPIO, resulting in a resource leak.
Add gpiod_put() before returning on regulator registration failure.
Fixes: 5e6f3ae5c1 ("regulator: fixed: Let core handle GPIO descriptor")
Signed-off-by: Haotian Zhang <vulab@iscas.ac.cn>
Link: https://patch.msgid.link/20251028172828.625-1-vulab@iscas.ac.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Joy Zou <joy.zou@nxp.com>:
For the details, please check the patch commit log.
Signed-off-by: Joy Zou <joy.zou@nxp.com>
---
Joy Zou (3):
regulator: pf9453: change the device ID register address
regulator: pf9453: remove low power mode
regulator: pf9453: remove unused I2C_LT register
drivers/regulator/pf9453-regulator.c | 22 +---------------------
1 file changed, 1 insertion(+), 21 deletions(-)
---
base-commit: 98bd8b16ae57e8f25c95d496fcde3dfdd8223d41
change-id: 20251103-b4-next-pf9453-c9f8fb6e0c10
Best regards,
--
Joy Zou <joy.zou@nxp.com>
Remove unnecessary register OTP_Ver and change the device ID address to
0x1. Previous version chip is never mass production. So not broken
compatibility.
Signed-off-by: Joy Zou <joy.zou@nxp.com>
Link: https://patch.msgid.link/20251103-b4-next-pf9453-v1-1-a025d536eee1@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The .min_sel and .max_sel fields remained uninitialized in the new
linear_range, causing an error further down the line. Copy the old
values of these fields to the new one as they represent the range of
register values, which does not change.
Fixes: d2ad981151 ("regulator: bd718x7: Support external connection to scale voltages")
Signed-off-by: Maud Spierings <maudspierings@gocontroll.com>
Reviewed-by: Matti Vaittinen <mazziesaccount@gmail.com>
Link: https://patch.msgid.link/20251030-mini_iv-v3-2-ef56c4d9f219@gocontroll.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Oleksij Rempel <o.rempel@pengutronix.de>:
This series adds input supply definitions for the NXP PCA9450 PMIC.
Some systems detect power events such as undervoltage before the PMIC.
To allow correct propagation of such events, each regulator must define
its upstream input supply. The first patch updates the devicetree
binding to document new *-supply properties, and the second patch adds
matching .supply_name entries in the driver.
Changes in this series:
- Document INL1, INB13, INB26 and INB45 supply properties
- Link all LDO and BUCK regulators to their corresponding input groups
Add supply_name entries for all PCA9450 regulators to describe their
respective input pin groups (INB13, INB26, INB45, INL1). This links each
buck and LDO to the upstream supply that powers its input group.
On some systems, power faults such as undervoltage are detected before
the PMIC itself. Defining supply relationships allows the regulator
framework to propagate such events properly through the dependency
chain.
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Link: https://patch.msgid.link/20251027124415.989301-3-o.rempel@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
The Raspberry Pi drivers aren't useful on other architectures, so
only offer them on ARM and ARM64, except for build testing purposes.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Link: https://patch.msgid.link/20251027132219.2f3274f0@endymion
Signed-off-by: Mark Brown <broonie@kernel.org>
Add support for PMR735D PMIC voltage regulators which are present on
Kaanapali boards.
Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Jishnu Prakash <jishnu.prakash@oss.qualcomm.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://patch.msgid.link/20251023-pmr735d_regulator-v2-2-452e1b28cd38@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add regulator support for the pf1550 PMIC.
Signed-off-by: Samuel Kayode <samuel.kayode@savoirfairelinux.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
Tested-by: Sean Nyekjaer <sean@geanix.com>
Link: https://patch.msgid.link/20251001-pf1550-v12-3-a3302aa41687@savoirfairelinux.com
Signed-off-by: Lee Jones <lee@kernel.org>
Merge series from Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com>:
This series contains patches to update rpmh-regulator driver and
dt-bindings for supporting the PMIC voltage regulators present on the
boards with Qualcomm's next gen compute SoC - Glymur.
Device tree changes aren't part of this series and will be posted
separately after the official announcement of the Glymur SoC.
Initialize input regulator and gpios to proper values to have things
basically working as well as in the case when these things are
hardwired.
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Andreas Kemnade <akemnade@kernel.org>
Link: https://patch.msgid.link/20250917-sy7636-rsrc-v3-2-331237d507a2@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Add support for PMH0101/PMCX0102/PMH0110/PMH0104 PMIC voltage
regulators which are present on Glymur boards.
Introduce new LDOs & SMPSs under them (PMIC5 subtype 530 for
both).
For these new LDOs support a new optimum power mode(OPM). In
this mode LDO will automatically switch between high power mode
(HPM) and low power mode (LPM) based on the real-time LDO load
current. Its operation is analogous to SMPS AUTO mode.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Co-developed-by: Jishnu Prakash <jishnu.prakash@oss.qualcomm.com>
Signed-off-by: Jishnu Prakash <jishnu.prakash@oss.qualcomm.com>
Signed-off-by: Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com>
Link: https://patch.msgid.link/20250918-glymur-rpmh-regulator-driver-v3-4-184c09678be3@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently rpmh-regulator resource name inside CMD-DB follows this
format: `^(ldo|smp|bob|vs)[a-n][1-9][0-9]?$`
(eg - ldob11, smpa2, bobc1 etc)
Here `[a-n]` in the resource name signifies the `pmic-id`.
However, newer firmware follows a different format that also
includes the `bus_id` as well in the resource name.
New format:
`^(L|S|B)[1-9][0-9]?[A-N]_E[0-3]$`
(eg - L11B_E1, S2A_E0, B1C_E0 etc)
Here `_E[0-3]` at the end is the `bus_id`, and upper case `[A-N]`
is used to denote `pmic-id`, while the regulator `(ldo|smp|bob)`
is replaced with their initials in upper case `(L|S|B|VA)`.
To handle this properly, do the following:
- Remove the `resource_name` member from vreg init data
- Add `index` and `regulator_hw_type` new members, which will
contain the index number and the regulator hardware type
(SMPS/LDO/BOB/VS) which can be combined with the pmic-id read
from the devicetree to generate the resource_name.
- Choose new resource name format if `pmic-id` contains `_E`
in it, else fallback to old format.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com>
Link: https://patch.msgid.link/20250918-glymur-rpmh-regulator-driver-v3-3-184c09678be3@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Forward critical supply events downstream so consumers can react in
time. An under-voltage event on an upstream rail may otherwise never
reach end devices (e.g. eMMC).
Register a notifier on a regulator's supply when the supply is resolved,
and forward only REGULATOR_EVENT_UNDER_VOLTAGE to the consumer's notifier
chain. Event handling is deferred to process context via a workqueue; the
consumer rdev is lifetime-pinned and the rdev lock is held while calling
the notifier chain. The notifier is unregistered on regulator teardown.
No DT/UAPI changes. Behavior applies to all regulators with a supply.
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Link: https://patch.msgid.link/20251001105650.2391477-1-o.rempel@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
This round of updates contains a fair amount of new device support, a couple of fixes and
some refactoring. The most notable additions include new drivers for Loongson's Security
Engine, RNG and TPM, new drivers for TI's TPS6594 Power Button and BQ257xx Charger ICs.
The rest of the set provides a return value check fix and a refactoring to use a more modern
GPIO API for the VEXPRESS sysreg driver, the removal of a deprecated IRQ ACK function from the
MC13xxx RTC driver and a new DT binding for the aforementioned TI BQ257xx charger.
New Support & Features
- Add a suite of drivers for the Loongson Security Engine, including the core controller, a
Random Number Generator (RNG) and Trusted Platform Module (TPM) support.
- Introduce support for the TI TPS6594 PMIC's power button, including the input driver, MFD
cell registration, and a system power-off handler.
- Add comprehensive support for the TI BQ257xx series of charger ICs, including the core MFD
driver and a power supply driver for the charger functionality.
Improvements & Fixes
- Check the return value of devm_gpiochip_add_data() in the VEXPRESS sysreg driver to prevent
potential silent failures.
Cleanups & Refactoring
- Add a MAINTAINERS entry for the new Loongson Security Engine drivers.
- Convert the VEXPRESS sysreg driver to use the modern generic GPIO chip API.
Removals
- Remove the deprecated and unused mc13xxx_irq_ack() function from the MC13xxx RTC, input and
touchscreen drivers.
Device Tree Bindings Updates
- Add device tree bindings for the TI BQ25703A charger.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEdrbJNaO+IJqU8IdIUa+KL4f8d2EFAmjdMogACgkQUa+KL4f8
d2FYEA/+J3U3bzH0JdjGVscQD1vLq+PjT0MsYoNLHSNG55H0Q9FhEv2SVmnRG8LR
DPvYXqpLHcHTGpPdCK7RX6FhSmXMFqXiWFbn9/lQE/+MX41U0B9E7rbRVCH8m+Vw
TAOvR86DEcTZFq3BEPDfjc4Q0ZPHKpyo/HOW739frmwC/a66K6G70vKmO+LJlqMk
asBAZUfRs14iaZte8LDKfcYcvC4NrJqtLD9lxPiuGxapMCGvJ+uReo+44A0F+wb8
UNq+cwdFK2rqPAur5ehe8C6s9IsANF4+OmAbbmqxfkbroiSYR7I2SeUhgxU/b8Om
9v+NqfC7Xsb8lcTJ/c0qCW8NfBtOlqer1lEHGTU91fTCAhACb4j7OuJtnTusp9Nk
W9Z9QcfOv/Mt7I/SUw9n8SQdHgPt9tQa6iqcGrYGp3enm8BISeb2jTTgrkDcCkKb
UTH8xVmxFgda08RCmPDPvrK0ebQ6gQzdq4g5vN3or1tFIKQHplorbvaAQtCBK02h
8ef33KrQ4HLV/NjijYrnFhrhj0WYBwmRb8vr43t4wvUdvlOSuK+VswKGIMhQabT3
uU+YjtCt19siOIx47XZVpj1gKTr24OoK2B+U8zy5oHj7abrRNkseZ8NMeu0vGzCn
p+ThEq+dxGD0mskaufdbJhejjumgCFaYNElWNHJQUGhMxHM5vQE=
=h21C
-----END PGP SIGNATURE-----
Merge tag 'mfd-next-6.18' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd
Pull MFD updates from Lee Jones:
"This round of updates contains a fair amount of new device support, a
couple of fixes and some refactoring. The most notable additions
include new drivers for Loongson's Security Engine, RNG and TPM, new
drivers for TI's TPS6594 Power Button and BQ257xx Charger ICs.
The rest of the set provides a return value check fix and a
refactoring to use a more modern GPIO API for the VEXPRESS sysreg
driver, the removal of a deprecated IRQ ACK function from the MC13xxx
RTC driver and a new DT binding for the aforementioned TI BQ257xx
charger.
New Support & Features:
- Add a suite of drivers for the Loongson Security Engine, including
the core controller, a Random Number Generator (RNG) and Trusted
Platform Module (TPM) support.
- Introduce support for the TI TPS6594 PMIC's power button, including
the input driver, MFD cell registration, and a system power-off
handler.
- Add comprehensive support for the TI BQ257xx series of charger ICs,
including the core MFD driver and a power supply driver for the
charger functionality.
Improvements & Fixes:
- Check the return value of devm_gpiochip_add_data() in the VEXPRESS
sysreg driver to prevent potential silent failures.
Cleanups & Refactoring:
- Add a MAINTAINERS entry for the new Loongson Security Engine
drivers.
- Convert the VEXPRESS sysreg driver to use the modern generic GPIO
chip API.
Removals:
- Remove the deprecated and unused mc13xxx_irq_ack() function from
the MC13xxx RTC, input and touchscreen drivers.
Device Tree Bindings Updates:
- Add device tree bindings for the TI BQ25703A charger"
* tag 'mfd-next-6.18' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd: (69 commits)
mfd: simple-mfd-i2c: Add compatible string for LX2160ARDB
mfd: simple-mfd-i2c: Keep compatible strings in alphabetical order
dt-bindings: mfd: twl: Add missing sub-nodes for TWL4030 & TWL603x
dt-bindings: watchdog: Add SMARC-sAM67 support
dt-bindings: mfd: tps6594: Allow gpio-line-names
mfd: intel-lpss: Add Intel Wildcat Lake LPSS PCI IDs
mfd: 88pm886: Add GPADC cell
mfd: vexpress-sysreg: Use more common syntax for compound literals
mfd: rz-mtu3: Fix MTU5 NFCR register offset
mfd: max77705: Setup the core driver as an interrupt controller
mfd: cs42l43: Remove IRQ masking in suspend
mfd: cs42l43: Move IRQ enable/disable to encompass force suspend
mfd: ls2kbmc: Add Loongson-2K BMC reset function support
mfd: ls2kbmc: Introduce Loongson-2K BMC core driver
mfd: bd71828, bd71815: Prepare for power-supply support
dt-bindings: mfd: aspeed: Add AST2700 SCU compatibles
dt-bindings: mfd: Convert aspeed,ast2400-p2a-ctrl to DT schema
dt-bindings: mfd: fsl,mc13xxx: Add buttons node
dt-bindings: mfd: fsl,mc13xxx: Convert txt to DT schema
mfd: macsmc: Add "apple,t8103-smc" compatible
...
The current entry for the MAX77838 regulator is unselectable (as it
depended on a non-user-selectable config - REGMAP_I2C). Fix this by
making it select the config, and not depending on it.
Signed-off-by: Igor Belwon <igor.belwon@mentallysanemainliners.org>
Link: https://patch.msgid.link/20250917-maxreg-kconfig-fix-v1-1-1369f88d6272@mentallysanemainliners.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Add support for the regulators found in the SpacemiT P1 PMIC. This
PMIC provides 6 buck converters and 12 LDO regulators.
The PMIC is implemented as a multi-function device. These regulators
are probed based on this driver being named in a MFD cell in the simple
MFD I2C driver.
Signed-off-by: Alex Elder <elder@riscstar.com>
Link: https://patch.msgid.link/20250825172057.163883-4-elder@riscstar.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Ivaylo Ivanov <ivo.ivanov.ivanov1@gmail.com>:
This patchset adds support for the max77838 PMIC. It's used on the Galaxy
S7 lineup of phones, and provides regulators for the display.
The max77838 PMIC contains a BUCK regulator and 4 LDOs. It's primarily
used in the Samsung Galaxy S7 lineup and is accessed over I2C.
Signed-off-by: Ivaylo Ivanov <ivo.ivanov.ivanov1@gmail.com>
Link: https://patch.msgid.link/20250914130230.2622030-3-ivo.ivanov.ivanov1@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add support for the boost regulator found in the Texas Instruments
BQ25703. The boost regulator is capable of outputting between 4.48
and 20.8 volts and between 0 and 6.35 amps.
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20250904160530.66178-5-macroalpha82@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
Attach the power good gpio to the regulator device devres instead of the
parent device to fix problems if probe is run multiple times
(rmmod/insmod or some deferral).
Fixes: 8c485bedfb ("regulator: sy7636a: Initial commit")
Signed-off-by: Andreas Kemnade <akemnade@kernel.org>
Reviewed-by: Alistair Francis <alistair@alistair23.me>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Message-ID: <20250906-sy7636-rsrc-v1-2-e2886a9763a7@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Woodrow Douglass <wdouglass@carnegierobotics.com>:
I wrote this driver to read settings and state from the nxp pf530x
regulator. Please consider it for inclusion, any criticism is welcome.
This driver allows reading some regulator settings and adjusting
output voltage. It is based on information from the datasheet
at https://www.nxp.com/docs/en/data-sheet/PF5300.pdf
Signed-off-by: Woodrow Douglass <wdouglass@carnegierobotics.com>
Message-ID: <20250902-pf530x-v7-2-10eb2542f944@carnegierobotics.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Change the 'ret' variable from u32 to int to store negative error codes or
zero returned by of_property_read_u32().
Storing the negative error codes in unsigned type, doesn't cause an issue
at runtime but it's ugly as pants. Additionally, assigning negative error
codes to unsigned type may trigger a GCC warning when the -Wsign-conversion
flag is enabled.
No effect on runtime.
Signed-off-by: Qianfeng Rong <rongqianfeng@vivo.com>
Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
Fixes: 0fbeae70ee ("regulator: add SCMI driver")
Link: https://patch.msgid.link/20250829101411.625214-1-rongqianfeng@vivo.com
Signed-off-by: Mark Brown <broonie@kernel.org>
For ternary operators in the form of "a ? true : false", if 'a' itself
returns a boolean result, the ternary operator can be omitted. Remove
redundant ternary operators to clean up the code.
Signed-off-by: Liao Yuanhong <liaoyuanhong@vivo.com>
Message-ID: <20250828122737.43488-1-liaoyuanhong@vivo.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
In the current design, the `pm8008_regulator_get_voltage_sel()` callback
can return a negative value if the raw voltage value is read as 0 uV from
the PMIC HW register. This can cause the probe to fail when the
`machine_constraints_voltage()` check is called during the regulator
registration flow.
Fix this by using the helper `regulator_map_voltage_linear_range()` to
convert the raw value to a voltage selector inside the mentioned get
voltage selector function. This ensures that the value returned is always
within the defined range.
Signed-off-by: Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com>
Message-ID: <20250823-pm8008-negitive-selector-v1-1-52b026a4b5e8@quicinc.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The "priv->cdata" pointer isn't an error pointer; this should be a NULL
check instead. Otherwise it leads to a NULL pointer dereference in the
caller, rt5133_probe().
Fixes: 714165e1c4 ("regulator: rt5133: Add RT5133 PMIC regulator Support")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Link: https://patch.msgid.link/aKMc1oK-7yY4cD3K@stanley.mountain
Signed-off-by: Mark Brown <broonie@kernel.org>
There is a copy and paste error and we accidentally use "PTR_ERR(rdev)"
instead of "error". The "rdev" pointer is valid at this point.
Also there is no need to print the error code in the error message
because dev_err_probe() already prints that. So clean up the error
message a bit.
Fixes: 38c9f98db2 ("regulator: tps65219: Add support for TPS65215 Regulator IRQs")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Link: https://patch.msgid.link/aKRGmVdbvT1HBvm8@stanley.mountain
Signed-off-by: Mark Brown <broonie@kernel.org>
Replace calls of 'devm_kzalloc(dev, count * sizeof([type]), flags)'
with 'devm_kcalloc(dev, count, sizeof([type]), flags)' in
setup_feedback_loop() for safer memory allocation with built-in
overflow protection.
Signed-off-by: Qianfeng Rong <rongqianfeng@vivo.com>
Reviewed-by: Matti Vaittinen <mazziesaccount@gmail.com>
Link: https://patch.msgid.link/20250817142327.174531-1-rongqianfeng@vivo.com
Signed-off-by: Mark Brown <broonie@kernel.org>
With module test, there is error dump:
------------[ cut here ]------------
notifier callback pca9450_i2c_restart_handler already registered
WARNING: kernel/notifier.c:23 at notifier_chain_register+0x5c/0x88,
CPU#0: kworker/u16:3/50
Call trace:
notifier_chain_register+0x5c/0x88 (P)
atomic_notifier_chain_register+0x30/0x58
register_restart_handler+0x1c/0x28
pca9450_i2c_probe+0x418/0x538
i2c_device_probe+0x220/0x3d0
really_probe+0x114/0x410
__driver_probe_device+0xa0/0x150
driver_probe_device+0x40/0x114
__device_attach_driver+0xd4/0x12c
So use devm_register_sys_off_handler to let kernel handle the resource
free to avoid kernel dump.
Fixes: 6157e62b07 ("regulator: pca9450: Add restart handler")
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Link: https://patch.msgid.link/20250815-pca9450-v1-1-7748e362dc97@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
RT5133 is a highly-integrated chip. It includes 8 LDOs and 3 GPOs that can
be used to drive output high/low purpose. The dependency of the GPO block is
internally LDO1 Voltage.
Signed-off-by: Jeff Chang <jeff_chang@richtek.com>
Link: https://patch.msgid.link/20250813020910.2977555-2-jeff_chang@richtek.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Joy Zou <joy.zou@nxp.com>:
Add binding document and driver.
Signed-off-by: Joy Zou <joy.zou@nxp.com>
---
Changes in v3:
binding part
- change regulator node names into lowercase.
- add more description for nxp,i2c-crc-enable.
- remove the unnecessary nxp,dvs-run/standby-voltage property.
These changes come from review comments:
https://lore.kernel.org/imx/e9f38e38-7df7-4d19-b5c0-2f18aeebcc78@kernel.org/
- add regulator-state-mem property for example.
driver part
- convert to use maple tree register cache.
- change of_match_ptr() name to lowercase since dt-binding changed.
- add more nxp,i2c-crc-enable description for commit message.
- remove the of_parse_cb and dvs from pf0900_regulators since the
unnecessary property nxp,dvs-run/standby-voltage removed.
- add set_suspend_enable/disable/voltage for the SW regulator_ops.
the run/standby voltage can be adjusted via the API which regulator
driver provides is recommended.
These changes come from binding review comments:
https://lore.kernel.org/imx/e9f38e38-7df7-4d19-b5c0-2f18aeebcc78@kernel.org/
- add bitfield.h header due to build issue.
- correct the sw4 id.
- add PF0900 prefix for short macro define in order to avoid duplication.
- merge the same mask define in order to simplify code.
- Link to v2: https://lore.kernel.org/r/20250721-b4-pf09-v2-v2-0-e2c568548032@nxp.com
Changes in v2:
binding part
- modify the binding file name to match compatible string.
- add one space for dt_binding_check warning.
- remove unnecessary quotes from "VAON".
- remove the unnecessary empty line.
- move unevaluatedProperties after the $ref.
- move additionalProperties after regulator type.
- remove unnecessary regulator description
driver part
- modify the copyright comment block to C++ style.
- add reg_read/write for regmap_bus.
- remove original pf0900_pmic_read/write.
- remove many regulator operations.
- use regmap_read replace pf0900_pmic_read.
- use regmap_update_bits and regmap_write_bits replace pf0900_pmic_write.
- move the code from pf0900.h to pf0900-regulator.c and delete the header file.
- remove unmask status interrupts and add unmask regulator interrupts.
- remove many interrupts check warning print from irq_handler.
- add notifier for regulator event.
- remove unused macro define.
- add PF0900 prefix for IRQ macro define in order to avoid duplication.
- use GENMASK() and BIT() to replace mask marco define
- remove redundant enum pf0900_chip_type.
- remove redundant print info and comments.
- add dvs property present check because this property is optional.
- remove ret == -EINVAL check from sw_set_dvs() function.
- Link to v1: https://lore.kernel.org/imx/20250617102025.3455544-1-joy.zou@nxp.com/
---
Joy Zou (2):
dt-bindings: regulator: add PF0900 regulator yaml
regulator: pf0900: Add PMIC PF0900 support
.../devicetree/bindings/regulator/nxp,pf0900.yaml | 163 ++++
drivers/regulator/Kconfig | 8 +
drivers/regulator/Makefile | 1 +
drivers/regulator/pf0900-regulator.c | 975 +++++++++++++++++++++
4 files changed, 1147 insertions(+)
---
base-commit: 84b92a499e7eca54ba1df6f6c6e01766025943f1
change-id: 20250714-b4-pf09-v2-91cdee6d1272
Best regards,
--
Joy Zou <joy.zou@nxp.com>
devm_kzalloc() has already been initialized to full 0 space, there is no
need to use memset() to initialize again.
Signed-off-by: Liao Yuanhong <liaoyuanhong@vivo.com>
Link: https://patch.msgid.link/20250807123949.495193-1-liaoyuanhong@vivo.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Remove unnecessary semicolons reported by Coccinelle/coccicheck and the
semantic patch at scripts/coccinelle/misc/semicolon.cocci.
Signed-off-by: Chen Ni <nichen@iscas.ac.cn>
Link: https://patch.msgid.link/20250729040044.1851988-1-nichen@iscas.ac.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
This fixes an issue with the newly added code for handling large voltage
changes on regulators which require that individual voltage changes
cover a limited range, the check for convergence was broken.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmiV71cACgkQJNaLcl1U
h9BT/wf/RFUziTbJP13+I+Ce+BixwFOfTJ2+aE2xlCWAd8eyylxdOvZwRaxiiU8K
2o8mfyVpGitROyEgsuXDqiel1hFTSVpuFzT8NhGe9tc5RC+UtF1nuygsMvPAuUlR
cyrGF4aUSsEGr5R37lZh6dC/kJDHOxoQy+YEk9ngnnfWlddpHJsQMulWU3MIVAaG
IZ3KVQeZeEpCNkgKr50IG/TQh9bX8Dct/EPSxKhR4EjaKXvEyKcrMnbQpb7h7dxN
dUFpKk99EKpC6uI7jLIwUgIA4CCN8h2g0+B10zo4Kp2AQLltGs/H/gZJSCzKzEv8
3UTeyBz8Uzr4srsKRBiP8woqA6hjoA==
=xTjP
-----END PGP SIGNATURE-----
Merge tag 'regulator-fix-v6.17-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator fix from Mark Brown:
"This fixes an issue with the newly added code for handling large
voltage changes on regulators which require that individual voltage
changes cover a limited range, the check for convergence was broken"
* tag 'regulator-fix-v6.17-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: core: correct convergence check in regulator_set_voltage()
The conversion of all GPIO drivers to using the .set_rv() and
.set_multiple_rv() callbacks from struct gpio_chip (which - unlike their
predecessors - return an integer and allow the controller drivers to
indicate failures to users) is now complete and the legacy ones have
been removed. Rename the new callbacks back to their original names in
one sweeping change.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
The logic in regulator_set_voltage() which checks for a non-convergence
condition on a stepped regulator is flawed.
regulator_set_voltage() checks if the error in target voltage has increased
or decreased, and returns -EWOULDBLOCK if the error has not decreased
enough. The correct non-convergence condition is:
new_delta - delta > -rdev->constraints->max_uV_step
or equivalently:
delta - new_delta < rdev->constraints->max_uV_step
But the currently used condition is:
new_delta - delta > rdev->constraints->max_uV_step
Which may cause an infinite loop if the voltage error doesn't converge.
Fix this by correcting the convergence condition.
Suggested-by: Jon Hunter <jonathanh@nvidia.com>
Fixes: d511206dc7 ("regulator: core: repeat voltage setting request for stepped regulators")
Signed-off-by: Romain Gantois <romain.gantois@bootlin.com>
Link: https://patch.msgid.link/20250729-b4-regulator-stepping-fix-v1-1-3f7b8c55d7d7@bootlin.com
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The regulator_set_voltage() function may exhibit unexpected behavior if the
target regulator has a maximum voltage step constraint. With such a
constraint, the regulator core may clamp the requested voltage to a lesser
value, to ensure that the voltage delta stays under the specified limit.
This means that the resulting regulator voltage depends on the current
voltage, as well as the requested range, which invalidates the assumption
that a repeated request for a specific voltage range will amount to a noop.
Considering the case of a regulator with a maximum voltage step constraint
of 1V:
initial voltage: 2.5V
consumer requests 4V
expected result: 3.5V
resulting voltage: 3.5V
consumer requests 4V again
expected result: 4V
actual result: 3.5V
Correct this by repeating attempts to balance the regulator voltage until
the result converges.
Signed-off-by: Romain Gantois <romain.gantois@bootlin.com>
Link: https://patch.msgid.link/20250718-regulator-stepping-v2-1-e28c9ac5d54a@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The volatile_reg function is named as tps6287x_volatile_reg by mistake
when enabing the REGCACHE_MAPLE support.
Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Link: https://patch.msgid.link/20250714010456.4906-1-jszhang@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Luca Weiss <luca.weiss@fairphone.com>:
Document and add support for the regulators on PM7550 and PMR735B, which
can be paired with the Milos SoC.
Add RPMH regulators exposed by Qualcomm Technologies, Inc. PM7550 PMIC.
It has 6 FTS525 (FT-SMPS) and 23 LDOs with 3 different types.
L1-L11 are LDO515 LV NMOS, L12-L13 are LDO515 MV PMOS, L14-L23 are
LDO512 MV PMOS.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
Link: https://patch.msgid.link/20250711-pm7550-pmr735b-rpmh-regs-v2-4-bca8cc15c199@fairphone.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add RPMH regulators exposed by Qualcomm Technologies, Inc. PMR735B PMIC.
It has 12 LDOs with 2 different types, L4 & L10 are LDO512 LV PMOS
and the rest are LDO512 NMOS.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
Link: https://patch.msgid.link/20250711-pm7550-pmr735b-rpmh-regs-v2-3-bca8cc15c199@fairphone.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The TI TPS652G1 is a stripped down version of the TPS65224 PMIC. It
doesn't feature the multiphase buck converter nor any voltage
monitoring. Due to the latter there are no interrupts serviced. In case
of the TPS652G1 any interrupt related setup is just skipped.
Signed-off-by: Michael Walle <mwalle@kernel.org>
Acked-by: Mark Brown <broonie@kernel.org>
Link: https://patch.msgid.link/20250703113153.2447110-9-mwalle@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Instead of using conditionals or tri state operators throughout the
.probe() provide a description per variant. This will make it much
easier to add new variants later.
While at it, make the variable naming more consistent.
This patch is only compile-time tested.
Signed-off-by: Michael Walle <mwalle@kernel.org>
Acked-by: Mark Brown <broonie@kernel.org>
Link: https://patch.msgid.link/20250703113153.2447110-8-mwalle@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Commit 00c826525f ("regulator: tps6594-regulator: Add TI TPS65224 PMIC
regulators") added support for the TPS65224 and made the description of
the multi-phase buck converter variable depending on the variant of the
PMIC. But this was just done for MUTLI_BUCK12 and MULTI_BUCK12_34
configs probably because this variant only supports a multi-phase
configuration on buck 1 and 2. Remove the hardcoded value for the
remaining two configs, too as future PMIC variants might also support
these.
This is a preparation patch to refactor the regulator description and
is compile-time only tested.
Signed-off-by: Michael Walle <mwalle@kernel.org>
Acked-by: Mark Brown <broonie@kernel.org>
Link: https://patch.msgid.link/20250703113153.2447110-7-mwalle@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
In .probe() interrupt_count and nr_types is essentially the same. It
contains the number of different interrupt per LDO or buck converter.
Drop one. This is a preparation patch to further simplify the handling
of different variants of this PMIC.
This patch is only compile-time tested.
Signed-off-by: Michael Walle <mwalle@kernel.org>
Acked-by: Mark Brown <broonie@kernel.org>
Link: https://patch.msgid.link/20250703113153.2447110-6-mwalle@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
On some platforms, the sy8827n enable gpio may also be used for other
purpose, so make it NONEXCLUSIVE to support this case.
Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Acked-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Link: https://patch.msgid.link/20250629095716.841-1-jszhang@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Make several autosuspend functions mark last busy stamp and update
the documentation accordingly (Sakari Ailus).
-----BEGIN PGP SIGNATURE-----
iQFGBAABCAAwFiEEcM8Aw/RY0dgsiRUR7l+9nS/U47UFAmhjrvQSHHJqd0Byand5
c29ja2kubmV0AAoJEO5fvZ0v1OO1aigIAKypscFSfd/WsAlP4orLtd4xiLi7KQHa
NrOYv7sZBVHgx4S9BGqHavYM3qhOBH5qCg+yBtqb8v6vp/TIlJjF2v3+C8uAXAnl
9GI5Gc6sZp/lMhf5Vb4Ibf58/P9lg4A7mIvM+LtfeEUMTlRrp47Q/RQ0ah7S4tDj
rFyC92QmBnkDLoyQp5IbCWkdjlqGgyTZzz/+XnfV9fWwX1aiXqaB4EZ2nXSAlyBx
awvA4/t662SWlHsdQqll9vS/+ZB39LEWwa1jJ7XGIK8t6GSH+TTys3S9/PHR/ua3
Dlcd+14plDGlSOy97hY+z6NdSgxH/qcpRgFduu5KwVqEwo2fqNkeV9Q=
=pFYw
-----END PGP SIGNATURE-----
Merge tag 'pm-runtime-6.17-rc1'
Runtime PM updates related to autosuspend for 6.17
Make several autosuspend functions mark last busy stamp and update
the documentation accordingly (Sakari Ailus).
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Merge series from Sakari Ailus <sakari.ailus@linux.intel.com>:
Late last year I posted a set to switch to __pm_runtime_mark_last_busy()
and gradually get rid of explicit pm_runtime_mark_last_busy() calls in
drivers, embedding them in the appropriate pm_runtime_*autosuspend*()
calls. The overall feedback I got at the time was that this is an
unnecessary intermediate step, and removing the
pm_runtime_mark_last_busy() calls can be done after adding them to the
relevant Runtime PM autosuspend related functions. The latter part has
been done and is present in Rafael's tree at the moment, also see
<URL:https://lore.kernel.org/linux-pm/CAJZ5v0g7-8UWp6ATOy+=oGdxDaCnfKHBG_+kbiTr+
+VeuXZsUFQ@mail.gmail.com/>:
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
pm-runtime-6.17-rc1
pm_runtime_put_autosuspend(), pm_runtime_put_sync_autosuspend(),
pm_runtime_autosuspend() and pm_request_autosuspend() now include a call
to pm_runtime_mark_last_busy(). Remove the now-reduntant explicit call to
pm_runtime_mark_last_busy().
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Link: https://patch.msgid.link/20250704075444.3221445-1-sakari.ailus@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
drvdata::gpiods is supposed to hold an array of 'gpio_desc' pointers. But
the memory is allocated for only one pointer. This will lead to
out-of-bounds access later in the code if 'config::ngpios' is > 1. So
fix the code to allocate enough memory to hold 'config::ngpios' of GPIO
descriptors.
While at it, also move the check for memory allocation failure to be below
the allocation to make it more readable.
Cc: stable@vger.kernel.org # 5.0
Fixes: d6cd33ad71 ("regulator: gpio: Convert to use descriptors")
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/20250703103549.16558-1-mani@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently, the driver_data of the i2c ID table is wrong, so it won't
work if any mp886x user makes use of the ID table. Fortunately, there's
no such user in upstream source code, we can fix the issue by using
different ID table entry for mp8867 and mp8869.
Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Link: https://patch.msgid.link/20250629095918.912-1-jszhang@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently, the driver_data of the i2c ID table is wrong, so it won't
work if any sy8824x user makes use of the ID table. Fortunately, there's
no such user in upstream source code, we can fix the issue by using
different ID table entry for sy8824c, sy8824e, sy20276 and sy20278.
Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Link: https://patch.msgid.link/20250629095905.898-1-jszhang@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Enable regmap cache to reduce i2c transactions and corresponding
interrupts if regulator is accessed frequently.
Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Link: https://patch.msgid.link/20250629095107.804-1-jszhang@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Enable regmap cache to reduce i2c transactions and corresponding
interrupts if regulator is accessed frequently.
Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Link: https://patch.msgid.link/20250629095822.868-1-jszhang@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Enable regmap cache to reduce i2c transactions and corresponding
interrupts if regulator is accessed frequently.
Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Link: https://patch.msgid.link/20250629094803.776-1-jszhang@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
In probe(), two arrays of structs are allocated with the devm_kmalloc()
function, but the memory size of the allocations were given as the arrays'
length (pmic->common_irq_size for the first call and pmic->dev_irq_size for
the second devm_kmalloc call). The memory size should have been the total
memory needed.
This led to a heap overflow when the struct array was used. The issue was
first discovered with the PocketBeagle2 and BeaglePlay. The common and
device-specific structs are now allocated one at a time within the loop.
Fixes: 38c9f98db2 ("regulator: tps65219: Add support for TPS65215 Regulator IRQs")
Reported-by: Dhruva Gole <d-gole@ti.com>
Closes: https://lore.kernel.org/all/20250619153526.297398-1-d-gole@ti.com/
Tested-by: Robert Nelson <robertcnelson@gmail.com>
Acked-by: Andrew Davis <afd@ti.com>
Signed-off-by: Shree Ramamoorthy <s-ramamoorthy@ti.com>
Reviewed-by: Nishanth Menon <nm@ti.com>
Link: https://patch.msgid.link/20250620154541.2713036-1-s-ramamoorthy@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Failing to reset coupling_desc.n_coupled after freeing coupled_rdevs can
lead to NULL pointer dereference when regulators are accessed post-unbind.
This can happen during runtime PM or other regulator operations that rely
on coupling metadata.
For example, on ridesx4, unbinding the 'reg-dummy' platform device triggers
a panic in regulator_lock_recursive() due to stale coupling state.
Ensure n_coupled is set to 0 to prevent access to invalid pointers.
Signed-off-by: Alessandro Carminati <acarmina@redhat.com>
Link: https://patch.msgid.link/20250626083809.314842-1-acarmina@redhat.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>:
This series adds support for the DVFSRC regulators found on the MediaTek
MT8196 Chromebook SoC and the (unrelated) MT6893 Dimensity 1200.
The MediaTek Dimensity 1200 (MT6893) features the same DVFSRC
regulators as the other currently supported SoCs, but with a
different select value: add an array describing the possible
voltages for the VCORE and VSCP regulators, and assign it to
a new compatible for this SoC.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://patch.msgid.link/20250623120144.109359-3-angelogioacchino.delregno@collabora.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Previous commit 548d770c33 ("regulator: pca9450: Add support for mode
operations") added support for setting forced PWM mode on the buck
regulators for pca9450a and pca9450bc parts. However part pca9451a also
supports this feature, thus add support for it.
Fixes: 548d770c33 ("regulator: pca9450: Add support for mode operations")
Signed-off-by: Primoz Fiser <primoz.fiser@norik.com>
Link: https://patch.msgid.link/20250618063339.2508893-1-primoz.fiser@norik.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add shutdown hook so that the panel gets powered off with the system.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Link: https://patch.msgid.link/20250616154018.430004-1-marek.vasut+renesas@mailbox.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The datasheets for all the fan53555 variants (and clones using the same
interface) define so called soft start times, from enabling the regulator
until at least some percentage of the output (i.e. 92% for the rk860x
types) are available.
The regulator framework supports this with the enable_time property
but currently the fan53555 driver does not define enable_times for any
variant.
I ran into a problem with this while testing the new driver for the
Rockchip NPUs (rocket), which does runtime-pm including disabling and
enabling a rk8602 as needed. When reenabling the regulator while running
a load, fatal hangs could be observed while enabling the associated
power-domain, which the regulator supplies.
Experimentally setting the regulator to always-on, made the issue
disappear, leading to the missing delay to let power stabilize.
And as expected, setting the enable-time to a non-zero value
according to the datasheet also resolved the regulator-issue.
The datasheets in nearly all cases only specify "typical" values,
except for the fan53555 type 08. There both a typical and maximum
value are listed - 40uS apart.
For all typical values I've added 100uS to be on the safe side.
Individual details for the relevant regulators below:
- fan53526:
The datasheet for all variants lists a typical value of 150uS, so
make that 250uS with safety margin.
- fan53555:
types 08 and 18 (unsupported) are given a typical enable time of 135uS
but also a maximum of 175uS so use that value. All the other types only
have a typical time in the datasheet of 300uS, so give a bit margin by
setting it to 400uS.
- rk8600 + rk8602:
Datasheet reports a typical value of 260us, so use 360uS to be safe.
- syr82x + syr83x:
All datasheets report typical soft-start values of 300uS for these
regulators, so use 400uS.
- tcs452x:
Datasheet sadly does not report a soft-start time, so I've not set
an enable-time
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20250606190418.478633-1-heiko@sntech.de
Signed-off-by: Mark Brown <broonie@kernel.org>
Add missing OF dependency and drop of_match_ptr() use.
This fixes the following LKP report:
"
>> drivers/regulator/rpi-panel-v2-regulator.c:95:34: warning: 'rpi_panel_v2_dt_ids' defined but not used [-Wunused-const-variable=]
static const struct of_device_id rpi_panel_v2_dt_ids[] = {
^~~~~~~~~~~~~~~~~~~
"
Fixes: d49305862f ("regulator: rpi-panel-v2: Add regulator for 7" Raspberry Pi 720x1280")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202506100440.fyTGO7CG-lkp@intel.com/
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Link: https://patch.msgid.link/20250609223012.87764-1-marek.vasut+renesas@mailbox.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The BD718x7 needs to disable voltage monitoring for a duration of
certain voltage changes.
The comment explaining use of msleep(1) instead of a more accurate
delay(), was placed to a function which disabled the protection. The
actual sleeping is done in a different place of the code, after the
voltage has been changed.
Browsing through the comment and code after the years made me to scratch
my head for a second. I may have figured why me and so many fellow
developers are slowly getting bald.
Clarify things a bit and move the comment about required delay directly
above the sleep. Leave only a small comment explaining why the protection
is disabled to the spot where the logic for disabling is.
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Link: https://patch.msgid.link/a90cb77e66a253f4055bbb99672dc81c7457de66.1749533040.git.mazziesaccount@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add missing GPIOLIB dependency reported by the LKP test robot.
This fixes the following report:
"
kismet warnings: (new ones prefixed by >>)
>> kismet: WARNING: unmet direct dependencies detected for GPIO_REGMAP when selected by REGULATOR_RASPBERRYPI_TOUCHSCREEN_V2
WARNING: unmet direct dependencies detected for GPIO_REGMAP
Depends on [n]: GPIOLIB [=n]
Selected by [y]:
- REGULATOR_RASPBERRYPI_TOUCHSCREEN_V2 [=y] && REGULATOR [=y] && I2C [=y]
"
Fixes: d49305862f ("regulator: rpi-panel-v2: Add regulator for 7" Raspberry Pi 720x1280")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202506092341.enbNKMOR-lkp@intel.com/
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Link: https://patch.msgid.link/20250609200242.31271-1-marek.vasut+renesas@mailbox.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Add regulator for the 7" Raspberry Pi 720x1280 DSI panel based on ili9881.
This is the Raspberry Pi DSI Panel V2. The newer Raspberry Pi 5" and 7"
panels have a slightly different register map to the original one. Add a
new driver for this "regulator" chip, this time by exposing two GPIOs and
one PWM controller, both of which can be consumed by panel driver and
pwm-backlight respectively.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Link: https://patch.msgid.link/20250609000748.1665219-2-marek.vasut+renesas@mailbox.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Make the PWM mode on the buck controllers configurable from
devicetree. Some boards require forced PWM mode to keep the supply
ripple within acceptable limits under light load conditions.
Signed-off-by: Martijn de Gouw <martijn.de.gouw@prodrive-technologies.com>
Link: https://patch.msgid.link/20250525071823.819342-2-martijn.de.gouw@prodrive-technologies.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There is no point in having 'npname' a static variable. So remove the
static qualifier. This is cleaner and saves a few bytes.
On a x86_64, with allmodconfig:
Before:
======
text data bss dec hex filename
27949 12176 64 40189 9cfd drivers/regulator/tps6594-regulator.o
After:
=====
text data bss dec hex filename
27947 12112 0 40059 9c7b drivers/regulator/tps6594-regulator.o
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://patch.msgid.link/ebc53d4049ec19796ef07e1bb734de19a2814727.1748103005.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Mark Brown <broonie@kernel.org>
'struct tps6594_regulator_irq_type' are not modified in this driver.
Constifying this structure moves some data to a read-only section, so
increases overall security.
On a x86_64, with allmodconfig, as an example:
Before:
======
text data bss dec hex filename
25645 14480 64 40189 9cfd drivers/regulator/tps6594-regulator.o
After:
=====
text data bss dec hex filename
27949 12176 64 40189 9cfd drivers/regulator/tps6594-regulator.o
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://patch.msgid.link/1446fb1938f3f38115be3e53f5dda3c8bb0ba5a1.1748103005.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Mark Brown <broonie@kernel.org>
There is a missing call to of_node_put() if devm_kcalloc() fails.
Fix this by changing the code to use cleanup.h magic to drop the
refcount.
Fixes: 6b0cd72757 ("regulator: max20086: fix invalid memory access")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Link: https://patch.msgid.link/aDVRLqgJWMxYU03G@stanley.mountain
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
A very minor fix that came in during the merge window, checking for I/O
errors in the MAX14577 driver.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmhBmiMACgkQJNaLcl1U
h9A5sAf9F/hOszrNv4Css2Md5h2nYNg+GY/cWOK4wIaVBxXG0OSqJZMVoqyYn+tj
Wb9OJf11CSoC7OSfG/pgN6W61leWmZ97HCs6tAkkuCm9DdklHB7i5yz2oedliG7e
fx2a6FYsIzGMN5i/+57bQxmNjIiHgioK1A+s2pDru6TyHucTDdwUBPWIemnjoCEV
mpSdlmSxIhyoWapE+Ur4L5lHBATWKl98TjxO6lzIaqJmFe16jZpwZY8sXY0q9+qV
Lg+W+EAFs6pna6l0FY6lnriAlUSBJDMgTa0aM3cpvX9RwBnH9Z+V4ebjkSXJ8CJA
sXFWoQvdPGdt/Dxez5qnldpTioldGw==
=m+cK
-----END PGP SIGNATURE-----
Merge tag 'regulator-fix-v6.16-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator fix from Mark Brown:
"A very minor fix that came in during the merge window, checking for
I/O errors in the MAX14577 driver"
* tag 'regulator-fix-v6.16-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: max14577: Add error check for max14577_read_reg()
* Samsung Exynos ACPM:
* Populate child platform devices from device tree data
* Introduce a new API, `devm_acpm_get_by_node()`, for child devices to get the ACPM handle
* ROHM PMICs:
* Add support for the ROHM BD96802 scalable companion PMIC to the BD96801 core driver
* Add support for controlling the BD96802 using the BD96801 regulator driver
* Add support to the BD96805, which is almost identical to the BD96801
* Add support to the BD96806, which is similar to the BD96802
* Maxim MAX77759:
* Add a core driver for the MAX77759 companion PMIC
* Add a GPIO driver for the expander functions on the MAX77759
* Add an NVMEM driver to expose the non-volatile memory on the MAX77759
* STMicroelectronics STM32MP25:
* Add support for the STM32MP25 SoC to the stm32-lptimer
* Add support for the STM32MP25 to the clocksource driver, handling new register access requirements
* Add support for the STM32MP25 to the PWM driver, enabling up to two PWM outputs
* Broadcom BCM590xx:
* Add support for the BCM59054 PMU
* Parse the PMU ID and revision to support behavioral differences between chip revisions
* Add regulator support for the BCM59054
* Samsung S2MPG10:
* Add support for the S2MPG10 PMIC, which communicates via the Samsung ACPM firmware instead of I2C
* Exynos ACPM:
* Improve timeout detection reliability by using ktime APIs instead of a loop counter assumption
* Allow PMIC access during late system shutdown by switching to `udelay()` instead of a sleeping function
* Fix an issue where reading command results longer than 8 bytes would fail
* Silence non-error `-EPROBE_DEFER` messages during boot to clean up logs
* Exynos LPASS:
* Fix an error handling path by switching to `devm_regmap_init_mmio()` to prevent resource leaks
* Fix a bug where `exynos_lpass_disable()` was called twice in the remove function
* Fix another resource leak in the probe's error path by using `devm_add_action_or_reset()`
* Samsung SEC:
* Handle the s2dos05, which does not have IRQ support, explicitly to prevent warnings
* Fix the core driver to correctly handle errors from `sec_irq_init()` instead of ignoring them
* STMPE-SPI:
* Correct an undeclared identifier in the `MODULE_DEVICE_TABLE` macro
* MAINTAINERS:
* Adjust a file path for the Siemens IPC LED drivers entry to fix a broken reference
* Maxim Drivers:
* Correct the spelling of "Electronics" in Samsung copyright headers across multiple files
* General:
* Fix wakeup source memory leaks on device unbind for 88pm886, as3722, max14577, max77541, max77705,
max8925, rt5033, and sprd-sc27xx drivers
* Samsung SEC Drivers:
* Split the driver into a transport-agnostic core (`sec-core`) and transport-specific (`sec-i2c`,
`sec-acpm`) modules to support non-I2C devices
* Merge the `sec-core` and `sec-irq` modules to reduce memory consumption
* Move internal APIs to a private header to clean up the public API
* Improve code style by sorting includes, cleaning up headers, sorting device tables, and using helper
macros like `dev_err_probe()`, `MFD_CELL`, and `REGMAP_IRQ_REG`
* Make regmap configuration for s2dos05/s2mpu05 explicit to improve clarity
* Rework platform data and regmap instantiation to use OF match data instead of a large switch statement
* ROHM BD96801/2:
* Prepare the driver for new models by separating chip-specific data into its own structure
* Drop IC name prefix from IRQ resource names in both the MFD and regulator drivers for simplification
* Broadcom BCM590xx:
* Refactor the regulator driver to store descriptions in a table to ease support for new chips
* Rename BCM59056-specific data to prepare for the addition of other regulators
* Use `dev_err_probe()` for cleaner error handling
* Exynos ACPM:
* Correct kerneldoc warnings and use the conventional 'np' argument name
* General MFD:
* Convert `aat2870` and `tps65010` to use the per-client debugfs directory provided by the I2C core
* Convert `sm501`, `tps65010` and `ucb1x00` to use the new GPIO line value setter callbacks
* Constify `regmap_irq_chip` and other structures in `88pm886` to move data to read-only sections
* BCM590xx:
* Drop the unused "id" member from the `bcm590xx` struct in preparation for a replacement
* Samsung SEC Core:
* Remove forward declarations for functions that no longer exist
* SM501:
* Remove the unused `sm501_find_clock()` function
* New Compatibles:
* Google: Add a PMIC child node to the `google,gs101-acpm-ipc` binding
* ROHM: Add new bindings for `rohm,bd96802-regulator` and `rohm,bd96802-pmic`, and add compatibles
for BD96805 and BD96806
* Maxim: Add new bindings for `maxim,max77759-gpio`, `maxim,max77759-nvmem`, and the top-level
`maxim,max77759`
* STM: Add `stm32mp25` compatible to the `stm32-lptimer` binding
* Broadcom: Add `bcm59054` compatible
* Atmel/Microchip: Add `microchip,sama7d65-gpbr` and `microchip,sama7d65-secumod` compatibles
* Samsung: Add `s2mpg10` compatible to the `samsung,s2mps11` MFD binding
* MediaTek: Add compatibles for `mt6893` (scpsys), `mt7988-topmisc`, and `mt8365-infracfg-nao`
* Qualcomm: Add `qcom,apq8064-mmss-sfpb` and `qcom,apq8064-sps-sic` syscon compatibles
* Refactoring & Cleanup:
* Convert Broadcom BCM59056 devicetree bindings to YAML and split them into MFD and regulator parts
* Convert the Microchip AT91 secumod binding to YAML
* Drop unrelated consumer nodes from binding examples to reduce bloat
* Correct indentation and style in various DTS examples
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEdrbJNaO+IJqU8IdIUa+KL4f8d2EFAmg+xmQACgkQUa+KL4f8
d2FJAxAApmk3kxAlb9r6E268SY1qQSeQKhhzQZeQz1Dt9ZfMurgnou+EdY5juxCH
owu4AjyQdaC/eIJJRaBcBjcskmNRsVd7mGwQfhMyg7IvhM9k1PxTuad/PSRauGqy
p7XnYFYeDa9fwwAZ8qD01gpCenQ3oLm4ef05FGC5SDlqcZzxOzc4iGYgHYjE7ACp
Iuv5tN0JkxCzTGtpZ6kXn5tp895KcndzPWgS0eQxf6Plw2syF0KKxlVCWUfLjAaZ
Db1VFOkc2vgjhxuFPpybGzRhgtVKRdYRJqL4EQEhnB/u23cuxxqBSJ3BPGIjfqrA
h6zaxbYJyBF3cHz9kOqi99inN4T3cZssOSdqIVuWTYSuH+FDdsVi5BF2WlrSgWqn
hgyVZYjMEB4UbEU+0VdZMqTWjY0+kmAEl7xWQ++sp2cuTtYdcufrldLVl0d/HOCm
zLXia1A2KHgFoBFN/sP0ffZD9ceM/ng1h1tfz+48MWWO7obpwbdFNtWllblfpm9d
cYPlg0uddFljjzP/gm3jgJAZkMer2m5eSVfvf2L5VrSROFSfbxwHcvVgRTxmPR0K
1rQqLm1w2Tp8HCocuO95bRv5g0Z4jWDu+CssM1XZrEXaNCZ5E0qm374JArpAFctb
cAVFcLYSUT73S6lgBOjF05F2zGPCmqW26S+R2cMPcM2SA1N89Go=
=hiAm
-----END PGP SIGNATURE-----
Merge tag 'mfd-next-6.16' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd
Pull MFD updates from Lee Jones:
"Samsung Exynos ACPM:
- Populate child platform devices from device tree data
- Introduce a new API, 'devm_acpm_get_by_node()', for child devices
to get the ACPM handle
ROHM PMICs:
- Add support for the ROHM BD96802 scalable companion PMIC to the
BD96801 core driver
- Add support for controlling the BD96802 using the BD96801 regulator
driver
- Add support to the BD96805, which is almost identical to the
BD96801
- Add support to the BD96806, which is similar to the BD96802
Maxim MAX77759:
- Add a core driver for the MAX77759 companion PMIC
- Add a GPIO driver for the expander functions on the MAX77759
- Add an NVMEM driver to expose the non-volatile memory on the
MAX77759
STMicroelectronics STM32MP25:
- Add support for the STM32MP25 SoC to the stm32-lptimer
- Add support for the STM32MP25 to the clocksource driver, handling
new register access requirements
- Add support for the STM32MP25 to the PWM driver, enabling up to two
PWM outputs
Broadcom BCM590xx:
- Add support for the BCM59054 PMU
- Parse the PMU ID and revision to support behavioral differences
between chip revisions
- Add regulator support for the BCM59054
Samsung S2MPG10:
- Add support for the S2MPG10 PMIC, which communicates via the
Samsung ACPM firmware instead of I2C
Exynos ACPM:
- Improve timeout detection reliability by using ktime APIs instead
of a loop counter assumption
- Allow PMIC access during late system shutdown by switching to
'udelay()' instead of a sleeping function
- Fix an issue where reading command results longer than 8 bytes
would fail
- Silence non-error '-EPROBE_DEFER' messages during boot to clean up
logs
Exynos LPASS:
- Fix an error handling path by switching to
'devm_regmap_init_mmio()' to prevent resource leaks
- Fix a bug where 'exynos_lpass_disable()' was called twice in the
remove function
- Fix another resource leak in the probe's error path by using
'devm_add_action_or_reset()'
Samsung SEC:
- Handle the s2dos05, which does not have IRQ support, explicitly to
prevent warnings
- Fix the core driver to correctly handle errors from
'sec_irq_init()' instead of ignoring them
STMPE-SPI:
- Correct an undeclared identifier in the 'MODULE_DEVICE_TABLE' macro
MAINTAINERS:
- Adjust a file path for the Siemens IPC LED drivers entry to fix a
broken reference
Maxim Drivers:
- Correct the spelling of "Electronics" in Samsung copyright headers
across multiple files
General:
- Fix wakeup source memory leaks on device unbind for 88pm886,
as3722, max14577, max77541, max77705, max8925, rt5033, and
sprd-sc27xx drivers
Samsung SEC Drivers:
- Split the driver into a transport-agnostic core ('sec-core') and
transport-specific ('sec-i2c', 'sec-acpm') modules to support
non-I2C devices
- Merge the 'sec-core' and 'sec-irq' modules to reduce memory
consumption
- Move internal APIs to a private header to clean up the public API
- Improve code style by sorting includes, cleaning up headers,
sorting device tables, and using helper macros like
'dev_err_probe()', 'MFD_CELL', and 'REGMAP_IRQ_REG'
- Make regmap configuration for s2dos05/s2mpu05 explicit to improve
clarity
- Rework platform data and regmap instantiation to use OF match data
instead of a large switch statement
ROHM BD96801/2:
- Prepare the driver for new models by separating chip-specific data
into its own structure
- Drop IC name prefix from IRQ resource names in both the MFD and
regulator drivers for simplification
Broadcom BCM590xx:
- Refactor the regulator driver to store descriptions in a table to
ease support for new chips
- Rename BCM59056-specific data to prepare for the addition of other
regulators
- Use 'dev_err_probe()' for cleaner error handling
Exynos ACPM:
- Correct kerneldoc warnings and use the conventional 'np' argument
name
General MFD:
- Convert 'aat2870' and 'tps65010' to use the per-client debugfs
directory provided by the I2C core
- Convert 'sm501', 'tps65010' and 'ucb1x00' to use the new GPIO line
value setter callbacks
- Constify 'regmap_irq_chip' and other structures in '88pm886' to
move data to read-only sections
BCM590xx:
- Drop the unused "id" member from the 'bcm590xx' struct in
preparation for a replacement
Samsung SEC Core:
- Remove forward declarations for functions that no longer exist
SM501:
- Remove the unused 'sm501_find_clock()' function
New Compatibles:
- Google: Add a PMIC child node to the 'google,gs101-acpm-ipc'
binding
- ROHM: Add new bindings for 'rohm,bd96802-regulator' and
'rohm,bd96802-pmic', and add compatibles for BD96805 and BD96806
- Maxim: Add new bindings for 'maxim,max77759-gpio',
'maxim,max77759-nvmem', and the top-level 'maxim,max77759'
- STM: Add 'stm32mp25' compatible to the 'stm32-lptimer' binding
- Broadcom: Add 'bcm59054' compatible
- Atmel/Microchip: Add 'microchip,sama7d65-gpbr' and
'microchip,sama7d65-secumod' compatibles
- Samsung: Add 's2mpg10' compatible to the 'samsung,s2mps11' MFD
binding
- MediaTek: Add compatibles for 'mt6893' (scpsys), 'mt7988-topmisc',
and 'mt8365-infracfg-nao'
- Qualcomm: Add 'qcom,apq8064-mmss-sfpb' and 'qcom,apq8064-sps-sic'
syscon compatibles
Refactoring & Cleanup:
- Convert Broadcom BCM59056 devicetree bindings to YAML and split
them into MFD and regulator parts
- Convert the Microchip AT91 secumod binding to YAML
- Drop unrelated consumer nodes from binding examples to reduce bloat
- Correct indentation and style in various DTS examples"
* tag 'mfd-next-6.16' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd: (81 commits)
mfd: maxim: Correct Samsung "Electronics" spelling in copyright headers
mfd: maxim: Correct Samsung "Electronics" spelling in headers
mfd: sm501: Remove unused sm501_find_clock
mfd: 88pm886: Constify struct regmap_irq_chip and some other structures
dt-bindings: mfd: syscon: Add mediatek,mt8365-infracfg-nao
mfd: sprd-sc27xx: Fix wakeup source leaks on device unbind
mfd: rt5033: Fix wakeup source leaks on device unbind
mfd: max8925: Fix wakeup source leaks on device unbind
mfd: max77705: Fix wakeup source leaks on device unbind
mfd: max77541: Fix wakeup source leaks on device unbind
mfd: max14577: Fix wakeup source leaks on device unbind
mfd: as3722: Fix wakeup source leaks on device unbind
mfd: 88pm886: Fix wakeup source leaks on device unbind
dt-bindings: mfd: Correct indentation and style in DTS example
dt-bindings: mfd: Drop unrelated nodes from DTS example
dt-bindings: mfd: syscon: Add qcom,apq8064-sps-sic
dt-bindings: mfd: syscon: Add qcom,apq8064-mmss-sfpb
mfd: stmpe-spi: Correct the name used in MODULE_DEVICE_TABLE
dt-bindings: mfd: syscon: Add mt7988-topmisc
mfd: exynos-lpass: Fix another error handling path in exynos_lpass_probe()
...
This is a very quiet release, there was no work on the core and a good
chunk of the updates were the result of conversions to use newer GPIO
APIs. We did gain support for Analog ADP5055 and TI TPS65214 devices,
and there's a new restart handler for the PCA9450 which allows devices
using it to be properly power cycled on reboot, but otherwise it's minor
fixes and API updates.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmgzBksACgkQJNaLcl1U
h9DfSQf+KAyyETqQ504yew2Yin0jdPsHrlrPw9OmK/4gwk9DNvzAELGBqolQWaEV
vDaLniVbqDoFDZECDKfKHPkw1GRjo8CUd1JaMcEv+cUHvdO7cyRR/44Kguuc78Q7
nkaBrgyYA9iK+3hH3t7aK4oKHcLzAcdrFHgAIm5P0mld0pr1UrQmYlsQpvEEAhEb
TpxT+9V04DjPbpyNC4k0GCvJS1EXaS2X3kjKnowTSylCdxxGC7HbQK1QX0OSEvWV
5wJz+46bmcjAggf4PM8DlFtLCmLdMlb2+g0iNfikwvvBVBe0fhDW657apSTq18XS
+K9bnCEupseehFA/r+gjh1EFjFWPLQ==
=QoGH
-----END PGP SIGNATURE-----
Merge tag 'regulator-v6.16' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator updates from Mark Brown:
"This is a very quiet release, there was no work on the core and a good
chunk of the updates were the result of conversions to use newer GPIO
APIs.
We did gain support for Analog ADP5055 and TI TPS65214 devices, and
there's a new restart handler for the PCA9450 which allows devices
using it to be properly power cycled on reboot, but otherwise it's
minor fixes and API updates"
* tag 'regulator-v6.16' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: (24 commits)
regulator: qcom_spmi: Constify struct spmi_voltage_range
regulator: max8952: Correct Samsung "Electronics" spelling in copyright headers
regulator: dt-bindings: mt6357: Drop fixed compatible requirement
regulator: gpio: Use dev_err_probe
regulator: pca9450: Add restart handler
regulator: da9121: Fix Wvoid-pointer-to-enum-cast warning
regulator: tps65219: Add TI TPS65214 Regulator Support
regulator: tps65219: Add support for TPS65215 Regulator IRQs
regulator: tps65219: Add support for TPS65215 regulator resources
regulator: tps65219: Update struct names
regulator: pf9453: convert to use maple tree register cache
regulator: max20086: Change enable gpio to optional
regulator: max20086: Fix MAX200086 chip id
regulator: adp5055: Remove unneeded semicolon
regulator: adp5055: remove duplicate device table
regulator: adp5055: Add driver for adp5055
regulator: dt-bindings: adi,adp5055-regulator: Add adp5055 support
regulator: don't compare raw GPIO descriptor pointers
regulator: rpi-panel-attiny: use new GPIO line value setter callbacks
regulator: rpi-panel-attiny: use lock guards for the state mutex
...
The function max14577_reg_get_current_limit() calls the function
max14577_read_reg(), but does not check its return value. A proper
implementation can be found in max14577_get_online().
Add a error check for the max14577_read_reg() and return error code
if the function fails.
Fixes: b0902bbeb7 ("regulator: max14577: Add regulator driver for Maxim 14577")
Cc: stable@vger.kernel.org # v3.14
Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
Link: https://patch.msgid.link/20250526025627.407-1-vulab@iscas.ac.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
The BCM59056 and BCM59054 are very similar in terms of regulators. Add
the register definitions for the BCM59054 and enable support for it in
the driver.
Signed-off-by: Artur Weber <aweber.kernel@gmail.com>
Reviewed-by: Stanislav Jakubek <stano.jakubek@gmail.com>
Reviewed-by: Mark Brown <brooni@kernel.org>
Link: https://lore.kernel.org/r/20250515-bcm59054-v9-8-14ba0ea2ea5b@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
Previously, the driver used the BCM590XX prefix for register data
specific to the BCM59056. As we will be introducing other regulators
to this driver as well, make the BCM59056-specific values use the
BCM59056 prefix.
Signed-off-by: Artur Weber <aweber.kernel@gmail.com>
Reviewed-by: Stanislav Jakubek <stano.jakubek@gmail.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20250515-bcm59054-v9-7-14ba0ea2ea5b@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
Instead of filling in the regulator description programatically,
store the data in a struct. This will make it a bit nicer to
introduce support for other BCM590xx chips besides the BCM59056.
To do this, add a new struct type, bcm590xx_reg_data, to store
all of the necessary information. Drop the old IS_LDO, IS_GPLDO...
macros in favor of the "type" field in this struct. Adapt the
old bcm590xx_reg struct to the new types.
Signed-off-by: Artur Weber <aweber.kernel@gmail.com>
Reviewed-by: Stanislav Jakubek <stano.jakubek@gmail.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20250515-bcm59054-v9-6-14ba0ea2ea5b@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
Instead of calling dev_err() and returning PTR_ERR(...) separately, use
a single "return dev_err_probe" statement.
Signed-off-by: Artur Weber <aweber.kernel@gmail.com>
Reviewed-by: Stanislav Jakubek <stano.jakubek@gmail.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20250515-bcm59054-v9-5-14ba0ea2ea5b@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
'struct spmi_voltage_range' are only modified at runtime to compile a
field, n_voltages, that could be computed at compile time.
So, simplify spmi_calculate_num_voltages() and compute n_voltages at
compile time within the SPMI_VOLTAGE_RANGE macro.
Constifying these structures moves some data to a read-only section, so
increase overall security.
On a x86_64, with allmodconfig:
Before:
======
text data bss dec hex filename
85437 26776 512 112725 1b855 drivers/regulator/qcom_spmi-regulator.o
After:
=====
text data bss dec hex filename
86857 24760 512 112129 1b601 drivers/regulator/qcom_spmi-regulator.o
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://patch.msgid.link/ef2a4b6df61e19470ddf6cbd1f3ca1ce88a3c1a0.1747570556.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Mark Brown <broonie@kernel.org>
max20086_parse_regulators_dt() calls of_regulator_match() using an
array of struct of_regulator_match allocated on the stack for the
matches argument.
of_regulator_match() calls devm_of_regulator_put_matches(), which calls
devres_alloc() to allocate a struct devm_of_regulator_matches which will
be de-allocated using devm_of_regulator_put_matches().
struct devm_of_regulator_matches is populated with the stack allocated
matches array.
If the device fails to probe, devm_of_regulator_put_matches() will be
called and will try to call of_node_put() on that stack pointer,
generating the following dmesg entries:
max20086 6-0028: Failed to read DEVICE_ID reg: -121
kobject: '\xc0$\xa5\x03' (000000002cebcb7a): is not initialized, yet
kobject_put() is being called.
Followed by a stack trace matching the call flow described above.
Switch to allocating the matches array using devm_kcalloc() to
avoid accessing the stack pointer long after it's out of scope.
This also has the advantage of allowing multiple max20086 to probe
without overriding the data stored inside the global of_regulator_match.
Fixes: bfff546aae ("regulator: Add MAX20086-MAX20089 driver")
Signed-off-by: Cosmin Tanislav <demonsingur@gmail.com>
Link: https://patch.msgid.link/20250508064947.2567255-1-demonsingur@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
During probe the gpio driver may not yet be available. Use
dev_err_probe to provide just the pertinent log.
Since dev_err_probe takes care of reporting the error value,
drop the redundant ret variable while at it.
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://patch.msgid.link/20250512185727.2907411-1-nm@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
When restarting a CPU powered by the PCA9450 power management IC, it
is beneficial to use the PCA9450 to power cycle the CPU and all its
connected peripherals to start up in a known state. The PCA9450 features
a cold start procedure initiated by an I2C command.
Add a restart handler so that the PCA9450 is used to restart the CPU.
The restart handler sends command 0x14 to the SW_RST register,
initiating a cold reset (Power recycle all regulators except LDO1, LDO2
and CLK_32K_OUT)
As the PCA9450 is a PMIC specific for the i.MX8M family CPU, the restart
handler priority is set just slightly higher than imx2_wdt and the PSCI
restart handler. This makes sure this restart handler takes precedence.
Signed-off-by: Paul Geurts <paul.geurts@prodrive-technologies.com>
Link: https://patch.msgid.link/20250505115936.1946891-1-paul.geurts@prodrive-technologies.com
Signed-off-by: Mark Brown <broonie@kernel.org>
'subvariant_id' is an enum, thus cast of pointer on 64-bit compile test
with clang and W=1 causes:
da9121-regulator.c:1132:24: error: cast to smaller integer type 'enum da9121_subvariant' from 'const void *' [-Werror,-Wvoid-pointer-to-enum-cast]
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://patch.msgid.link/20250509142448.257199-2-krzysztof.kozlowski@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Add support for TPS65214 regulators (bucks and LDOs) to the TPS65219
Regulator Driver as the TPS65214/TPS65214/TPS65219 PMIC devices have
significant register map overlap. TPS65214 is a Power Management IC with 3
Buck regulators (like TPS65215/TPS65219) and has 2 LDOs (like TPS65215).
Signed-off-by: Shree Ramamoorthy <s-ramamoorthy@ti.com>
Link: https://patch.msgid.link/20250425205736.76433-5-s-ramamoorthy@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Isolate all changes involving regulator IRQ types:
- Adding in TPS65215 resources
- Organize what resources are common vs device-specific
- How the chip_data uses these resource structs
- Restructure the probe() for multi-PMIC support.
Signed-off-by: Shree Ramamoorthy <s-ramamoorthy@ti.com>
Link: https://patch.msgid.link/20250425205736.76433-4-s-ramamoorthy@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Isolate all changes involving TPS65215 regulator desc and range resources.
- 'chipid' will identify which PMIC to support, and the corresponding
chip_data struct element to use in probe(). The chip_data struct is
helpful for any new PMICs added to this driver. The goal is to add future
PMIC info to necessary structs and minimize probe() function edits.
- The probe() will now loop through common (overlapping) regulators first,
then device-specific structs identified in the chip_data struct.
- Add TI TPS65215 PMIC to the existing platform_device_id struct, so the
regulator probe() can handle which PMIC chip_data information to use.
Signed-off-by: Shree Ramamoorthy <s-ramamoorthy@ti.com>
Link: https://patch.msgid.link/20250425205736.76433-3-s-ramamoorthy@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Isolate changes that involve renaming to indicate this resource is only for
TPS65219 or if it will be common for both devices. The renames are in
preparation for adding TPS65215 support.
Signed-off-by: Shree Ramamoorthy <s-ramamoorthy@ti.com>
Link: https://patch.msgid.link/20250425205736.76433-2-s-ramamoorthy@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The ROHM BD96806 is from the software perspective almost identical to
the ROHM BD96802. The main difference is different voltage tuning
ranges.
Add support differentiating these PMICs and provide correct voltages
for both models.
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/5d15660e0e71c70fda8df1694bec0e4fba7f251e.1744090658.git.mazziesaccount@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
The ROHM BD96805 is from the software perspective almost identical to
the ROHM BD96801. The main difference is different voltage tuning
ranges.
Add support differentiating these PMICs and provide correct voltages
for both models.
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/eab1369557b14a9762c41a5429d1ac87a4644d9e.1744090658.git.mazziesaccount@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
The ROHM BD96802 PMIC is primarily intended to be used as a companion
PMIC extending the capabilities of the BD96802 but it can be used on
it's own as well. When used as a companion PMIC, the start-up and
shut-down sequences are usually intitiated by the master PMIC using IF
pins.
The BD96802 looks from the digital interface point of view pretty much
like a reduced version of BD96801. It includes only 2 BUCKs and provides
the same error protection/detection mechanisms as the BD96801. Also, the
voltage control logic is same up to the register addresses.
Add support for controlling BD96802 using the BD96801 driver.
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/2fb2d0d4997c32d18bfa32cea4564352c00eebc8.1744090658.git.mazziesaccount@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
The resources generated in the BD96801 MFD driver are only visible to
the sub-drivers whose resource fields they are added. This makes
abbreviating the resource name with the IC name pointless. It just adds
confusion in those sub-drivers which do not really care the exact model
that generates the IRQ but just want to know the purpose IRQ was
generated for. Thus, as a preparatory fix to simplify adding support for
ROHM BD96802 PMIC the IC name "bd96801-" prefix was dropped from the IRQ
resource names. Adapt the regulator driver to this change.
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/73ec2425655ab19c9f0cf990419641ad36561590.1744090658.git.mazziesaccount@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Signed-off-by: Bo Liu <liubo03@inspur.com>
Link: https://patch.msgid.link/20250424010855.2662-1-liubo03@inspur.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from João Paulo Gonçalves <jpaulo.silvagoncalves@gmail.com>:
I'm working on integrating a system with a MAX20086 and noticed these
small issues in the driver: the chip ID for MAX20086 is 0x30 and not
0x40. Also, in my use case, the enable pin is always enabled by
hardware, so the enable GPIO isn't needed. Without these changes, the
driver fails to probe.
The enable pin can be configured as always enabled by the hardware. Make
the enable gpio request optional so the driver doesn't fail to probe
when `enable-gpios` property is not present in the device tree.
Cc: stable@vger.kernel.org
Fixes: bfff546aae ("regulator: Add MAX20086-MAX20089 driver")
Signed-off-by: João Paulo Gonçalves <jpaulo.silvagoncalves@gmail.com>
Link: https://patch.msgid.link/20250420-fix-max20086-v1-2-8cc9ee0d5a08@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
>From MAX20086-MAX20089 datasheet, the id for a MAX20086 is 0x30 and not
0x40. With the current code, the driver will fail on probe when the
driver tries to identify the chip id from a MAX20086 device over I2C.
Cc: stable@vger.kernel.org
Fixes: bfff546aae ("regulator: Add MAX20086-MAX20089 driver")
Signed-off-by: João Paulo Gonçalves <jpaulo.silvagoncalves@gmail.com>
Link: https://patch.msgid.link/20250420-fix-max20086-v1-1-8cc9ee0d5a08@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Remove unnecessary semicolons reported by Coccinelle/coccicheck and the
semantic patch at scripts/coccinelle/misc/semicolon.cocci.
Signed-off-by: Chen Ni <nichen@iscas.ac.cn>
Link: https://patch.msgid.link/20250414021950.3755819-1-nichen@iscas.ac.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
When building with -Wunused-const-variable, gcc points out an
device table that is not referenced anywhere:
drivers/regulator/adp5055-regulator.c:346:34: error: unused variable 'adp5055_dt_ids' [-Werror,-Wunused-const-variable]
346 | static const struct of_device_id adp5055_dt_ids[] = {
| ^~~~~~~~~~~~~~
The contents are the same as the second table in that file, so
just remove this copy.
Fixes: 147b2a96f2 ("regulator: adp5055: Add driver for adp5055")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://patch.msgid.link/20250410141006.866813-1-arnd@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Alexis Czezar Torreno <alexisczezar.torreno@analog.com>:
Introduce a regulator driver support for ADP5055. The device combines 3
high performance buck regulators in a 43-termminal land grid array
package. The device enables direct connection to high input voltages up
to 18V with no preregulator. Channel 1 and 2 deliver a programmable
output current of 3.5A or 7.5A or provide a single output with up to 14A
in parallel operation. Channel 3 has a programmable output current of
1.5A or 3A.
Merge series from Bartosz Golaszewski <brgl@bgdev.pl>:
Handling of shared GPIOs in the kernel needs some improvements. Let's
start with a simple change of not comparing GPIO descriptor pointers
directly as there's nothing that guarantees that the same physical pin
will always be represented by a single GPIO descriptor obtained by
calling gpiod_get().
Add ADI ADP5055 driver support. The device consists
of 3 buck regulators able to connect to high input voltages of up to 18V
with no preregulators.
Signed-off-by: Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
Link: https://patch.msgid.link/20250409-upstream-adp5055-v6-2-faa6e810deb1@analog.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There's no API contract saying that two GPIO descriptor pointers
obtained with a call to gpiod_get() (or one of the variants), that refer
to the same physical GPIO pin, always point to the same structure. Use
the dedicated comparator function.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Link: https://patch.msgid.link/20250407-gpiod-is-equal-v1-2-7d85f568ae6e@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Bartosz Golaszewski <brgl@bgdev.pl>:
struct gpio_chip now has callbacks for setting line values that return
an integer, allowing to indicate failures. We're in the process of
converting all GPIO drivers to using the new API. This series converts
the only GPIO controller under drivers/regulator/ and - while at it -
refactors the code a bit.
struct gpio_chip now has callbacks for setting line values that return
an integer, allowing to indicate failures. Convert the driver to using
them.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Link: https://patch.msgid.link/20250408-gpiochip-set-rv-regulator-v1-4-a18b6154b31a@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Use mutex lock guards from linux/cleanup.h to simplify the driver code.
Note that ret must be initialized in order to avoid a build warning as
scoped_guard() is implemented as a for loop.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Link: https://patch.msgid.link/20250408-gpiochip-set-rv-regulator-v1-3-a18b6154b31a@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from From git@z Thu Jan 1 00:00:00 1970
Peng Fan <peng.fan@nxp.com>:
Update the driver to fetch buck_gpio and buck_ds as GPIO descriptors.
Then drop the usage of 'of_gpio.h' which should be deprecated.
Based on commit 84618d5e31 ("regulator: max8997:
Convert to GPIO descriptors") as a reference to make the changes.
With the quirk fix for s5m8767 in of_gpio_try_fixup_polarity,
the polarity will be active-high, even if exynos5250 spring DTS
wrongly use active-low polarity. So using GPIO descriptors,
it should work as before.
The function pf9453_regulator_set_ramp_delay_regmap lacked detailed
parameter descriptions and return value explanations in its documentation.
This patch improves the documentation by adding specific details about
the parameters, their usage, and the return values, enhancing clarity for
developers.
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=20168
Signed-off-by: Yang Li <yang.lee@linux.alibaba.com>
Link: https://patch.msgid.link/20250407064532.22680-1-yang.lee@linux.alibaba.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Update the driver to fetch buck_gpio and buck_ds as GPIO descriptors.
Then drop the usage of 'of_gpio.h' which should be deprecated.
Based on commit 84618d5e31 ("regulator: max8997:
Convert to GPIO descriptors") as a reference to make the changes.
With the quirk fix for s5m8767 in of_gpio_try_fixup_polarity,
the polarity will be active-high, even if exynos5250 spring DTS
wrongly use active-low polarity. So using GPIO descriptors,
it should work as before.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Acked-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://patch.msgid.link/20250327004945.563765-2-peng.fan@oss.nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
around the fallout from the new CONFIG_OBJTOOL_WERROR=y feature,
which, despite its default-off nature, increased the profile/impact
of objtool warnings:
- Improve error handling and the presentation of warnings/errors.
- Revert the new summary warning line that some test-bot tools
interpreted as new regressions.
- Fix a number of objtool warnings in various drivers, core kernel
code and architecture code. About half of them are potential
problems related to out-of-bounds accesses or potential undefined
behavior, the other half are additional objtool annotations.
- Update objtool to latest (known) compiler quirks and
objtool bugs triggered by compiler code generation
- Misc fixes
Signed-off-by: Ingo Molnar <mingo@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQJFBAABCgAvFiEEBpT5eoXrXCwVQwEKEnMQ0APhK1gFAmfsRJMRHG1pbmdvQGtl
cm5lbC5vcmcACgkQEnMQ0APhK1g0YRAApiCylIv+0ucdKiDVAiI+cU7dqAggFp9h
ULcTuuCtVkfjYzIBw6y1Iw9JeYsyngYaI0VEMmLasJPt8o93K0vwBXGArXJKoMeu
UPcVS8N6+LqrHsWBXk919t1wgBZ7csgUxsCa1K47NKa3eCijrqI0N8PtcoYqKd+M
tOuyEcTCTfS0E2STv6Gpdp6VfDKms3Cn4MffLbcNWJXAsd1dwzDIG8IvAHUW9yG3
/ezVjm46thneNrRd9j/qU3mqNmhsec9NemHG7URaTznRKleWULhpmhGmcPYCh4Rj
AqGjmPtqprPELtgezeV+LIcmIm5UWF/f+0tzzBrsRy1MiY8ED2w+J51DHsLoHg8t
IfIkPyYX/zu9StXoRIwx/7C5NQqBlUfXGp6TuOOwzgbKOt+uRJOU6SnSQ06ZDwsa
l2brQ+NDfvF7EvGnvi18wIM+iqMc2jSuWl0AT94ATDuAZGCyzlmwluIYmDuLfyZM
JuYOogojt5vgHXDN6Ro3rDfK+tYckwez+Txx4oByGB3IJy75osBihtvHiYno7FgW
KXDbiAfLZ4SlfPzqxI6PPzaj3py6hG9LICEiL0U8VecC7bZ/22BZQCpdKko+/E/Y
PwlqCatqz/25U7GlsnfBISJO2VAyyUcbymvjnVXzZCi+IPAfeih6WcsTPJ96jxsa
LULLCnuvmoY=
=KkiI
-----END PGP SIGNATURE-----
Merge tag 'objtool-urgent-2025-04-01' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull objtool fixes from Ingo Molnar:
"These are objtool fixes and updates by Josh Poimboeuf, centered around
the fallout from the new CONFIG_OBJTOOL_WERROR=y feature, which,
despite its default-off nature, increased the profile/impact of
objtool warnings:
- Improve error handling and the presentation of warnings/errors
- Revert the new summary warning line that some test-bot tools
interpreted as new regressions
- Fix a number of objtool warnings in various drivers, core kernel
code and architecture code. About half of them are potential
problems related to out-of-bounds accesses or potential undefined
behavior, the other half are additional objtool annotations
- Update objtool to latest (known) compiler quirks and objtool bugs
triggered by compiler code generation
- Misc fixes"
* tag 'objtool-urgent-2025-04-01' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (36 commits)
objtool/loongarch: Add unwind hints in prepare_frametrace()
rcu-tasks: Always inline rcu_irq_work_resched()
context_tracking: Always inline ct_{nmi,irq}_{enter,exit}()
sched/smt: Always inline sched_smt_active()
objtool: Fix verbose disassembly if CROSS_COMPILE isn't set
objtool: Change "warning:" to "error: " for fatal errors
objtool: Always fail on fatal errors
Revert "objtool: Increase per-function WARN_FUNC() rate limit"
objtool: Append "()" to function name in "unexpected end of section" warning
objtool: Ignore end-of-section jumps for KCOV/GCOV
objtool: Silence more KCOV warnings, part 2
objtool, drm/vmwgfx: Don't ignore vmw_send_msg() for ORC
objtool: Fix STACK_FRAME_NON_STANDARD for cold subfunctions
objtool: Fix segfault in ignore_unreachable_insn()
objtool: Fix NULL printf() '%s' argument in builtin-check.c:save_argv()
objtool, lkdtm: Obfuscate the do_nothing() pointer
objtool, regulator: rk808: Remove potential undefined behavior in rk806_set_mode_dcdc()
objtool, ASoC: codecs: wcd934x: Remove potential undefined behavior in wcd934x_slim_irq_handler()
objtool, Input: cyapa - Remove undefined behavior in cyapa_update_fw_store()
objtool, panic: Disable SMAP in __stack_chk_fail()
...
Here is the big set of char, misc, iio, and other smaller driver
subsystems for 6.15-rc1. Lots of stuff in here, including:
- loads of IIO changes and driver updates
- counter driver updates
- w1 driver updates
- faux conversions for some drivers that were abusing the platform bus
interface
- coresight driver updates
- rust miscdevice binding updates based on real-world-use
- other minor driver updates
All of these have been in linux-next with no reported issues for quite a
while.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCZ+mNdQ8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+ylktACfYJix41jCCDbiFjnu7Hz4OIdcrUsAnRyF164M
1n5MhEhsEmvQj7WBwQLE
=AmmW
-----END PGP SIGNATURE-----
Merge tag 'char-misc-6.15-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
Pull char / misc / IIO driver updates from Greg KH:
"Here is the big set of char, misc, iio, and other smaller driver
subsystems for 6.15-rc1. Lots of stuff in here, including:
- loads of IIO changes and driver updates
- counter driver updates
- w1 driver updates
- faux conversions for some drivers that were abusing the platform
bus interface
- coresight driver updates
- rust miscdevice binding updates based on real-world-use
- other minor driver updates
All of these have been in linux-next with no reported issues for quite
a while"
* tag 'char-misc-6.15-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (292 commits)
samples: rust_misc_device: fix markup in top-level docs
Coresight: Fix a NULL vs IS_ERR() bug in probe
misc: lis3lv02d: convert to use faux_device
tlclk: convert to use faux_device
regulator: dummy: convert to use the faux device interface
bus: mhi: host: Fix race between unprepare and queue_buf
coresight: configfs: Constify struct config_item_type
doc: iio: ad7380: describe offload support
iio: ad7380: add support for SPI offload
iio: light: Add check for array bounds in veml6075_read_int_time_ms
iio: adc: ti-ads7924 Drop unnecessary function parameters
staging: iio: ad9834: Use devm_regulator_get_enable()
staging: iio: ad9832: Use devm_regulator_get_enable()
iio: gyro: bmg160_spi: add of_match_table
dt-bindings: iio: adc: Add i.MX94 and i.MX95 support
iio: adc: ad7768-1: remove unnecessary locking
Documentation: ABI: add wideband filter type to sysfs-bus-iio
iio: adc: ad7768-1: set MOSI idle state to prevent accidental reset
iio: adc: ad7768-1: Fix conversion result sign
iio: adc: ad7124: Benefit of dev = indio_dev->dev.parent in ad7124_parse_channel_config()
...
reservation" from Sourabh Jain changes powerpc's kexec code to use more
of the generic layers.
- The 2 patch series "get_maintainer: report subsystem status
separately" from Vlastimil Babka makes some long-requested improvements
to the get_maintainer output.
- The 4 patch series "ucount: Simplify refcounting with rcuref_t" from
Sebastian Siewior cleans up and optimizing the refcounting in the ucount
code.
- The 12 patch series "reboot: support runtime configuration of
emergency hw_protection action" from Ahmad Fatoum improves the ability
for a driver to perform an emergency system shutdown or reboot.
- The 16 patch series "Converge on using secs_to_jiffies() part two"
from Easwar Hariharan performs further migrations from
msecs_to_jiffies() to secs_to_jiffies().
- The 7 patch series "lib/interval_tree: add some test cases and
cleanup" from Wei Yang permits more userspace testing of kernel library
code, adds some more tests and performs some cleanups.
- The 2 patch series "hung_task: Dump the blocking task stacktrace" from
Masami Hiramatsu arranges for the hung_task detector to dump the stack
of the blocking task and not just that of the blocked task.
- The 4 patch series "resource: Split and use DEFINE_RES*() macros" from
Andy Shevchenko provides some cleanups to the resource definition
macros.
- Plus the usual shower of singleton patches - please see the individual
changelogs for details.
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQTTMBEPP41GrTpTJgfdBJ7gKXxAjgUCZ+nuqwAKCRDdBJ7gKXxA
jtNqAQDxqJpjWkzn4yN9CNSs1ivVx3fr6SqazlYCrt3u89WQvwEA1oRrGpETzUGq
r6khQUIcQImPPcjFqEFpuiSOU0MBZA0=
=Kii8
-----END PGP SIGNATURE-----
Merge tag 'mm-nonmm-stable-2025-03-30-18-23' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Pull non-MM updates from Andrew Morton:
- The series "powerpc/crash: use generic crashkernel reservation" from
Sourabh Jain changes powerpc's kexec code to use more of the generic
layers.
- The series "get_maintainer: report subsystem status separately" from
Vlastimil Babka makes some long-requested improvements to the
get_maintainer output.
- The series "ucount: Simplify refcounting with rcuref_t" from
Sebastian Siewior cleans up and optimizing the refcounting in the
ucount code.
- The series "reboot: support runtime configuration of emergency
hw_protection action" from Ahmad Fatoum improves the ability for a
driver to perform an emergency system shutdown or reboot.
- The series "Converge on using secs_to_jiffies() part two" from Easwar
Hariharan performs further migrations from msecs_to_jiffies() to
secs_to_jiffies().
- The series "lib/interval_tree: add some test cases and cleanup" from
Wei Yang permits more userspace testing of kernel library code, adds
some more tests and performs some cleanups.
- The series "hung_task: Dump the blocking task stacktrace" from Masami
Hiramatsu arranges for the hung_task detector to dump the stack of
the blocking task and not just that of the blocked task.
- The series "resource: Split and use DEFINE_RES*() macros" from Andy
Shevchenko provides some cleanups to the resource definition macros.
- Plus the usual shower of singleton patches - please see the
individual changelogs for details.
* tag 'mm-nonmm-stable-2025-03-30-18-23' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: (77 commits)
mailmap: consolidate email addresses of Alexander Sverdlin
fs/procfs: fix the comment above proc_pid_wchan()
relay: use kasprintf() instead of fixed buffer formatting
resource: replace open coded variant of DEFINE_RES()
resource: replace open coded variants of DEFINE_RES_*_NAMED()
resource: replace open coded variant of DEFINE_RES_NAMED_DESC()
resource: split DEFINE_RES_NAMED_DESC() out of DEFINE_RES_NAMED()
samples: add hung_task detector mutex blocking sample
hung_task: show the blocker task if the task is hung on mutex
kexec_core: accept unaccepted kexec segments' destination addresses
watchdog/perf: optimize bytes copied and remove manual NUL-termination
lib/interval_tree: fix the comment of interval_tree_span_iter_next_gap()
lib/interval_tree: skip the check before go to the right subtree
lib/interval_tree: add test case for span iteration
lib/interval_tree: add test case for interval_tree_iter_xxx() helpers
lib/rbtree: add random seed
lib/rbtree: split tests
lib/rbtree: enable userland test suite for rbtree related data structure
checkpatch: describe --min-conf-desc-length
scripts/gdb/symbols: determine KASLR offset on s390
...
* Added core MFD driver.
* Added charger driver.
* Added devicetree bindings for the charger and MFD core.
* Added Haptic controller support via the input subsystem.
* Added LED support.
* Added support to simple-mfd-i2c for fuel gauge and hwmon.
* Samsung S2MPU05 (Exynos7870 PMIC):
* Added core MFD support.
* Added Regulator support for 21 LDOs and 5 BUCKs.
* Added devicetree bindings for regulators and the PMIC core.
* TI TPS65215 & TPS65214:
* Added support to the existing TPS65219 driver.
* Added devicetree bindings.
* STMicroelectronics STM32MP25:
* Added support to the stm32-timers MFD driver.
* Added devicetree bindings.
* Congatec Board Controller (CGBC):
* Added HWMON support for internal sensors.
* Added support for the conga-SA8 module.
* Microchip LAN969X:
* Enabled the at91-usart MFD driver for this architecture.
* MediaTek MT6359:
* Added mfd_cell for mt6359-accdet to allow its driver to probe.
* AXP20X (AXP717): Added AXP717_TS_PIN_CFG register to writeable
regs for temperature sensor configuration.
* SM501: Switched to using BIT() macro to mitigate potential
integer overflows in GPIO functions.
* ENE KB3930: Added a NULL pointer check for off_gpios during
probe to prevent potential dereference.
* SYSCON: Added a check for invalid resource size to prevent
issues from DT misconfiguration.
* CGBC: Corrected signedness issues in cgbc_session_request.
* intel_soc_pmic_chtdc_ti / intel_soc_pmic_crc: Removed unneeded
explicit assignment to REGCACHE_NONE.
* ipaq-micro / tps65010: Switched to using str_enable_disable()
helpers for clarity and potential size reduction.
* upboard-fpga: Removed unnecessary ACPI_PTR() annotation.
* max8997: Removed unused max8997_irq_exit() function, using
devm_* helpers instead.
* lp3943: Dropped unused #include <linux/pwm.h> from the header
file.
* db8500-prcmu: Removed needless return statements in void APIs.
* qnap-mcu: Replaced commas with semicolons between expressions
for correctness.
* STA2X11: Removed the core MFD driver as the underlying
platform support was removed.
* EZX-PCAP: Removed the unused pcap_adc_sync function.
* PCF50633 (OpenMoko PMIC): Removed the entire driver (core, adc,
gpio, irq) as the underlying s3c24xx platform support was removed.
* Converted fsl,mcu-mpc8349emitx binding to YAML.
* Added qcom,msm8937-tcsr compatible.
* Added microchip,sama7d65-flexcom compatible.
* Added rockchip,rk3528-qos syscon compatible.
* Added airoha,en7581-pbus-csr syscon compatible.
* Added microchip,sama7d65-ddr3phy syscon compatible.
* Added microchip,sama7d65-sfrbu syscon compatible.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEdrbJNaO+IJqU8IdIUa+KL4f8d2EFAmfmqKQACgkQUa+KL4f8
d2G+rA//UU3UixCD8FsNN+o4DS7FbxdiSUCrATOBKia9MGfor4xCl6Qk9ZyO4sE1
Rr9zUrTb1xlCmMZupZlkV8TDHHcaiUbgmnKB161d4HMxCbju10MKlm7faz2vRMz3
a73ehTmUeNDiWG3t1/2zAyRt7PHPC2zakUlnXlLhLir12uR2jsDSeGOZh4xR7Hdi
5nkOA2xWbbeW4b+ybwZ32afbLtZFkLo80QvqDx/D9lMUnQO0FqKak0Zope7IzeqC
ilg+tIJOQRGEbjEVQ+pVXsPI6zfmO8eAja70F7sm+Q6TVDw2JhHU/YElHw+quiP+
aLYeE+DuSun1EYlK4ATQ0vzUdgsaOEWblF0eythctXFTfM9ZKhzWYdXEOvco7N4u
R9BYRtM/zGkxiScbr6igyjWZx7NPOsKEKIi5tOv+C2BAKb53om7vsNuMgvMDL/8W
gztmG0SMKwJSx2Dg7h1LLUfa3tG9QRFd0I+Yfaso3MtYmxnZVcJtM5IQbvzf6i/B
3fSiGP6PDNeJqbn9k3/7SB8Tb4XmJUN2LFdDtDuWVhgZpSDULkjpYxAXDIrbp+il
QNdLPiU1x7OzPkFZQxtXLt7yRmlEc2lu9jJHkGVM1M18TMexQiFxoSY9NxkbUj3o
T4s/PKGmRKHP9XxCmRSfu6Veql0MPUwtvkErlUf4GTLWK4oshag=
=ntF1
-----END PGP SIGNATURE-----
Merge tag 'mfd-next-6.15' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd
Pull MFD updates from Lee Jones:
"Maxim MAX77705:
- Added core MFD driver.
- Added charger driver.
- Added devicetree bindings for the charger and MFD core.
- Added Haptic controller support via the input subsystem.
- Added LED support.
- Added support to simple-mfd-i2c for fuel gauge and hwmon.
Samsung S2MPU05 (Exynos7870 PMIC):
- Added core MFD support.
- Added Regulator support for 21 LDOs and 5 BUCKs.
- Added devicetree bindings for regulators and the PMIC core.
TI TPS65215 & TPS65214:
- Added support to the existing TPS65219 driver.
- Added devicetree bindings.
STMicroelectronics STM32MP25:
- Added support to the stm32-timers MFD driver.
- Added devicetree bindings.
Congatec Board Controller (CGBC):
- Added HWMON support for internal sensors.
- Added support for the conga-SA8 module.
Microchip LAN969X:
- Enabled the at91-usart MFD driver for this architecture.
MediaTek MT6359:
- Added mfd_cell for mt6359-accdet to allow its driver to probe.
Other misc driver updates:
- AXP20X (AXP717): Added AXP717_TS_PIN_CFG register to writeable regs
for temperature sensor configuration.
- SM501: Switched to using BIT() macro to mitigate potential integer
overflows in GPIO functions.
- ENE KB3930: Added a NULL pointer check for off_gpios during probe
to prevent potential dereference.
- SYSCON: Added a check for invalid resource size to prevent issues
from DT misconfiguration.
- CGBC: Corrected signedness issues in cgbc_session_request
- intel_soc_pmic_chtdc_ti / intel_soc_pmic_crc: Removed unneeded
explicit assignment to REGCACHE_NONE.
- ipaq-micro / tps65010: Switched to using str_enable_disable()
helpers for clarity and potential size reduction.
- upboard-fpga: Removed unnecessary ACPI_PTR() annotation.
- max8997: Removed unused max8997_irq_exit() function, using devm_*
helpers instead.
- lp3943: Dropped unused #include <linux/pwm.h> from the header file.
- db8500-prcmu: Removed needless return statements in void APIs.
- qnap-mcu: Replaced commas with semicolons between expressions for
correctness.
- STA2X11: Removed the core MFD driver as the underlying platform
support was removed.
- EZX-PCAP: Removed the unused pcap_adc_sync function.
- PCF50633 (OpenMoko PMIC): Removed the entire driver (core, adc,
gpio, irq) as the underlying s3c24xx platform support was removed.
Devicetree updates:
- Converted fsl,mcu-mpc8349emitx binding to YAML
- Added qcom,msm8937-tcsr compatible
- Added microchip,sama7d65-flexcom compatible
- Added rockchip,rk3528-qos syscon compatible
- Added airoha,en7581-pbus-csr syscon compatible
- Added microchip,sama7d65-ddr3phy syscon compatible
- Added microchip,sama7d65-sfrbu syscon compatible"
* tag 'mfd-next-6.15' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd: (49 commits)
mfd: cgbc-core: Add support for conga-SA8
dt-bindings: mfd: syscon: Add microchip,sama7d65-sfrbu
dt-bindings: mfd: syscon: Add microchip,sama7d65-ddr3phy
mfd: cgbc: Add support for HWMON
dt-bindings: mfd: syscon: Add the pbus-csr node for Airoha EN7581 SoC
mfd: cgbc-core: Cleanup signedness in cgbc_session_request()
mfd: pcf50633: Remove remaining PCF50633 support
mfd: pcf50633: Remove unused platform IRQ code
mfd: pcF50633-gpio: Remove unused driver
mfd: pcf50633-adc: Remove unused driver
mfd: qnap-mcu: Convert commas to semicolons in qnap_mcu_exec()
mfd: mt6397-core: Add mfd_cell for mt6359-accdet
dt-bindings: mfd: syscon: Add rk3528 QoS register compatible
dt-bindings: mfd: atmel,sama5d2-flexcom: Add microchip,sama7d65-flexcom
mfd: ezx-pcap: Remove unused pcap_adc_sync
mfd: db8500-prcmu: Remove needless return in three void APIs
mfd: Remove STA2x11 core driver
mfd: max77620: Allow building as a module
mfd: ene-kb3930: Fix a potential NULL pointer dereference
dt-bindings: mfd: qcom,tcsr: Add compatible for MSM8937
...
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.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmfhaNUACgkQJNaLcl1U
h9C3lAf8C6tohTvyzPWCcqQN5RnoZSw1SNN9jloEL1xcMKEtRosTaqIYRDKhuKUL
Drumh8C1B9Kx2wrsvE+j1eX4gXCaPK9P7EZbH3h3WFXkFkov6MNsH+UmhOAVm3AT
U/JmYs6/iGng/OptlYsguahwgwyj2eLb8E5RzSg7KgKbNW47M7QcqpkarQpRB+Si
Fz5528UQwDPwD04R4SEIn85I1xnJWdFVyOdfQA32Ugh7l8Vhgf+Z7G1aH4/5hOz8
cYJKoZscgOIkJw4lsKbS/+dCo2haYJqKCcT68P8qGf8zr9yeLPzkLYqNf+NaW/wP
uhoJKDm0nqo/rC9T1810YQfbPrfg6w==
=oFD5
-----END PGP SIGNATURE-----
Merge tag 'regulator-v6.15' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
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"
...
If 'ctr_bit' is negative, the shift counts become negative, causing a
shift of bounds and undefined behavior.
Presumably that's not possible in normal operation, but the code
generation isn't optimal. And undefined behavior should be avoided
regardless.
Improve code generation and remove the undefined behavior by converting
the signed variables to unsigned.
Fixes the following warning with an UBSAN kernel:
vmlinux.o: warning: objtool: rk806_set_mode_dcdc() falls through to next function rk806_get_mode_dcdc()
vmlinux.o: warning: objtool: .text.rk806_set_mode_dcdc: unexpected end of section
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Mark Brown <broonie@kernel.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: https://lore.kernel.org/r/2023abcddf3f524ba478d64339996f25dc4097d2.1742852847.git.jpoimboe@kernel.org
Closes: https://lore.kernel.org/oe-kbuild-all/202503182350.52KeHGD4-lkp@intel.com/
According to AXP717 user manual, DCDC4 doesn't have a ramp delay like
DCDC1/2/3 do.
Remove it from the description and cleanup the macros.
Signed-off-by: Philippe Simons <simons.philippe@gmail.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Link: https://patch.msgid.link/20250318205147.42850-1-simons.philippe@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Use the hidden bank register to identify whether the LDO voltage is
fixed or variable. Remove the read of 'richtek,fixed-microvolt'
property.
Fixes: af1296d15d ("regulator: rtq2208: Add fixed LDO VOUT property and check that matches the constraints")
Signed-off-by: ChiYuan Huang <cy_huang@richtek.com>
Link: https://patch.msgid.link/dae0321b710518ce32260336e3cc9caf2ba84215.1742204502.git.cy_huang@richtek.com
Signed-off-by: Mark Brown <broonie@kernel.org>
When the core detects permanent regulator hardware failure or imminent
power failure of a critical supply, it will call hw_protection_shutdown in
an attempt to do a limited orderly shutdown followed by powering off the
system.
This doesn't work out well for many unattended embedded systems that don't
have support for shutdown and that power on automatically when power is
supplied:
- A brief power cycle gets detected by the driver
- The kernel powers down the system and SoC goes into shutdown mode
- Power is restored
- The system remains oblivious to the restored power
- System needs to be manually power cycled for a duration long enough
to drain the capacitors
Allow users to fix this by calling the newly introduced
hw_protection_trigger() instead: This way the hw_protection commandline or
sysfs parameter is used to dictate the policy of dealing with the
regulator fault.
Link: https://lkml.kernel.org/r/20250217-hw_protection-reboot-v3-8-e1c09b090c0c@pengutronix.de
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Reviewed-by: Tzung-Bi Shih <tzungbi@kernel.org>
Reviewed-by: Matti Vaittinen <mazziesaccount@gmail.com>
Cc: Benson Leung <bleung@chromium.org>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Fabio Estevam <festevam@denx.de>
Cc: Guenter Roeck <groeck@chromium.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Lukasz Luba <lukasz.luba@arm.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Matteo Croce <teknoraver@meta.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Rob Herring (Arm) <robh@kernel.org>
Cc: Rui Zhang <rui.zhang@intel.com>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: "Serge E. Hallyn" <serge@hallyn.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
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>
The dummy regulator driver does not need to create a platform device, it
only did so because it was simple to do. Change it over to use the
faux bus instead as this is NOT a real platform device, and it makes
the code even smaller than before.
Reviewed-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/2025021027-outclass-stress-59dd@gregkh
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
S2MPU05 is a PMIC by manufactured by Samsung, particularly used in
Exynos7870 based devices. Add driver support for controlling its 21 LDO
and 5 BUCK regulators.
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
Acked-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20250301-exynos7870-pmic-regulators-v3-3-808d0b47a564@disroot.org
Signed-off-by: Lee Jones <lee@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>
