| Age | Commit message (Collapse) | Author |
|---|
|
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator fix from Mark Brown:
"One fix here, we had an issue with deferred hardware disables where
if we were deferring while suspend was happening we would let the
workqueue run which could result in us trying to access hardware after
it or the buses used to access it were suspended.
We fix this by completing any work as we suspend the individual
regulators"
* tag 'regulator-fix-v7.4-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: irq: freeze deferred hardware access during suspend
|
|
The regulator IRQ helper delays status checks and recovery callbacks on
non-freezable workqueues. Those callbacks may access regulator hardware
after the backing bus has been suspended.
Use system_freezable_wq for normal-priority callbacks. Allocate a
freezable high-priority workqueue when requested so the high_prio
contract is preserved while hardware access is frozen across suspend.
Signed-off-by: Jiale Yao <yaojiale02@163.com>
Fixes: 7111c6d1b31b ("regulator: IRQ based event/error notification helpers")
Reviewed-by: Matti Vaittinen <mazziesaccount@gmail.com>
Link: https://patch.msgid.link/20261016100522.2582557-3-yaojiale02@163.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator updates from Mark Brown:
"This is quite a quiet release, especially given the general onslaught
of cleanup patches seen elsewhere. There is some of that, but not as
much as I'm seeing elsewhere relatively to the size of the subsystem.
We do have some new drivers as well, plus Linus Walleij has done a big
overhaul of the AB8500 driver including feature buildout.
- Substantial cleanups and feature additions for the ST Ericsson AB8500
- Overhaul of the configuration for the LP872x.
- A bunch of DT binding conversions
- Support for Maxim MAX20024, MPS MPQ4210, Nexperia NEX10000UB"
* tag 'regulator-v7.4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: (60 commits)
regulator: rpi-panel-attiny: Fix probe failure after a host cold boot
regulator: lp872x: Use macro to fill regulator descriptor
regulator: lp872x: Add support for input and regulator power supplies
regulator: lp872x: Remove platform_data based probing
regulator: lp872x: Remove redundant regmap wrappers
regulator: lp872x: Fold driver header into driver file
regulator: dt-bindings: ti,lp872x: Document input supplies
regulator: dt-bindings: ti,lp872x: Deprecate ti,dvs-gpio and ti,update-config
regulator: dt-bindings: sy8827n: support standard properties
regulator: dt-bindings: Reference Tegra regulator coupling schema
regulator: dt-bindings: nvidia,tegra-regulators-coupling: Convert to DT schema
regulator: dt-bindings: ti,lp872x: Convert to DT schema
regulator: dt-bindings: Drop obsolete MAX8925 .txt binding
regulator: 88pm886: Add Vbus regulator
regulator: core: Export helpers used by regulator couplers
regulator: core: Fix coupled regulators reference leak on removal
regulator: dt-bindings: ti,tps6586x: Convert to DT schema
regulator: dt-bindings: Add MAX20024 sd4
regulator: dt-bindings: Convert mediatek,mt6380-regulator to DT schema
regulator: mp886x: fix pontential division by zero
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux
Pull gpio updates from Bartosz Golaszewski:
"Nothing stands out as particularly interesting, it's been a calm
cycle. We have three new drivers, support for more models and lots of
updates across many modules (details are in the signed tag as usual).
There are also some minor changes and additions to the in-kernel GPIO
API.
GPIO core:
- provide a new controller API: gpiochip_generic_get_config()
- return -EOPNOTSUPP instead of -ENODEV to user-space if it requests
hardware timestamping on systems where it's unavailable (no
user-space regressions reported)
New drivers:
- add a driver for ROHM BD73800 PMIC GPIO controller
- add a driver for Axiado AX3005 SGPIO controller
- add a driver for Analog Devices AD7768 GPIO controller
New hardware support:
- extend gpio-rcar with support for R-Car X5H (R8A78000)
- extend gpio-tegra186 with support for Tegra 268
Driver changes:
- refactor and improve gpio-rtd1625: switch to modern or better
fitting interfaces and improve coding style
- improve error handling of return values of
platform_get_irq_optional() in several drivers
- normalize the return value of the gpio_chip::get() callback in
gpio-siox in order to not propagate invalid values up to the GPIO
core
- implement gpio_chip::get_direction() for gpio-pcf857x
- use managed variants of notifier registration functions in several
drivers
- remove legacy gpio_set_value_cansleep() as it has no more users
- add pinctrl support to gpio-realtek-otto
- add runtime PM support to the gpio-regmap helper module
- add more ACPI GPIO quirks for various hardware
- stop needlessly reading gpio_chip::base in gpio-pxa
- add support for tracking of direction of generic GPIO chips with no
direction registers via pinctrl backend to gpio-mmio (use the new
core API: gpiochip_generic_get_config())
- use the "safe" variants of debugfs_create_file() in
gpio-sloppy-analyzer
- use device name as GPIO chip label in gpio-omap
- refactor bit ops in gpio-dln2
- prepare gpio-it87 for upcoming kmalloc_obj() conversion
Devicetree bindings:
- document new model in gpio-pca95xx
- allow the gpio-hogs property in gpio-zynq and fsl,qoriq-gpio
- allow the gpio-ranges property in gpio-realtek-otto
Misc fixes:
- add missing MODULE_ALIAS() to gpio-crystalcove
- fix a comment typo in example GPIO tools
- fix unbalanced brackets in documentation
- add names to regmaps in gpio-mvebu to avoid collisions in debugfs
output
- fix GPIO lookup using relative paths in GPIO ACPI"
* tag 'gpio-updates-for-v7.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: (63 commits)
gpiolib: acpi: Fix GPIO lookup using relative path
gpio: legacy: Kill gpio_set_value_cansleep()
dt-bindings: gpio: pca95xx: add onnn,pca9655 with nxp,pca9555 fallback
gpiolib: acpi: Ignore GPIO 11 interrupt on Acer Nitro V 16S AI
gpio: pxa: stop reading gpio_chip::base in direction callbacks
gpio: axiado: add AX3005 SGPIO controller support
dt-bindings: gpio: add Axiado AX3005 SGPIO controller
gpiolib: acpi: Add quirk for Lenovo IdeaPad Slim 3 15ABR8
MAINTAINERS: Add ROHM BD73800 PMIC files
gpio: bd73800: Support ROHM BD73800 PMIC GPIOs
clk: bd718x7: Support ROHM BD73800
regulator: bd71828: Support ROHM BD73800
rtc: bd70528: Support RTC on ROHM BD73800
mfd: Support for ROHM BD73800 PMIC core
dt-bindings: mfd: ROHM BD73800 PMIC
dt-bindings: regulator: ROHM BD73800 regulators
dt-bindings: rohm,bd*: Ref common ROHM bindings
dt-bindings: mfd: Common ROHM PMIC properties
gpio: siox: normalize return value of gpio_get()
gpio: dln2: use assign_bit() where applicable
...
|
|
attiny_i2c_probe() reads REG_ID with attiny_i2c_read(), a function added
in commit e4a7e3f741f7 ("regulator/rpi-panel-attiny: Use two
transactions for I2C read") specifically for fixing REG_ID read failures
at probe.
On TI's BeagleY-AI (but also on other TI boards tested) with the
Raspberry Pi 7-inch touchscreen, the first I2C transfer to the attiny
after a cold boot of the board usually fails, so the probe fails.
Retrying the transfer once fixes the problem.
It is unclear why this happens, but as the earlier commit adding
attiny_i2c_read() shows, attiny seems to have i2c issues. It is not out
of the question that the issue could be on the TI i2c side, but as the
other i2c peripherals (like sensors) work fine, adding this workaround
to attiny driver feels sensible.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Link: https://patch.msgid.link/20261016-attiny-probe-fix-v1-1-96337ba58dfa@ideasonboard.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Switch to using the macro for filling the LP872x regulator descriptor
to improve readability.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Link: https://patch.msgid.link/20261013181417.492252-8-clamor95@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The LP872x support dedicated main power supply input usually shared with
parent power supply for one of internal regulators (ldo1).
Add support for retrieving and managing these supply regulators using the
regulator framework to ensure proper power supply dependencies and
power-up sequencing.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Link: https://patch.msgid.link/20261013181417.492252-7-clamor95@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The platform_data-based probing is tightly integrated into the lp872x
driver structure itself; removing just the platform data support is
impossible without remodeling major parts of the probe sequence.
The lp872x_platform_data structure was removed, and its contents were
incorporated into the driver private structure and lp872x_chip_info (which
holds differences between the LP8720 and LP8725). The
lp872x_populate_pdata_from_dt() helper was removed: general Device Tree
parsing code was integrated directly into the probe function, and
DVS-related code was consolidated into lp872x_init_dvs().
lp872x_hw_enable() and lp872x_config() helpers were folded into probe().
i2c_client_get_device_id() was switched to i2c_get_match_data(). Finally,
of_regulator_match structures were dropped, and
lp872x_regulator_register() was upgraded to rely on the core regulator
registration framework.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Link: https://patch.msgid.link/20261013181417.492252-6-clamor95@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Remove lp872x_read_byte(), lp872x_write_byte(), and lp872x_update_bits()
helpers which are just wrappers around the same regmap helpers.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Link: https://patch.msgid.link/20261013181417.492252-5-clamor95@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Remove need in header file in preparation for pdata probing removal.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Link: https://patch.msgid.link/20261013181417.492252-4-clamor95@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
HRST (0x1e) and CLIRQ (0x1f) are write-only command strobes. Writing HRST
triggers a hard reset of the chip and writing CLIRQ clears the interrupt;
reading them returns nothing useful, and the read itself fires the command.
The result is that a plain register dump resets the board:
cat /sys/kernel/debug/regmap/2-003c/registers
walks every readable register, hits HRST, and the board reboots.
Split the callback back in two so HRST and CLIRQ stay writable but are no
longer readable. The readable range is left unchanged
(LTC3676_BUCK1 ... LTC3676_IRQSTAT).
Fixes: 37b918a034fe ("regulator: Add LTC3676 support")
Cc: stable@vger.kernel.org
Signed-off-by: Abhishek Ojha <Abhishek.ojha@savoirfairelinux.com>
Link: https://patch.msgid.link/20260902010701.3360310-1-Abhishek.ojha@savoirfairelinux.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Alexey Charkov <alchark@flipper.net> says:
of_regulator_bulk_get_all() only fills in the .consumer part of the
struct regulator_bulk_data for the regulators it gets, leaving .supply as
garbage, while the rest of the regulator core expects a meaningful name
there (e.g. for error prints), causing uninitialized memory access in any
failure paths in the core.
It also allocates the supplies array and hands it to callers, but never
says the callers need to free it (which they don't currently), causing
leaks.
Fix the former and document the latter in the kerneldoc to help any new
users avoid the leak.
Link: https://patch.msgid.link/20260930-regulator-get-all-v2-0-ca82070d22f2@flipper.net
|
|
of_regulator_bulk_get_all() allocates the consumer array and hands it to
the caller, but never said so. Its own error path frees the array, while
regulator_bulk_free() only puts the regulators, so both callers release
the regulators and leak the array.
Spell the contract out in the kerneldoc.
Signed-off-by: Alexey Charkov <alchark@flipper.net>
Link: https://patch.msgid.link/20260930-regulator-get-all-v2-2-ca82070d22f2@flipper.net
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
of_regulator_bulk_get_all() returns an array it allocated itself, and
fills in only the consumer of each entry. Every other way of getting a
bulk array has the supply name set, because the caller provides it, and
the core expects it to be there: regulator_bulk_enable() prints it when
a supply fails to enable, so a caller that hands such an array to it
dereferences uninitialised memory on that path.
Copy each name into the array's own allocation, right behind the
entries, so that it shares the array's lifetime and callers still have
nothing extra to free. That also retires the fixed 64 byte stack buffer
the names were assembled in, which is_supply_name() never bounded the
copy against.
Cc: stable@vger.kernel.org
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/patchset/20260928-b4-rk3576-reboot-mode-v1-0-65486b03bd41@flipper.net?part=3
Fixes: 27b9ecc7a9ba ("regulator: Add of_regulator_bulk_get_all")
Signed-off-by: Alexey Charkov <alchark@flipper.net>
Link: https://patch.msgid.link/20260930-regulator-get-all-v2-1-ca82070d22f2@flipper.net
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
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>
|
