| Age | Commit message (Collapse) | Author |
|---|
|
# Conflicts:
# drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
# net/ceph/osd_client.c
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git
|
|
|
|
The TPS65224 BUCK2, BUCK3 and BUCK4 descriptors pass 4 as
n_linear_ranges, but tps65224_bucks_2_3_4_ranges[] only has two
entries, covering selectors 0x00-0x45.
The linear range helpers loop over n_linear_ranges entries, so any
lookup of a selector above 0x45 reads past the end of the array and
treats whatever follows it as two more ranges. This happens on the
normal registration path when the core checks the voltage constraints
against every selector. TPS652G1 uses the same descriptors and is
affected too.
Use ARRAY_SIZE() so the count always matches the table.
Fixes: 00c826525fba ("regulator: tps6594-regulator: Add TI TPS65224 PMIC regulators")
Cc: stable@vger.kernel.org
Signed-off-by: Ridham Khurana <khurana.ridham222@gmail.com>
Link: https://patch.msgid.link/20260930105333.3522412-1-khurana.ridham222@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Add support for the PMIC's Vbus regulator. This regulator is mandatory
for USB OTG support on boards using the PMIC.
Reviewed-by: Karel Balej <balejk@matfyz.cz>
Signed-off-by: Duje Mihanović <duje@dujemihanovic.xyz>
Link: https://patch.msgid.link/20260613-88pm886-vbus-v2-3-021dfb02c6bb@dujemihanovic.xyz
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Justin Yeh <justin.yeh@mediatek.com> says:
MTK_REGULATOR_COUPLER can currently only be built into the kernel: it is
a bool, and its prompt is hidden unless COMPILE_TEST is set, so on real
MediaTek configurations the symbol has no prompt and is forced to its
"default ARCH_MEDIATEK" value.
Kernels that ship nearly everything as a module (Android GKI style
kernels, but distro kernels have the same shape) cannot use it that way.
Two things are in the way:
- the four helpers the coupler calls are declared in
include/linux/regulator/coupler.h for coupler implementations to
use, but none of them is exported (patch 1);
- the Kconfig symbol is a bool without a usable prompt (patch 2).
Link: https://patch.msgid.link/20260903062056.1024263-1-justin.yeh@mediatek.com
|
|
regulator_check_voltage(), regulator_check_consumers(),
regulator_do_balance_voltage() and regulator_coupler_register() are
already declared in include/linux/regulator/coupler.h for regulator
coupler implementations to use, but none of them is exported. That
limits couplers to being built into the kernel.
Export them so that coupler drivers can be built as loadable modules.
Signed-off-by: Justin Yeh <justin.yeh@mediatek.com>
Link: https://patch.msgid.link/20260903062056.1024263-2-justin.yeh@mediatek.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
of_parse_coupled_regulator() returns the coupled regulator with its
device reference incremented and regulator_resolve_coupling() stores it
in coupling_desc.coupled_rdevs[]. regulator_remove_coupling() clears
those pointers without dropping the references, so they are leaked when
the couple is torn down.
Release the reference of each coupled regulator while removing the
coupling.
Fixes: d3d64537c339 ("regulator: core: Resolve coupled regulators")
Cc: stable@vger.kernel.org
Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
Link: https://patch.msgid.link/20260917143052.2156903-1-vulab@iscas.ac.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The ROHM BD73800 is a power management IC which integrates 8 BUCKs and 4
LDOs. The PMIC has internal state-machine and it can support transitions
to RUN, SUSPEND and IDLE states. The LDOs 1 and 3 have two different
voltage range configurations that can be set at the manufacturing phase
by OTP. By default driver assumes low voltage ranges to be used because
the data-sheet indicates the higher voltage ranges to be an 'OTP option'.
The high voltage range can be indicated via device-tree property.
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Acked-by: Mark Brown <broonie@kernel.org>
Link: https://patch.msgid.link/94a1cef828fb5f6ea1703167c819f321ee3bde77.1789538455.git.mazziesaccount@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
Jisheng Zhang <jszhang@kernel.org> says:
Fix two issues reported by sashiko.
https://sashiko.dev/#/patchset/20260901043123.5401-1-jszhang@kernel.org?part=1
Link: https://patch.msgid.link/20260909143957.9284-1-jszhang@kernel.org
|
|
If the "mps,fb-voltage-divider" 2nd var is 0, there will be division
by zero bug.
Fixes: 97be82880b61 ("regulator: add support for MP8869 regulator")
Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Closes: https://sashiko.dev/#/patchset/20260901043123.5401-1-jszhang@kernel.org?part=1
Link: https://patch.msgid.link/20260909143957.9284-3-jszhang@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The get_voltage_sel() can fail, resulting in negative error codes
stored in unsigned integers and corrupted state logic.
Fixes: 97be82880b61 ("regulator: add support for MP8869 regulator")
Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Closes: https://sashiko.dev/#/patchset/20260901043123.5401-1-jszhang@kernel.org?part=1
Link: https://patch.msgid.link/20260909143957.9284-2-jszhang@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
power supply
Neil Armstrong <neil.armstrong@linaro.org> says:
Document and add regulator support for the Nexperia NEX10000UB dual
output LCD bias power supply which provides programmable positive
and negative output voltages mainly for display panels applications.
The driver supports setting the output voltage from 4V to 6V in
100mV steps for each output via the I2C programming interface and
supports the enable GPIOs for both outputs.
Product datashet can be found online at [1].
[1] https://assets.nexperia.com/documents/data-sheet/NEX10000UB.pdf
Link: https://patch.msgid.link/20260921-topic-sm8x50-nex10000ub-v2-0-eeeaf9b0c913@linaro.org
|
|
Add regulator support for the Nexperia NEX10000UB dual output LCD
bias power supply which provides programmable positive and negative
output voltages mainly for display panels applications.
The driver supports setting the output voltage from 4V to 6V in
100mV steps for each output via the I2C programming interface and
supports the enable GPIOs for both outputs.
Product datashet can be found online at [1].
[1] https://assets.nexperia.com/documents/data-sheet/NEX10000UB.pdf
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260921-topic-sm8x50-nex10000ub-v2-3-eeeaf9b0c913@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
In rt6190_out_enable(), pm_runtime_get_sync() is called at the start of
the function. However, if any subsequent regmap or regulator operation
fails, the function returns directly without dropping the runtime PM
reference, causing a runtime PM reference leak.
Add an error handling path with pm_runtime_put() to keep the reference
count balanced on failure.
Fixes: e6999e7cca7e ("regulator: rt6190: Add support for Richtek RT6190 regulator")
Cc: stable@vger.kernel.org
Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
Reviewed-by: ChiYuan Huang <cy_huang@richtek.com>
Link: https://patch.msgid.link/20260916072541.1968033-1-vulab@iscas.ac.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
In preparation for making the devm_kmalloc family of allocators type
aware, we need to make sure that the returned type from the allocation
matches the type of the variable being assigned. (Before, the allocator
would always return "void *", which can be implicitly cast to any
pointer type.)
The assigned type is "struct regulator_desc *", but the converted
allocation types would be "const struct regulator_desc *", as all three
sizeof()s were taken from "*desc", and "desc" is
"const struct regulator_desc *". As there is no general way to remove
const qualifiers, take the size from the assignment target instead. No
change in allocation size results.
Build tested ARCH=x86_64 allmodconfig with GCC 16.2.0:
drivers/regulator/axp20x-regulator.o
Assisted-by: LLM coccinelle
Signed-off-by: Kees Cook <kees+treewide@kernel.org>
Link: https://patch.msgid.link/20260917211315.i.973-kees@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
regulator_resolve_supply() takes a reference on the looked-up regulator
with regulator_dev_lookup(), but when the supply resolves to the
regulator itself that reference is never dropped: it leaks on the early
return and is lost as well when r is replaced with the dummy regulator.
Release the reference before handling the self-referent case.
Fixes: 4b639e254d3d ("regulator: avoid resolve_supply() infinite recursion")
Cc: stable@vger.kernel.org
Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
Link: https://patch.msgid.link/20260917142810.2156816-1-vulab@iscas.ac.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
of_parse_coupled_regulator() returns the coupled regulator with its
device reference incremented, but regulator_resolve_coupling() returns
without dropping it when the coupled regulator belongs to a different
coupler, leaking the reference.
Fixes: d8ca7d184b33 ("regulator: core: Introduce API for regulators coupling customization")
Cc: stable@vger.kernel.org
Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
Link: https://patch.msgid.link/20260917142535.2156720-1-vulab@iscas.ac.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Tapio Reijonen <tapio.reijonen@vaisala.com> says:
The MPQ4210 series was applied to for-7.4 as e3c05a881fc9 and 61879d561e91,
and two review comments arrived afterwards. Both are addressed here as
incremental patches against current for-7.4.
Patches 1 and 2 rename mps,fb-voltage-divider to mps,fb-voltage-divider-ohms,
as Krzysztof asked. The split across the binding and the driver leaves one
commit where the two disagree, so they are meant to be applied together. The
suffix is worth more here than the convention alone: mps,mp886x.yaml already
describes a property of the same name whose values are kilo ohms rather than
ohms, so two bindings from the same vendor spelled the resistances
identically while meaning different units. Nothing in tree uses the old name
and it has not appeared in a release, so no fallback is kept.
Patch 3 drops the <linux/mod_devicetable.h> include, as Uwe asked.
Tested on an i.MX6SX board whose MPQ4210 sits behind a gpio i2c mux, with the
device tree updated to the new property name. The regulator registers and the
divider is parsed correctly: the board sets regulator-ramp-delay above every
supported rate, and the core reports "Can't set ramp-delay 3000, setting 2101",
where 2101 uV/us is the fastest reference rate scaled by this board's divider.
That value can only be reached by reading both resistors from the renamed
property.
Link: https://patch.msgid.link/20260913-mpq4210-ohms-fixup-v1-0-dcff627001ff@vaisala.com
|
|
<linux/mod_devicetable.h> is meant to go away, and this driver does not
need it: <linux/i2c.h> already supplies struct i2c_device_id and
<linux/of.h> struct of_device_id, and both are included already.
Suggested-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Link: https://lore.kernel.org/r/aqRMb8q7BT3uZ9iF@monoceros
Signed-off-by: Tapio Reijonen <tapio.reijonen@vaisala.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Link: https://patch.msgid.link/20260913-mpq4210-ohms-fixup-v1-3-dcff627001ff@vaisala.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Follow the binding rename of mps,fb-voltage-divider to
mps,fb-voltage-divider-ohms.
The old name was never in a release and this driver is its only reader,
so it is dropped rather than kept as a fallback.
Fixes: 61879d561e91 ("regulator: Add MPS MPQ4210 buck-boost regulator driver")
Suggested-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20260911-gaur-of-satisfying-action-1a3b0f@quoll
Signed-off-by: Tapio Reijonen <tapio.reijonen@vaisala.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260913-mpq4210-ohms-fixup-v1-2-dcff627001ff@vaisala.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
rpmh_regulator_vrm_get_optimum_mode() kernel-doc
rpmh_regulator_vrm_get_optimum_mode() returns REGULATOR_MODE_NORMAL or
REGULATOR_MODE_IDLE and cannot fail, but its kernel-doc says "0 on
success, or a negative error number on failure", which was never true.
Describe the mode.
Fixes: efb0cb50c427 ("regulator: qcom-rpmh: Implement get_optimum_mode(), not set_load()")
Assisted-by: LLM
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Link: https://patch.msgid.link/20260912000606.34614-1-kmehltretter@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Linus Walleij <linusw@kernel.org> says:
While working on the Ux500 power domains it became apparent that the
device trees were using the DB8500 power-domain regulator for supplies
which actually come from buck converters in the AB8500 PMIC.
First: fix a bunch of bugs. All of these patches have Fixes: tags.
I do not consider any of them urgent or regressions, they can just
be queued in front of the new functionality.
Move some regulators over to using linear ranges before adding new
stuff since linear ranges are nice.
Add bindings and regulator driver support for the six SMPS1, SMPS2,
SMPS3, ARM, APE and MOD buck converters. Instantiate the regulators for
both AB8500 and AB8505, where the corresponding rails are named VSMPSA,
VSMPSB, VSAFE, VARM, VSMPSC and VSMPSM, and connect existing consumers
to the correct SMPS2/VSMPSB supply.
The driver follows the active hardware selector, including the
additional AB8505 selector banks, and uses the variant-specific VARM
voltage encoding. It provides enable and low-power mode control for the
three peripheral bucks while leaving the SoC-controlled rails
voltage-only.
Since peripheral buck enable state is programmed by OTP and can power
discrete components outside the device tree, preserve any rail which
the OTP leaves enabled when regulator constraints are completed.
Link: https://patch.msgid.link/20260901-ux500-dts-snowball-regulator-v2-0-fe88b01829bf@kernel.org
|
|
Use a scoped mutex guard in ab8500_regulator_set_mode().
Assisted-by: LLM
Signed-off-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20260901-ux500-dts-snowball-regulator-v2-11-fe88b01829bf@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The SMPS enable fields are initialized from OTP and may leave a rail
enabled for discrete consumers which cannot be described in the device
tree. Such a rail currently looks unused to the regulator core and is
disabled when constraints are completed.
Read the enable field while registering each switchable buck
regulator. If it is nonzero, mark the regulator boot-on and always-on
dynamically so the unused-regulator sweep leaves it alone. Keep the
enable operation idempotent so applying the always-on constraint
preserves an OTP-selected hardware-control or low-power mode instead of
forcing high-power mode. Synchronize the cached mode with the preserved
field so an OTP-selected low-power state is also reported correctly.
Regulators which are disabled by OTP retain normal switchable
behavior.
Assisted-by: LLM
Signed-off-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20260901-ux500-dts-snowball-regulator-v2-10-fe88b01829bf@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Register the SMPS1, SMPS2, SMPS3, ARM, APE and MOD buck converters on
AB8500 and the VSMPSA, VSMPSB, VSAFE, VARM, VSMPSC and VSMPSM buck
converters on AB8505 so that the new device tree nodes can supply
consumers. Match each variant through its own device tree node names.
AB8500 SMPS3 supplies Vsafe and AB8505 VSAFE occupies the corresponding
control and selector registers at 0x0405 and 0x041b through 0x041d.
AB8500 VAPE and AB8505 VSMPSC instead use 0x0402 and the 0x040e through
0x0410 selector registers. Keep separate AB8505 regulator descriptors
and identifiers so these variant-specific rails are not conflated.
Describe the hardware selector ranges and follow the selector-control
registers when reading or changing voltage. This accounts for AB8505
using Sel2 after reset, its additional selector registers and its
separate 7-bit VARM range. Use the AB8500-compatible and low-range OTP
profiles found on the supported platforms for the other rails.
SMPS1 through SMPS3 and VSMPSA, VSMPSB and VSAFE also expose enable and
low-power mode control. Keep the ARM, APE, MOD, VARM, VSMPSC and VSMPSM
rails voltage-only since their on/off state is managed with the SoC.
Assisted-by: LLM
Signed-off-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20260901-ux500-dts-snowball-regulator-v2-9-fe88b01829bf@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
VINTCORE uses consecutive selectors with uniform 25 mV steps, with
AB8505 duplicating the highest voltage at selector 7. AB8505 VAUDIO
likewise has uniform 100 mV steps followed by a duplicate selector for
its highest voltage.
Describe these selector encodings with linear ranges and the matching
regulator helpers instead of enumerated voltage tables. Keep tables for
the irregular and non-monotonic VAUX and VANA selectors.
Assisted-by: LLM
Signed-off-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20260901-ux500-dts-snowball-regulator-v2-7-fe88b01829bf@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
For regulators whose enable and mode share a state field, set_mode()
first reads that field so changing the requested mode does not enable a
disabled rail. A register read error is currently treated as true and
the driver proceeds to write the new mode, potentially enabling a rail
whose state is unknown.
Return the read error without changing the register or cached mode.
References: AB8500 User Manual, UM0836 Rev 3, p. 227;
AB8505 User Manual, DM00046744 Rev 3, p. 237
Fixes: 438e695b87e0 ("regulator: ab8500: Get rid of is_enabled from struct ab8500_regulator_info")
Assisted-by: LLM
Signed-off-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20260901-ux500-dts-snowball-regulator-v2-6-fe88b01829bf@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Some regulator control registers have independent enable and low-power
bits. is_enabled() currently tests their combined update mask, so an
off regulator with its low-power bit set is incorrectly reported as
enabled.
Add an optional enable mask and use it for VINTCORE, AB8500 TVOUT,
AB8505 ADC, and AB8505 VAUX5/6. Regulators whose two-bit field encodes
the complete operating state continue to test the full update mask.
References: AB8500 User Manual, UM0836 Rev 3, p. 214;
AB8505 User Manual, DM00046744 Rev 3, pp. 171-172 and 223
Fixes: 65e03ed2d0cd ("regulators: Fixed errors in ab8500 register mapping")
Assisted-by: LLM
Signed-off-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20260901-ux500-dts-snowball-regulator-v2-5-fe88b01829bf@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The early-cut workaround currently gives AB8500 cut 1.0 the 16
programmable VAUX3 settings introduced with cut 1.1. On cut 1.0 the
selector is not programmable and VAUX3 is fixed at 1.2 V.
Register VAUX3 as a fixed-voltage regulator on cut 1.0 and retain the
16-value workaround only for cut 1.1.
Reference: AB8500 User Manual, UM0836 Rev 3, p. 240
Fixes: 2b75151a1041 ("regulators: Added ab8500 v2 support")
Assisted-by: LLM
Signed-off-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20260901-ux500-dts-snowball-regulator-v2-4-fe88b01829bf@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The AB8505 VINTCORE table exposes only selectors 0 through 6. The
hardware also accepts selector 7 and maps it to 1.35 V, just like
selector 6. Omitting it can make an OTP-programmed selector 7 appear
invalid to the regulator core.
Give AB8505 its own eight-entry selector table while leaving the
AB8500 table unchanged.
Reference: AB8505 User Manual, DM00046744 Rev 3, p. 223
Fixes: 547f384f33db ("regulator: ab8500: add support for ab8505")
Assisted-by: LLM
Signed-off-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20260901-ux500-dts-snowball-regulator-v2-3-fe88b01829bf@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
AB8505 has an additional VAUX3 voltage setting which is not encoded
in the normal three-bit selector. ArmRegu2.Vaux3Sel3 overrides that
selector and selects 3.05 V.
Add the missing voltage and use the override bit as an extended
selector. Program the ordinary selector before clearing the override
so VAUX3 does not briefly switch to a stale voltage.
Reference: AB8505 User Manual, DM00046744 Rev 3, pp. 229 and 254
Fixes: 547f384f33db ("regulator: ab8500: add support for ab8505")
Assisted-by: LLM
Signed-off-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20260901-ux500-dts-snowball-regulator-v2-2-fe88b01829bf@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The AB8505 VANA voltage table assumes selector 0 represents 1.05 V
and all eight selectors increase linearly. Selector 0 actually
represents 1.2 V. Selectors 1 through 6 cover 1.05 V through
1.175 V, and selector 7 represents 1.225 V.
Correct the table so each selector reports and programs the documented
voltage.
Reference: AB8505 User Manual, DM00046744 Rev 3, p. 257
Fixes: 8a3b1b8703fe ("regulator: ab8500: Add voltage selection for AUDIO and ANA on AB8505")
Assisted-by: LLM
Signed-off-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20260901-ux500-dts-snowball-regulator-v2-1-fe88b01829bf@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Tapio Reijonen <tapio.reijonen@vaisala.com> says:
This series adds support for the Monolithic Power Systems MPQ4210, a 40V
synchronous four-switch buck-boost controller with an I2C interface.
The output voltage is programmed through an 11-bit feedback reference DAC
with a 1mV step and is then scaled by an external feedback resistor
divider, so the divider ratio has to be described in the device tree. The
same ratio applies to the reference slew rate, so the four rates that the
Control 1 SR field selects are scaled into a per-device ramp_delay_table
and the field is exposed through regulator_set_ramp_delay_regmap(). The
current limit, switching frequency, dither and interrupt registers are
left at their reset values.
Only 0.3V to 2.047V of the DAC range is specified, so linear_min_sel
holds the driver to that and the lower selectors are not offered. On a
board with a gain of 14 that is the difference between a floor of 4.2V
and one of 0V, and the lower part of that range does not regulate.
Scaling the ramp table is a deliberate difference from ltc3589 and
mp886x, which read an equivalent feedback-divider property but keep their
ramp values unscaled. Every other constraint in the device tree is
expressed at the regulator output, so the selectable rates have to be as
well, or regulator-ramp-delay would select the wrong SR encoding. It does
mean the reachable rates are board specific and no value can be copied
between boards, so the binding documents how they are derived and shows
the calculation in its example.
Two details are worth a reviewer's attention.
Enable follows the start-up sequence the datasheet spells out: commit the
reference with the GO bit, wait 200ms, then set ENPWR. That is why
.enable is open coded rather than using regulator_enable_regmap.
Control 1 bit 2 is documented only as "Reserved", but the datasheet notes
that it must be set to one before the IC starts up. Its reset value is
zero, so probe sets it.
One consequence of the hardware worth spelling out: the MPQ4210 does not
respond on the I2C bus while EN is deasserted. The enable GPIO is
therefore claimed and asserted before the first register access and held
for the lifetime of the device, rather than being handed to the core as
regulator_config::ena_gpiod, which would drop the bus along with the
output.
Tested on an i.MX6SX board, regulator behind an I2C mux, feedback divider
100k/7.685k giving a gain of 14.0124, a 14012uV step and a 4.204V floor:
- A 16 point staircase from 4.204V to 25.2V: the commanded voltage, the
value read back and the selector decoded from the two reference
registers agree exactly at every point, and a meter on the rail
follows.
- With the rail up and no regulator-ramp-delay in the device tree,
Control 1 reads 0x45: SR at its reset value, bit 2 set, GO
self-cleared and ENPWR set. Interrupt status reads clear.
- regulator-ramp-delay picks the SR encoding as intended. 1050, an exact
entry of this board's scaled table, gives 0x85. 3000, above every
entry, warns "Can't set ramp-delay 3000, setting 2101" and gives 0xC5.
- Sampling Control 1 across a disable and re-enable shows 0x45, 0x44,
0x45, so ENPWR is cleared and restored as expected.
- Enable takes 230ms, against roughly 16ms for a plain register write on
this bus.
Link: https://patch.msgid.link/20260910-mpq4210-regulator-v1-0-d37e208dfc8d@vaisala.com
|
|
The MPQ4210 is a 40V synchronous four-switch buck-boost controller with
an I2C interface. Add a driver exposing voltage control and enable
control through the regulator interface.
The output voltage is programmed by an 11-bit feedback reference DAC with
a 1mV step, split across REF_LSB[2:0] and REF_MSB[7:0], and is then
scaled by the external feedback divider described in the device tree.
Only 0.3V to 2.047V of that range is specified, so linear_min_sel holds
the driver to it and the lower selectors are not offered. Scaled by the
divider, that floor is not zero: 4.2V on a board with a gain of 14, and
the core narrows regulator-min-microvolt to it.
The same divider ratio applies to the slew rate, so the four reference
slew rates that the Control 1 SR field selects are scaled into a
per-device ramp_delay_table and the field is exposed through
regulator_set_ramp_delay_regmap(). ramp_delay is initialised from the
rate SR is currently programmed for, so the core waits in proportion to
the size of each change; a board that sets regulator-ramp-delay
reprograms SR and the core uses that value instead.
Enabling follows the start-up sequence in the datasheet: commit the
reference with the GO bit, wait 200ms, then set ENPWR. Control 1 bit 2 is
documented as reserved but has to be set before the controller starts up,
so probe sets it. The controller does not respond on the bus while EN is
deasserted, so the enable GPIO is claimed before the first register
access.
Link: https://www.monolithicpower.com/en/mpq4210.html
Signed-off-by: Tapio Reijonen <tapio.reijonen@vaisala.com>
Link: https://patch.msgid.link/20260910-mpq4210-regulator-v1-2-d37e208dfc8d@vaisala.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The interrupt handler distinguishes the rail that reported the fault, but
the body ignores it. Every SW interrupt walks the regulator array looking
for the name "SW3" and every LDO interrupt looks for "LDO3", so an
over-current on SW1 is reported to the consumers of SW3 while the
consumers of SW1 hear nothing.
The lookup itself is unreliable as well. rdev_get_name() returns the
device tree regulator-name property whenever the board supplies one, and
only falls back to the name in the driver descriptor when it does not.
The binding example for this device sets regulator-name to "sw3" and
"ldo3", which strcmp() does not match against the upper case literals
used here, so a board that follows the documentation gets no over-current
notification at all. A board that names its rails after the schematic
does not match either. No other driver in the tree selects a notification
target this way.
Replace the name lookup with rdev_get_id(), which returns the descriptor
id set by the driver and cannot be overridden from the device tree, and
take both the id and the event from a table indexed by the interrupt.
The die temperature interrupts keep notifying every regulator since they
report a chip wide condition.
Fixes: 7320d41c29bb ("regulator: pf1550: Add support for regulator")
Signed-off-by: Donggeun Yoo <donggeunyoo.kernel@gmail.com>
Link: https://patch.msgid.link/20260904105624.48577-1-donggeunyoo.kernel@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Hemanth Selam <hemanth.selam@gmail.com> says:
This corrects 2 misspellings and repeated words in comments. Each is a
separate patch so that any one of them can be dropped without touching
the rest.
Nothing outside comments changes. Every touched C file was checked by
dropping its comments, replacing each string literal with a placeholder
and collapsing whitespace; what remained was identical before and after,
so the compiled code cannot differ.
The mistakes were found with scripts/checkpatch.pl against the list in
scripts/spelling.txt. The scanning, the edits and the changelogs were
produced with Cursor running the claude-opus-5 model, from a request to
find and fix spelling mistakes across the tree, and every correction was
then re-checked by the comparison described above. Words that name an
identifier were left alone deliberately, even when they read as typos,
because correcting the prose would make the comment disagree with the
code it describes.
Tested by building x86_64 defconfig at v7.3-rc1-269-gbc35965f6940, which
is clean. Nothing else was built, so any patch touching code that
x86_64 defconfig does not compile has been read but not compiled.
Link: https://patch.msgid.link/20260904110203.10113-1-hemanth.selam@gmail.com
|
|
Drop the word written twice, reported by checkpatch.pl as a possible
repeated word.
Only the message text changes, no code changes.
Assisted-by: Cursor:claude-opus-5
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Link: https://patch.msgid.link/20260904110203.10113-3-hemanth.selam@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Fix typos in comments, reported by scripts/checkpatch.pl using the
misspelling list in scripts/spelling.txt. Only touches comments, no code
changes.
Assisted-by: Cursor:claude-opus-5
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Link: https://patch.msgid.link/20260904110203.10113-2-hemanth.selam@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Luca Weiss <luca.weiss@fairphone.com> says:
During bringup no parent supply names were added to the RPMh regulator
driver. Add them now.
Link: https://patch.msgid.link/20260901-fp4-regulator-supply-v1-0-68288ab70aee@fairphone.com
|
|
Add the missing smps3-6 and ldo17 definitions. While smps3/5 and ldo17
are not used from the rpmh regulator driver on SM6350, the regulators do
exist, so add them with the types based on the datasheet.
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Link: https://patch.msgid.link/20260901-fp4-regulator-supply-v1-3-68288ab70aee@fairphone.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The supply names for the PM6350 regulators were skipped during initial
bringup. Add them.
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Link: https://patch.msgid.link/20260901-fp4-regulator-supply-v1-2-68288ab70aee@fairphone.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Jisheng Zhang <jszhang@kernel.org> says:
The MP8864 is a 4 A, 21 V synchronous step-down converter. Its
register layout and voltage transition handling are compatible with the
MP8867, but its selectable switching frequencies are 600 kHz, 850 kHz,
1.1 MHz and 1.6 MHz.
Add the compatible and chip-specific switching-frequency table.
Link: https://patch.msgid.link/20260901043123.5401-1-jszhang@kernel.org
|
|
The MP8864 is a 4 A, 21 V synchronous step-down converter. Its
register layout and voltage transition handling are compatible with the
MP8867, but its selectable switching frequencies are 600 kHz, 850 kHz,
1.1 MHz and 1.6 MHz.
Add the compatible and chip-specific switching-frequency table.
Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Assisted-by: Codex:gpt-5
Link: https://patch.msgid.link/20260901043123.5401-4-jszhang@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The MP886X vsel is 7bits, fix the vsel_mask.
Fixes: 97be82880b61 ("regulator: add support for MP8869 regulator")
Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Link: https://patch.msgid.link/20260901043123.5401-2-jszhang@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The devm_request_threaded_irq() function now automatically logs detailed
error messages on failure. This eliminates the need for driver-specific
dev_err_probe() calls that print generic messages.
Signed-off-by: Diederik de Haas <diederik@cknow-tech.com>
Link: https://patch.msgid.link/20260904144728.1629471-1-diederik@cknow-tech.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
set_machine_constraints() calls the set_ramp_delay() op when either
constraints->ramp_delay or constraints->ramp_disable is set. The
regulator binding documents regulator-ramp-delay = <0> as the way to
disable ramp control, and of_get_regulation_constraints() turns that
into ramp_disable = true while leaving ramp_delay at 0, so the op is
called with a ramp_delay of 0. The range check rejects negative values
and values above 6250 but not zero, and the value is then used as a
divisor.
The mapping is also wrong for the values that do pass the check. The
hardware offers two rates, 6250 uV/us and 3125 uV/us, selected by
SWx_DVSSPEED in SWx_CTRL1. Dividing 6250 by the requested rate and
taking bit 1 of the quotient does not map monotonically onto them: a
request for 1500 uV/us selects 6250 uV/us, while a request for the
faster 2000 uV/us selects 3125 uV/us.
Replace the division with a direct mapping onto the two supported
rates. Requests at or below 3125 uV/us get the slower rate and anything
above it gets the faster one. A ramp_delay of 0 asks for ramp control
to be disabled, which this hardware cannot do, so it gets the fastest
rate; pfuze100 handles the disabled case the same way.
Fixes: 7320d41c29bb ("regulator: pf1550: Add support for regulator")
Signed-off-by: Donggeun Yoo <donggeunyoo.kernel@gmail.com>
Link: https://patch.msgid.link/20260903082010.4024603-1-donggeunyoo.kernel@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The fixed regulator driver expects non-DT platform devices to provide
their configuration through platform_data as a struct fixed_voltage_config.
An explicitly bound driver can bypass the normal platform device/driver
matching and attach the fixed regulator driver to an unrelated platform
device. This causes the driver's platform_data to be interpreted as a
struct fixed_voltage_config even though it contains data for a different
device.
Reject non-DT platform devices whose name does not match the fixed
regulator driver before accessing their platform data.
Fixes: 4b74ff651249 ("regulator: add support for fixed regulators.")
Reported-by: syzbot+bfc9e55cf4f98183c636@syzkaller.appspotmail.com
Closes: https://syzbot.org/bug?extid=bfc9e55cf4f98183c636
Signed-off-by: Chandradhar Kumar <chandradhar.2003@gmail.com>
Link: https://patch.msgid.link/20260822065519.112441-1-chandradhar.2003@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The PCA9450 uses each regulator's ENMODE field to control whether the
regulator remains enabled when the PMIC transitions from RUN to STANDBY
mode.
The driver does not currently implement set_suspend_disable(), so a
regulator configured with regulator-off-in-suspend remains enabled
during system suspend.
Implement set_suspend_disable() for the buck regulators and LDO3-LDO5.
The suspend and runtime controls share ENMODE, so first read the field
and leave it unchanged when it is 00b. This preserves the state of a
regulator that was already disabled at runtime. For an enabled regulator,
program 10b to keep it on in RUN and turn it off while PMIC_STBY_REQ is
asserted.
Most buck descriptors set enable_val to 01b, while BUCK2 uses 10b. When
enable_val is nonzero, regulator_is_enabled_regmap() checks for an exact
match. It would therefore report most bucks as disabled after their ENMODE
is changed from 01b to 10b, even though all valid nonzero ENMODE values
enable the regulator in RUN. Use a custom is_enabled() helper for the buck
operation tables that considers a nonzero ENMODE enabled. The LDO
descriptors leave enable_val at zero, for which the generic helper already
performs this nonzero check, so keep using it for the LDOs.
Runtime enable and disable operations remain unchanged: disable writes
00b and enable writes the regulator's default mode. The suspend callback
reapplies 10b on each suspend after any intervening runtime operation.
Keep LDO1 and LDO2 on regulator operations without
set_suspend_disable(), because these regulators supply the SNVS domain
and must remain enabled in STANDBY mode.
Measured on a custom i.MX8MP board, turning off NVCC_SD2 (LDO5) during
system suspend reduced power consumption by approximately 64 mW.
Signed-off-by: Fabio Estevam <festevam@nabladev.com>
Link: https://patch.msgid.link/20260818014059.351152-2-festevam@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
