Sometimes I get a NULL pointer dereference at boot time in kobject_get()
with the following call stack:
anatop_regulator_probe()
devm_regulator_register()
regulator_register()
regulator_resolve_supply()
kobject_get()
By placing some extra BUG_ON() statements I could verify that this is
raised because probing of the 'dummy' regulator driver is not completed
('dummy_regulator_rdev' is still NULL).
In the JTAG debugger I can see that dummy_regulator_probe() and
anatop_regulator_probe() can be run by different kernel threads
(kworker/u4:*). I haven't further investigated whether this can be
changed or if there are other possibilities to force synchronization
between these two probe routines. On the other hand I don't expect much
boot time penalty by probing the 'dummy' regulator synchronously.
Cc: stable@vger.kernel.org
Fixes: 259b93b21a ("regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in 4.14")
Signed-off-by: Christian Eggers <ceggers@arri.de>
Link: https://patch.msgid.link/20250311091803.31026-1-ceggers@arri.de
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently, we are unnecessarily holding a regulator_ww_class_mutex lock
when creating debugfs entries for a newly created regulator. This was
brought up as a concern in the discussion in commit cba6cfdc7c
("regulator: core: Avoid lockdep reports when resolving supplies").
This causes the following lockdep splat after executing
`ls /sys/kernel/debug` on my platform:
======================================================
WARNING: possible circular locking dependency detected
5.15.167-axis9-devel #1 Tainted: G O
------------------------------------------------------
ls/2146 is trying to acquire lock:
ffffff803a562918 (&mm->mmap_lock){++++}-{3:3}, at: __might_fault+0x40/0x88
but task is already holding lock:
ffffff80014497f8 (&sb->s_type->i_mutex_key#3){++++}-{3:3}, at: iterate_dir+0x50/0x1f4
which lock already depends on the new lock.
[...]
Chain exists of:
&mm->mmap_lock --> regulator_ww_class_mutex --> &sb->s_type->i_mutex_key#3
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&sb->s_type->i_mutex_key#3);
lock(regulator_ww_class_mutex);
lock(&sb->s_type->i_mutex_key#3);
lock(&mm->mmap_lock);
*** DEADLOCK ***
This lock dependency still exists on the latest kernel and using a newer
non-tainted kernel would still cause this problem.
Fix by moving sysfs symlinking and creation of debugfs entries to after
the release of the regulator lock.
Fixes: cba6cfdc7c ("regulator: core: Avoid lockdep reports when resolving supplies")
Fixes: eaa7995c52 ("regulator: core: avoid regulator_resolve_supply() race condition")
Signed-off-by: Ludvig Pärsson <ludvig.parsson@axis.com>
Link: https://patch.msgid.link/20250305-regulator_lockdep_fix-v1-1-ab938b12e790@axis.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This reverts commit cd7a38c40b.
When submitting the change above, it was thought that the origin of the
init_data should be a clear choice, from the driver or from DT but not
both.
It turns out some devices, such as qcom-msm8974-lge-nexus5-hammerhead,
relied on the old behaviour to override the init_data provided by the
driver, making it some kind of default if none is provided by the platform.
Using the init_data provided by the driver when it is present broke these
devices so revert the change to fixup the situation and add a comment
to make things a bit more clear
Reported-by: Luca Weiss <luca@lucaweiss.eu>
Closes: https://lore.kernel.org/lkml/5857103.DvuYhMxLoT@lucaweiss.eu
Fixes: cd7a38c40b ("regulator: core: do not silently ignore provided init_data")
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Link: https://patch.msgid.link/20250211-regulator-init-data-fixup-v1-1-5ce1c6cff990@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Pull regulator fixes from Mark Brown:
"A couple of fixes that have come in during the merge window: one that
operates the TPS6287x devices more within the design spec and can
prevent current surges when changing voltages and another more trivial
one for error message formatting"
* tag 'regulator-fix-v6.14-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: core: Add missing newline character
regulator: TPS6287X: Use min/max uV to get VRANGE
Pull regulator updates from Mark Brown:
"This was a very quiet release, aside from some smaller improvements we
have:
- Support for power budgeting on regulators, initially targeted at
some still in review support for PSE controllers but generally
useful
- Support for error interrupts from ROHM BD96801 devices
- Support for NXP PCA9452"
* tag 'regulator-v6.14' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: dt-bindings: Add regulator-power-budget-milliwatt property
regulator: Add support for power budget
regulator: core: Resolve supply using of_node from regulator_config
regulator: of: Implement the unwind path of of_regulator_match()
regulator: tps65219: Remove debugging helper function
regulator: tps65219: Remove MODULE_ALIAS
regulator: tps65219: Update driver name
regulator: tps65219: Use dev_err_probe() instead of dev_err()
regulator: dt-bindings: mt6315: Drop regulator-compatible property
regulator: pca9450: Add PMIC pca9452 support
regulator: dt-bindings: pca9450: Add pca9452 support
regulator: pca9450: Use dev_err_probe() to simplify code
regulator: pca9450: add enable_value for all bucks
regulator: bd96801: Add ERRB IRQ
Changing voltage might ignore slew rate and cause a current surge.
With current implementation the driver will get the regulator to change
the voltage range used during run time. According to communication I
have had with Texas Instruments, this is not intended, since the
Dynamic Voltage Scaling in the hardware is only designed to work
within a voltage range. The current implementation will therefore
ignore the slew rate that is defined in devicetree when the voltage
range is changed during use.
The current implementation will always select a voltage in the most
accurate range that can reach that voltage even though multiple ranges
are able to reach that voltage. There are 4 Voltage ranges with the
following reach:
0b00: 0.4-0.71875V (1.25mV step size)
0b01: 0.4-1.0375V (2.5mV)
0b10: 0.4-1.675V (5mV)
0b11: 0.8-3.3V (10mV)
This in practice means that a change from below to above 0.71875V will
use the smallest range(0b00) for the values below and the second
smallest range(0b01) for the voltages above (Up to 1.675V). I have
timed how long it takes to go from below 0.71875V to above. The
increase was 100mV which, with the slew rate set to 1250µV/µs. This
in theory should take 80µs to do. With the current implementation, it
takes 10µs on my hardware. Doing the same test with the slew rate set
to 5000µV/µs, which should take 20µs, also only takes 10µs to do on
my hardware. Not only is this not in line with the technical
specification for the regulator. It also causes a current surge. Which
when calculating the output current, as described in the technical
specification, compared to what I could observe on my hardware the real
output is ~1A higher (~1.2A) than what I calculated it to be(~0.2A).
I tested also transitioning from a bigger to a smaller range, and the
results were the same.
Instead, let's limit the voltage range to a single one, which is in
line with the intended use of the regulator. This is done by looking
up the minimum and maximum requested voltage specified in devicetree.
Signed-off-by: Jonas Andreasson <jonas.andreasson@axis.com>
Link: https://patch.msgid.link/20250121-tps-fix-v2-1-50cc4d0f1635@axis.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Previously, the regulator core resolved its supply only from the parent
device or its children, ignoring the of_node specified in the
regulator_config structure.
This behavior causes issues in scenarios where multiple regulator devices
are registered for components described as children of a controller, each
with their own specific regulator supply.
For instance, in a PSE controller with multiple PIs (Power Interfaces),
each PI may have a distinct regulator supply. However, the regulator core
would incorrectly use the PSE controller node or its first child to look up
the regulator supply, rather than the node specified by the
regulator_config->of_node for the PI.
This update modifies the behavior to prioritize the of_node in
regulator_config for resolving the supply. This ensures correct resolution
of the power supply for each device. If no supply is found in the provided
of_node, the core falls back to searching within the parent device as
before.
Reviewed-by: Oleksij Rempel <o.rempel@pengutronix.de>
Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
Link: https://patch.msgid.link/20250109-b4-feature_poe_arrange-v2-13-55ded947b510@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
of_regulator_match() does not release the OF node reference in the error
path, resulting in an OF node leak. Therefore, call of_node_put() on the
obtained nodes before returning the EINVAL error.
Since it is possible that some drivers call this function and do not
exit on failure, such as s2mps11_pmic_driver, clear the init_data and
of_node in the error path.
This was reported by an experimental verification tool that I am
developing. As I do not have access to actual devices nor the QEMU board
configuration to test drivers that call this function, no runtime test
was able to be performed.
Fixes: 1c8fa58f47 ("regulator: Add generic DT parsing for regulators")
Signed-off-by: Joe Hattori <joe@pf.is.s.u-tokyo.ac.jp>
Link: https://patch.msgid.link/20250104080453.2153592-1-joe@pf.is.s.u-tokyo.ac.jp
Signed-off-by: Mark Brown <broonie@kernel.org>
This helper function is primarily used by developers for debugging & is
not a standard feature included in other PMIC drivers. The purpose of
debugging function is to check if rdev is determine if the regulator has
been registered prior to requesting a threaded irq. This case is already
handled with the ISERR(rdev) check because the error code is returned.
Signed-off-by: Shree Ramamoorthy <s-ramamoorthy@ti.com>
Link: https://patch.msgid.link/20241217204526.1010989-5-s-ramamoorthy@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Set 'enable_value' in the regulator descriptor for different bucks to
manage their enable modes:
- 00b: OFF
- 01b: ON when PMIC_ON_REQ = H
- 10b: ON when PMIC_ON_REQ = H && PMIC_STBY_REQ = L
- 11b: Always ON
Ensure appropriate behavior based on the intended design. For example:
- Buck2, designed for vddarm, should be set to '10b' (ON when
PMIC_STBY_REQ = L) since it can be off when `PMIC_STBY_REQ = H` after the
kernel enters suspend.
- Other bucks remain '01b' (ON when PMIC_ON_REQ = H), matching the default
setting. This avoids the need to re-enable them during kernel boot as they
are already enabled after PMIC initialization.
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20241205-pca9450-v1-1-aab448b74e78@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
AXP717 datasheet says that regulator ramp delay is 15.625 us/step,
which is 10mV in our case.
Add a AXP_DESC_RANGES_DELAY macro and update AXP_DESC_RANGES macro to
expand to AXP_DESC_RANGES_DELAY with ramp_delay = 0
For DCDC4, steps is 100mv
Add a AXP_DESC_DELAY macro and update AXP_DESC macro to
expand to AXP_DESC_DELAY with ramp_delay = 0
This patch fix crashes when using CPU DVFS.
Signed-off-by: Philippe Simons <simons.philippe@gmail.com>
Tested-by: Hironori KIKUCHI <kikuchan98@gmail.com>
Tested-by: Chris Morgan <macromorgan@hotmail.com>
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
Fixes: d2ac3df75c ("regulator: axp20x: add support for the AXP717")
Link: https://patch.msgid.link/20241208124308.5630-1-simons.philippe@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The ROHM BD96801 "scalable PMIC" provides two physical IRQs. The ERRB
handling can in many cases be omitted because it is used to inform fatal
IRQs, which usually kill the power from the SOC.
There may however be use-cases where the SOC has a 'back-up' emergency
power source which allows some very short time of operation to try to
gracefully shut down sensitive hardware. Furthermore, it is possible the
processor controlling the PMIC is not powered by the PMIC. In such cases
handling the ERRB IRQs may be beneficial.
Add support for ERRB IRQs.
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
Link: https://patch.msgid.link/ZzWkny4lKpY09SX5@mva-rohm
Signed-off-by: Mark Brown <broonie@kernel.org>
Pull regulator fixes from Mark Brown:
"A couple of fixes that came in during the merge window, plus
documetation of a new device ID for the Qualcomm LABIBB driver.
There's a core fix for the rarely used current constraints and a fix
for the Qualcomm RPMH driver which had described only one of the two
voltage ranges that the hardware could control, creating a potential
incompatibility with the configuration left by firmware"
* tag 'regulator-fix-v6.13-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: core: Ignore unset max_uA constraints in current limit check
dt-bindings: regulator: qcom-labibb-regulator: document the pmi8950 labibb regulator
regulator: qcom-rpmh: Update ranges for FTSMPS525
Pull MFD updates from Lee Jones:
- Several drivers, including atmel-flexcom/rk8xx-core, palmas, and
tps65010, have undergone minor code improvements to enhance
consistency and fix race conditions.
- The syscon driver now utilizes the regmap max_register_is_0
capability for consistent register map configuration across syscons
of all sizes.
- New device support has been added for QCS8300, qcs615, SA8255p, and
samsung,s2dos05, expanding the range of compatible hardware.
- The cros_ec driver now supports loading cros_ec_ucsi on supported ECs
and avoids loading the charger with UCSI, streamlining functionality.
- The bd96801 driver now utilizes the more modern maple tree register
cache, improving performance.
- The da9052-spi driver has undergone a fix to change the read-mask to
write-mask, preventing potential issues.
- Unused declarations in max77693 have been removed, and support for
samsung,s2dos05 has been added, enhancing code clarity and device
compatibility.
- Error handling in cs42l43 has been fixed to avoid unbalanced
regulator put and ensure proper synchronization during driver
removal.
- The wcd934x driver now uses MODULE_DEVICE_TABLE() instead of
MODULE_ALIAS(), improving code consistency.
- Documentation for qcom,tcsr, syscon, and atmel-smc has been updated
and reorganized for better clarity and maintainability.
- The intel_soc_pmic_bxtwc driver has undergone significant
improvements, including the use of IRQ domains for various devices,
fixing IRQ domain names duplication, and code refactoring for better
consistency and maintainability.
- The ipaq-micro driver has received a fix for a missing break
statement in the default case, enhancing code robustness.
- Support for the AXP323 PMIC has been added to the axp20x driver,
along with ensuring a clear relationship between IDs and model names,
and allowing multiple regulators, broadening hardware compatibility.
- The cs42l43 driver now disables IRQs during suspend for improved
power management.
- The adp5585 driver has reduced its dependencies by dropping the
obsolete dependency on COMPILE_TEST.
- Initial support for the MT6328 PMIC has been added to the mt6397
driver, expanding the range of supported hardware.
- The rtc-bd70528 driver has been simplified by dropping the IC name
from IRQ, improving code readability.
- Documentation for qcom,spmi-pmic, ti,twl, and zii,rave-sp has been
updated to enhance clarity and incorporate new features.
- The rt5033 driver has received a fix for a missing
regmap_del_irq_chip() in the error handling path.
- New device support has been added for MSM8917, and the
intel_soc_pmic_crc driver now supports non-ACPI instantiated
i2c_client.
- The 88pm886 driver has added support for the RTC cell, and the tqmx86
driver has improved its GPIO IRQ setup and added I2C IRQ support,
increasing functionality.
- The sprd,sc2731 DT schema has been updated and converted to YAML
format for better readability and maintainability.
* tag 'mfd-next-6.13' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd: (62 commits)
dt-bindings: mfd: bd71828: Use charger resistor in mOhm instead of MOhm
dt-bindings: mfd: sprd,sc2731: Convert to YAML
mfd: tqmx86: Add I2C IRQ support
mfd: tqmx86: Make IRQ setup errors non-fatal
mfd: tqmx86: Refactor GPIO IRQ setup
mfd: tqmx86: Improve gpio_irq module parameter description
mfd: tqmx86: Add board definitions for TQMx120UC, TQMx130UC and TQMxE41S
mfd: 88pm886: Add the RTC cell
dt-bindings: mfd: Add Realtek RTL9300 switch peripherals
mfd: intel_soc_pmic_crc: Add support for non ACPI instantiated i2c_client
mfd: intel_soc_pmic_*: Consistently use filename as driver name
dt-bindings: mfd: qcom,tcsr: Add compatible for MSM8917
mfd: rt5033: Fix missing regmap_del_irq_chip()
mfd: cgbc-core: Fix error handling paths in cgbc_init_device()
dt-bindings: mfd: aspeed: Support for AST2700
mfd: Switch back to struct platform_driver::remove()
dt-bindings: mfd: qcom,spmi-pmic: Document PMICs added in SM8750
mfd: rtc: bd7xxxx Drop IC name from IRQ
mfd: mt6397: Add initial support for MT6328
mfd: adp5585: Drop obsolete dependency on COMPILE_TEST
...
