| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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>
|
|
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>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator fix from Mark Brown:
"One fix here, for a race condition on startup in the tps65185 driver
which is seen on actual boards - we need a delay after waking the chip
before it is ready to talk to the host"
* tag 'regulator-fix-v7.3-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: tps65185: wait for the IC to wake before the first I2C access
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd
Pull MFD updates from Lee Jones:
"New Support & Features:
- MediaTek MT6397: Add mt6323 AUXADC support
- MediaTek MT6397: Add mt6323 EFUSE support
- Spreadtrum SC27xx: Add SC2730 regulator cell
Improvements & Fixes:
- Apple SMC: Fix key count endianness annotation
- Azoteq IQS62x: Reject zero-length firmware records
- ChromeOS EC: Introduce cros_ec_read_features helper and read
features during probe to catch transfer errors
- Cirrus Logic CS42L43: Fix regmap defaults ordering
- Cirrus Logic CS42L43: Remove redundant NULL checks on SoundWire
- Congatec Board Controller: Fix teardown ordering in cgbc_remove()
- HP iPAQ Micro: Fix out-of-bounds stack read in ipaq_micro_str
- Marvell 88PM886: Initialize the battery page
- QNAP MCU: Keep the reply buffer alive past a command timeout
- RAVE SP: Validate received frame payload lengths
- Silicon Labs Si476x: Drop duplicate NULL checks
- Silicon Labs Si476x: Modernize GPIO handling
- Silicon Motion SM501: Fix potential memory leaks during remove
- UCB1x00: Convert Assabet gpio-keys to use software nodes and
register software node for GPIO controller
- Viperboard: Fix native fields type in structures as little-endian
- Viperboard: Remove redundant NULL check before kfree()
- X-Powers AXP20x: Preserve other control bits when powering off
Cleanups & Refactoring:
- Core: Drop unused assignment of spi_device_id driver data
- Core: Initialize spi_device_id arrays using member names
- Core: Unify style of spi_device_id arrays
- Maintainers: Add Intel LPSS section to follow the changes
- Maintainers: Add a mailing list entry to MFD
- Cirrus Logic CS42L43: Format sdw_device_id table
- Cirrus Logic CS42L43: Use new SoundWire enumeration helper
- ROHM PMIC: Factor out power button registration and convert
gpio-keys to use software nodes
- ST-Ericsson DB8500: Fold dbx500 header into db8500
Device Tree Binding Updates:
- Core: Add techvision vendor prefix
- Marvell 88PM886: Allow vbus regulator
- MediaTek MT8195 SCP: Add support for MT8189 SoC
- Qualcomm SPMI PMIC: Document PMG1110
- Qualcomm SPMI PMIC: Document haptics device
- Qualcomm TCSR: Add compatible for Hawi and Maili SoCs
- Qualcomm TCSR: Add compatible for Shikra
- Qualcomm TCSR: Document the IPQ9650 TCSR block
- STMicroelectronics STMPE: Fix typo st,stmpe601 (should be
st,stmpe610)
- Syscon: Add ESWIN EIC7700 compatible
- Syscon: Allow syscon compatible for Loongson-2K0300 chip id
- Syscon: Disallow simple-bus with syscon
- Syscon: Drop custom select for older dtschema
- TI OMAP USBHS TLL: Convert to DT schema"
* tag 'mfd-next-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd: (45 commits)
mfd: cs42l43: Fix regmap defaults ordering
dt-bindings: mfd: syscon: Allow syscon compatible for Loongson-2K0300 chip id
dt-bindings: mfd: syscon: Add ESWIN EIC7700 compatible
mfd: qnap-mcu: keep the reply buffer alive past a command timeout
dt-bindings: mfd: qcom,tcsr: Document the IPQ9650 TCSR block
mfd: macsmc: Fix key count endianness annotation
dt-bindings: mfd: qcom,spmi-pmic: Document haptics device
mfd: iqs62x: Reject zero-length firmware records
mfd: rave-sp: validate received frame payload lengths
mfd: sm501: Fix potential memory leaks during remove
mfd: viperboard: Fix native fields type in structures as little-endian
mfd: si476x-i2c: Get rid of duplicate NULL checks
dt-bindings: mfd: Convert OMAP USB TLL to DT schema
mfd: cgbc: Fix teardown ordering in cgbc_remove()
mfd: mt6397-core: Add mt6323 AUXADC support
dt-bindings: mfd: qcom,tcsr: Add compatible for Hawi and Maili SoCs
mfd: rohm: Factor out power button registration
mfd: ucb1x00: Convert Assabet gpio-keys to use software nodes
mfd: ucb1x00: Register software node for GPIO controller
mfd: cs42l43: Tidy up formatting on sdw_device_id table
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator updates from Mark Brown:
"This is a relatively quiet release for the regulator API, we've had no
major core work and not really that much driver work either. There's a
bunch of activity, including several new devices, but nothing hugely
remarkable here.
- Reworking of the mode handling in the max14577 driver to fix issues
with collisions with enables
- Support for onsemi FAN53555BUC23X, Qualcomm IPQ9650, PM4125 VBUS
and PM8150B and Unisoc SC2730"
* tag 'regulator-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: (36 commits)
regulator: fan53555: Add support for FAN53555BUC23X type
regulator: qcom-rpmh: Fix coding style issues
regulator: qcom-rpmh: readback voltage/bypass/mode set during bootup
regulator: qcom-rpmh: Fix PMIC5 BOB bypass mode handling
soc: qcom: rpmh: Add support to read back resource settings
regulator: dt-bindings: ti,pbias-omap: Convert to DT schema
regulator: ab8500: Remove stale expand_register kernel-doc entry
regulator: dt-bindings: Correct white-space style
regulator: pfuze100: add set_suspend_disable for LDO ops
regulator: core: use system_freezable_wq for init complete work
regulator: rt6245: Restore state on enable failure
regulator: tps65185: handle gpiod_get_value_cansleep() error returns
regulator: fan53555: Add support for mode operations on Silergy devices
regulator: dt-bindings: Add fan53555 allowed modes
regulator: wm831x-isink: remove conditional return with no effect
regulator: dt-bindings: Convert ltc3589.txt to yaml format
regulator: dt-bindings: tps51632: Convert to DT schema
regulator: mcp16502: Convert to dev_err_probe() in mcp16502_probe()
regulator: adp5055: Fix error code in adp5055_of_parse_cb()
regulator: qcom_usb_vbus: add support for qcom,pm4125-vbus-reg
...
|
|
The probe drives WAKEUP high with GPIOD_OUT_HIGH, enables the input
supply, and then issues a regmap_update_bits() on INT_EN2 with no wait
anywhere in between. The TPS65185 data sheet (TI SLVSAQ8G, February
2011, revised September 2017), section 7.6 "Timing Requirements: Data
Transmission", Figure 2 "Power-Up and Power-Down Timing Diagram",
footnote 1, requires 1.8 ms minimum between the WAKEUP rising edge and
the IC being ready to accept an I2C transaction. The driver calls no
delay function anywhere, and nothing on that path is guaranteed to take
that long.
On an RK3026 board the first transfer was NAKed:
tps65185 0-0068: error -ENXIO: failed to enable temp irq
-ENXIO here is rk3x_i2c reporting REG_INT_NAKRCV. Probe failed, so
vposneg never registered and its consumer deferred indefinitely.
Wait after the supply rather than at the gpiod_get(). Figure 2 times
that 1.8 ms from a WAKEUP edge with VIN already up, whereas this driver
asserts WAKEUP before enabling vin-supply; the data sheet does not
describe that order, so on a board whose vin-supply is a switched
regulator that was off, a wait placed at the gpiod_get() could elapse
before the part had power. Waiting from whichever of the two comes last
satisfies the specified case and is the conservative choice in the
other.
It also goes above the interrupt request rather than immediately before
the INT_EN2 write, because that write is not necessarily the first
transfer: tps65185_irq_thread() reads INT1 and INT2, and it is
requested with IRQF_TRIGGER_LOW, so it can run as soon as the handler
is installed.
Tested on an ONYX BOOX C67ML (RK3026): the chip now probes, all three
regulators register and the EPD controller comes up.
Fixes: b0fc1e770194 ("regulator: Add TPS65185 driver")
Signed-off-by: Mario Rugiero <mrugiero@gmail.com>
Link: https://patch.msgid.link/20260815232229.68474-1-mrugiero@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
FAN53555BUC23X has the ID 0 and REV 0xc, starts at 600mV and
increments in 12.5mV steps.
Per the datasheet, the FAN53555BUC23X (23 option) is grouped with
the 00 and 13 options for soft-start timing (t_SS = 300us typ.),
so the existing enable_time = 400 is reused here as well.
This variant is found on the ASUS Tinker Edge R (RK3399Pro) as the
supply regulator for both vdd_gpu and vdd_cpu_b. Verified across
the full GPU OPP table with the userspace devfreq governor.
Signed-off-by: Arash Golgol <arash.golgol@gmail.com>
Link: https://patch.msgid.link/20260812125054.19111-1-arash.golgol@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com> says:
This patch series adds a new `rpmh_read()` API to allow reading RPMH
addresses. Using this API enhances the RPMH regulator driver by adding
readback of the voltage/bypass/mode settings as they have been applied by
APPS during the bootloader stage, so regulator framework can get them
via `get_mode`, `get_bypass` & `get_voltage_selector` callbacks during
regulator registration.
This is needed because currently regulator framework does a unnecessary
write with `min-microvolt` DT setting for all the RPMH regulators during
regulator registration, because the first time after boot the value is
seen as -ENOTRECOVERABLE, as there is no option to read these regulator
settings.
With this change this unnecessary write can be avoided and regulator
framework gets a sense of the initial state set during the bootloader
stage for all regulator settings.
NOTE - During discussion on the v2 series - PATCH 3/4, reviewer had
inquired about possible need for the use of the sync_state() to handle the
"multiple" client case - for maintaining the regulator settings till all
the clients are probed.
This case was not covered in my previous series and had originally planned
to do that series separately. But after the discussion decided to merge
the 2 series as it seemed this would be a better approach. But after
working on sync_state change. I realized a basic issue with using
sync_state() for regulators - that its per-driver and not per-regulator
resource. But we needed a sync_state callback for each regulator separately.
I had been experimenting with few ideas but seems its going to need more
time for me to close on the equivalent solution that has per-regulator
sync_state or something to that effect. So I thought to close on this
series and attend to that separately.
Link: https://patch.msgid.link/20260801-b4-read-rpmh-v5-v6-0-9fcb54928523@oss.qualcomm.com
|
|
Fix the code style/format issues reported by checkpatch.pl
script.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com>
Link: https://patch.msgid.link/20260801-b4-read-rpmh-v5-v6-4-9fcb54928523@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Currently, during regulator registration, regulator framework sends an
unnecessary `min-microvolts` request for the rpmh-regulator device. This
happens because in current design, we do not have a way to readback the
voltage settings that was set during the bootloader stage.
Fix this by using the rpmh_read() API to read the regulator voltage
settings done during boot and make it available to regulator framework
from the very first read after the bootup.
Also use this API to read the mode/bypass settings as well. This will
provide the regulator framework a sense of the initial settings done by
bootloader and thus preventing any redundant writes for any setting post
bootup incase the same setting was already applied during bootup.
Signed-off-by: Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com>
Link: https://patch.msgid.link/20260801-b4-read-rpmh-v5-v6-3-9fcb54928523@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Currently, when `rpmh_regulator_set_mode_bypass()` helper function
is called to set bypass mode, it sends PMIC4's BOB bypass mode
value for even if its a PMIC5 BOB.
To fix this, introduce new hw_data parameter`pmic_bypass_mode`
to store bypass mode value. Use it to send correct PMIC bypass
mode value that corresponds to PMIC4/5 BOB regulators from the
helper function.
Fixes: 610f29e5cc0e8d58 ("regulator: qcom-rpmh: Update PMIC modes for PMIC5")
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com>
Link: https://patch.msgid.link/20260801-b4-read-rpmh-v5-v6-2-9fcb54928523@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Commit aeee55b76bfd ("regulator: ab8500: Remove unused embedded struct
expand_register") deleted the expand_register member from struct
ab8500_regulator_info and, in the same hunk, added an empty
"@expand_register:" line to the kernel-doc block. That traded one W=1
warning for another:
drivers/regulator/ab8500.c:196 Excess struct member 'expand_register'
description in 'ab8500_regulator_info'
Drop the leftover line; the remaining @member entries all match the
struct.
No functional changes.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/r/202605160857.ZIE3nO9J-lkp@intel.com/
Assisted-by: Claude:claude-opus-5 [kernel-doc]
Signed-off-by: Babanpreet Singh <bbnpreetsingh@gmail.com>
Link: https://patch.msgid.link/20260802013304.7-1-bbnpreetsingh@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The VPOSNEG_table[] mapping does not match the FP9931 datasheet.
The datasheet defines the VPOS/VNEG voltage mapping as:
00h-04h -> 7.04V (-7.04V)
05h -> 7.26V (-7.26V)
06h -> 7.49V (-7.49V)
...
28h-3Fh -> 15.06V (-15.06V)
However, VPOSNEG_table[] has two issues:
1. Selector 0x00~0x04 should all map to 7.04V (5 entries), but the
table has 6 entries of 7.04V, causing all subsequent entries to be
shifted by one position.
2. Selectors 0x29~0x3F should all clamp to 15.06V (23 entries), but
the table has only 41 entries. Any selector value above 0x28
would result in an out-of-bounds table access.
Fix both issues by removing the duplicate 7.04V entry and appending
the missing 23 clamped 15.06V entries, bringing the table to the
correct size of 64 entries (0x00~0x3F).
Fixes: 12d821bd13d4 ("regulator: Add FP9931/JD9930 driver")
Signed-off-by: Robby Cai <robby.cai@nxp.com>
Link: https://patch.msgid.link/20260724103441.800522-2-robby.cai@oss.nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Joy Zou <joy.zou@oss.nxp.com> says:
The regulator_init_complete_work fires ~30s after boot to disable
unused regulators via I2C. When this work races with PM suspend, the
I2C adapter may already be suspended, causing a -ESHUTDOWN warning
dump.
This series addresses the race and adds proper suspend power
management for unused LDO regulators.
Link: https://patch.msgid.link/20260731-b4-regulator-pf01-v2-0-a406c8737fdb@oss.nxp.com
|
|
Add a set_suspend_disable callback to pfuze100_ldo_regulator_ops to
support the regulator-off-in-suspend DTS property for the VGEN LDO
regulators. This allows unused LDO regulators to be properly disabled
during system suspend, reducing power consumption.
The callback is only used by the LDO ops, so name it accordingly:
pfuze100_ldo_set_suspend_disable. It uses the per-regulator
stby_reg/stby_mask that already describe the standby control for
each LDO, so it works for every LDO covered by these ops.
Signed-off-by: Joy Zou <joy.zou@oss.nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260731-b4-regulator-pf01-v2-2-a406c8737fdb@oss.nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
schedule_delayed_work() uses system_wq, which is non-freezable, allowing
regulator_init_complete_work to run concurrently with system suspend. This
work fires ~30s after boot to disable unused regulators via I2C. When it
races with PM suspend, the I2C adapter may already be suspended, triggering
a -ESHUTDOWN warning in __i2c_transfer():
WARNING: ... at __i2c_transfer+0x36c/0x3c8
Call trace:
__i2c_transfer
i2c_transfer
regmap_i2c_write
_regmap_update_bits
regulator_disable_regmap
_regulator_do_disable
regulator_late_cleanup
regulator_init_complete_work_function
process_one_work
Switch to system_freezable_wq so the work is frozen before any device
is suspended, eliminating the race.
Fixes: 55576cf18537 ("regulator: Defer init completion for a while after late_initcall")
Signed-off-by: Joy Zou <joy.zou@oss.nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260731-b4-regulator-pf01-v2-1-a406c8737fdb@oss.nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Currently, if regcache_sync() fails after the enable GPIO has been
asserted, the driver returns with enable_gpio still set high and
regcache_cache_only() left disabled. This leaves the device state
inconsistent with the disabled state, where the enable GPIO is low and
cache_only is enabled.
On failure, restore the original state by setting cache_only back to
true and driving the enable GPIO low before returning the error.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Link: https://patch.msgid.link/20260729100018.66577-1-phucduc.bui@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Move the DBx500 PRCMU definitions into the DB8500 PRCMU
header and delete the wrapper header.
Convert users of simple PRCMU wrappers to call the DB8500 helpers
directly.
The dbx500-prcmu.h header was the result of an earlier attempt to
abstract several DBx5x SoC PRCMU units to use the same abstract
header. They are deleted from the kernel and this is not just
causing maintenance burden and build errors.
The stub code is using -ENOSYS in a way checkpatch complains about
so replace these with -EINVAL while we're at it.
Assisted-by: Codex:gpt-5-5
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202606180825.vUSQntkJ-lkp@intel.com/
Signed-off-by: Linus Walleij <linusw@kernel.org>
Acked-by: Brian Masney <bmasney@redhat.com>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/oe-kbuild-all/202606180825.vUSQntkJ-lkp@intel.com/
Link: https://patch.msgid.link/20260619-mfd-prcmu-merge-headers-v1-1-8ea0ee23b4d6@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
tps65185_vposneg_enable() evaluated:
if (gpiod_get_value_cansleep(data->pgood_gpio) != 1)
return -ETIMEDOUT;
gpiod_get_value_cansleep() returns 1 if active, 0 if inactive, and a
negative error code (e.g. -EIO or -EINVAL) on failure. Evaluating != 1
treats a negative error code as non-equal, swallowing GPIO read errors and
masking them as -ETIMEDOUT.
Fix this by capturing the return value of gpiod_get_value_cansleep(). If
it returns a negative error code, propagate that error immediately; if
it returns 0 (inactive), return -ETIMEDOUT.
Fixes: b0fc1e770194 ("regulator: Add TPS65185 driver")
Signed-off-by: Surendra Singh Chouhan <kr494167@gmail.com>
Reviewed-by: Andreas Kemnade <andreas@kemnade.info>
Link: https://patch.msgid.link/20260724125858.75635-1-kr494167@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The PM8350B has only one LDO, which gets its power from a dedicated input.
Add support for it.
Signed-off-by: Esteban Urrutia <esteuwu@proton.me>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://patch.msgid.link/20260723-pm8350b-ldo-v1-2-42b5428a0d3f@proton.me
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Make the PWM mode configurable from devicetree. Some boards require forced
PWM mode to keep the supply ripple within acceptable limits under light
load conditions
Support is restricted to Silergy manufacturer as it is the only one
currently tested.
Signed-off-by: Victor Krawiec <victor.krawiec@arturia.com>
Link: https://patch.msgid.link/20260723094001.120264-5-victor.krawiec@arturia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Both branches of the check return the same value, so the check has
no effect. Remove it and return the value directly.
This is the result of running the Coccinelle script from
scripts/coccinelle/misc/cond_return_no_effect.cocci.
Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20260723184538.3888637-29-ekffu200098@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
machine_constraints_voltage() currently applies apply_uV against the
machine-supplied [min_uV, max_uV] range, and only afterwards clamps
that range down to what the regulator can actually supply (via
ops->list_voltage()).
If the machine-supplied range is wider than the regulator's actual
range, apply_uV's rounding can pick a selector outside the (correct)
clamped range, so the regulator ends up programmed outside its clamped
min/max. At bring-up this shows up as a voltage read-back outside the
clamped range.
Fix this by moving the clamping block ahead of the apply_uV block, so
apply_uV always targets an already-clamped range. Whether apply_uV
should run is decided from the unclamped constraints beforehand and
stored in a local bool, since clamping must not itself change whether
apply_uV fires.
No functional change to the clamping logic itself, only its position
relative to apply_uV. Its early return 0 exits become fallthroughs
since the apply_uV logic now follows it.
Assisted-by: Claude:claude-sonnet-5
Signed-off-by: Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com>
Link: https://patch.msgid.link/20260720-b4-regulator-core-clamp-voltage-v1-1-8e5eec076a8e@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The "fixed" LDOs with output voltage calibration use
mt6358_get_buck_voltage_sel as their get_voltage_sel op, but the
MT6358_REG_FIXED and MT6366_REG_FIXED entries do not populate
da_vsel_reg/da_vsel_mask. The op therefore reads register 0x0 with a
zero mask and shifts the result by ffs(0) - 1 = -1, which is undefined
behaviour and gets flagged by UBSAN on every boot on MT6366 boards:
UBSAN: shift-out-of-bounds in drivers/regulator/mt6358-regulator.c:384:38
shift exponent -1 is negative
Call trace:
mt6358_get_buck_voltage_sel+0xc8/0x120
regulator_get_voltage_rdev+0x70/0x170
set_machine_constraints+0x504/0xc38
regulator_register+0x324/0xc68
Besides the undefined shift, the returned selector is always 0, so the
actual calibration offset programmed in <reg>_ANA_CON0 is never
reported.
The descriptor already carries the correct vsel_reg/vsel_mask (the
ANA_CON0 calibration field), matching the regulator_set_voltage_sel_regmap
op already in use. Read the selector back through
regulator_get_voltage_sel_regmap instead.
Fixes: cf08fa74c716 ("regulator: mt6358: Add output voltage fine tuning to fixed regulators")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Reviewed-by: Chen-Yu Tsai <wens@kernel.org>
Tested-by: Chen-Yu Tsai <wens@kernel.org>
Link: https://patch.msgid.link/dcd98d81dede338c9bbb9700a9613c848b702e49.1784336005.git.daniel@makrotopia.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The LTC3676_IRQSTAT_* bit definitions do not match the IRQSTAT
(Interrupt Request Status) register layout documented in Table 15
of the LTC3676/LTC3676-1 datasheet:
bit 0 - Pushbutton Status Active
bit 1 - Hard Reset Occurred
bit 2 - PGOOD Timeout Occurred
bit 3 - Undervoltage Warning
bit 4 - Undervoltage Standby (Fault) Occurred
bit 5 - Overtemperature Warning
bit 6 - Overtemperature Standby (Fault) Occurred
bit 7 - Reserved
The driver instead defines these starting at bit 3, one bit higher
than the datasheet specifies, which causes ltc3676_regulator_isr()
to check the wrong status bits and misreport (or miss) PGOOD
timeout, undervoltage and thermal warning/fault conditions.
Fix the bit offsets to match the datasheet.
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/20260715170408.295552-1-Abhishek.ojha@savoirfairelinux.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The mcp16502_probe() currently uses dev_err() for logging errors.
However, functions like devm_regmap_init_i2c, devm_gpiod_get_optional
and devm_regulator_register can return -EPROBE_DEFER. Using dev_err()
in these situations can cause unnecessary error spam in dmesg.
As a result, convert to dev_err_probe(). It also simplifies the print
and return operations into single statement. The 'ret' variable is no
longer required and has been removed.
Originally detected by Coccinelle with this warning "Consider using
%pe to print PTR_ERR()"
Compile-tested only.
Signed-off-by: Ninad Naik <ninadnaik07@gmail.com>
Link: https://patch.msgid.link/20260714192228.1639768-1-ninadnaik07@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
This code accidentally returned the wrong variable instead of a negative
error code. Return -EINVAL.
Fixes: 147b2a96f24e ("regulator: adp5055: Add driver for adp5055")
Signed-off-by: Dan Carpenter <error27@gmail.com>
Link: https://patch.msgid.link/alFJVBbiFNxhqa_1@stanley.mountain
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Compare against -EDEADLK, which is what ww_mutex_lock() actually
returns and what every other deadlock check in this file already uses.
Function regulator_lock_two() acquires two regulators via
regulator_lock_nested() -> ww_mutex_lock(). On contention,
ww_mutex_lock() returns -EDEADLK, which is the caller's signal to drop
the lock it holds and retry the acquisition in the canonical order.
However, regulator_lock_two() tests the return value against -EDEADLOCK
rather than -EDEADLK. On most architectures, EDEADLK and EDEADLOCK are
the same value, so the comparison happens to be correct and the bug is
invisible. But on MIPS, SPARC, and PowerPC, those two errors have
different values. The test is wrong: a genuine -EDEADLK backoff no
longer matches -EDEADLOCK, so instead of unlocking and retrying, the
code falls into WARN_ON(ret) and returns with only one of the two
regulators locked.
In practice, this is a bug only on MIPS, because the regulator core is
not built or used on the other two platforms.
In general, EDEADLK is preferred over EDEADLOCK for new code.
Fixes: cba6cfdc7c3f ("regulator: core: Avoid lockdep reports when resolving supplies")
Signed-off-by: Timur Tabi <ttabi@nvidia.com>
Link: https://patch.msgid.link/20260708235722.2953579-1-ttabi@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The driver has an OF match table wired to .of_match_table, but does
not export the table with MODULE_DEVICE_TABLE().
Add the missing MODULE_DEVICE_TABLE(of, ...) entry so module alias
information is generated for OF based module autoloading.
This is a source-level fix. It does not claim dynamic hardware
reproduction; the evidence is the driver-owned match table, its use by
the platform driver, and the missing module alias publication.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Link: https://patch.msgid.link/20260704124352.7981-1-pengpeng@iscas.ac.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The driver has an OF match table wired to .of_match_table, but does
not export the table with MODULE_DEVICE_TABLE().
Add the missing MODULE_DEVICE_TABLE(of, ...) entry so module alias
information is generated for OF based module autoloading.
This is a source-level fix. It does not claim dynamic hardware
reproduction; the evidence is the driver-owned match table, its use by
the platform driver, and the missing module alias publication.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Link: https://patch.msgid.link/20260704122926.21586-1-pengpeng@iscas.ac.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Rakesh Kota <rakesh.kota@oss.qualcomm.com> says:
Add support for PM4125 USB VBUS regulator. Unlike PM8150B which uses
a current-limit selector, PM4125 uses a 2-bit VBOOST voltage selector
supporting 4.25 V, 4.5 V, 4.75 V and 5.0 V output.
Link: https://patch.msgid.link/20260706-add_pm4125-vbus-reg-v3-0-999d78a87b81@oss.qualcomm.com
|
|
The PM4125 PMIC uses a different register layout for USB VBUS control
compared to PM8150B. On PM4125, CMD_OTG is at offset 0x50, OTG_CFG is
at 0x56, and offset 0x52 is a 2-bit VBOOST voltage selector rather than
a current-limit selector.
Add pm4125_data using the abstraction introduced for PM8150B, along with
dedicated voltage-selector ops and the pm4125_vboost_table covering the
four supported boost voltages: 4.25 V, 4.5 V, 4.75 V, and 5.0 V.
Signed-off-by: Rakesh Kota <rakesh.kota@oss.qualcomm.com>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://patch.msgid.link/20260706-add_pm4125-vbus-reg-v3-3-999d78a87b81@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Introduce per-compatible regulator descriptor data via struct
qcom_usb_vbus_reg_data to abstract register layout differences between
PMICs. This allows the probe function to dynamically populate the
regulator_desc fields rather than relying on compile-time constants.
Refactor the existing PM8150B support to use this abstraction, wiring in
its CMD_OTG, OTG_CFG, and current-limit registers through pm8150b_data.
No functional change is intended for PM8150B.
Signed-off-by: Rakesh Kota <rakesh.kota@oss.qualcomm.com>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://patch.msgid.link/20260706-add_pm4125-vbus-reg-v3-2-999d78a87b81@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Add a regulator driver for the Spreadtrum/Unisoc SC2730 PMIC, used
e.g. with the UMS512 and UMS9230 SoCs. This version of the driver is
based on a downstream driver provided by Unisoc [1][2] and the existing
SC2731 driver.
[1]: https://github.com/MotorolaMobilityLLC/kernel-sprd/commit/30be0ddfe6b9a877fc9c328fbd2bae84e645eb31
[2]: https://github.com/MotorolaMobilityLLC/kernel-sprd/blob/android-13-release-tla33/drivers/regulator/sc2730-regulator.c
Signed-off-by: Zhongfa Wang <zhongfa.wang@unisoc.com>
[cleanup, adapt to new device tree requirements]
Signed-off-by: Otto Pflüger <otto.pflueger@abscue.de>
Link: https://patch.msgid.link/20260701-sc2730-regulators-v7-2-6e145ce83657@abscue.de
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
files)
Replace the #include of <linux/mod_devicetable.h> by the more specific
<linux/device-id/*.h> where applicable. For most cases the include
can be dropped completely, only a few drivers need one or two headers
added.
Acked-by: Danilo Krummrich <dakr@kernel.org>
Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/1a3f2007c5c5dcf555c09a4035ce3ae8ef1b6c49.1782808461.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
|
|
ownership transferred to rdata
In max8998_pmic_dt_parse_pdata(), of_get_child_by_name() acquires a
reference on reg_np which is then stored in rdata->reg_node, transferring
ownership to the regulator data array. The subsequent of_node_put(reg_np)
at the end of the function releases the last matched regulator node's
reference, leaving rdata->reg_node as a dangling pointer for the last
entry.
Remove the spurious of_node_put(reg_np) call.
Cc: stable@vger.kernel.org
Fixes: 156f252857df ("drivers: regulator: add Maxim 8998 driver")
Signed-off-by: WenTao Liang <vulab@iscas.ac.cn>
Link: https://patch.msgid.link/20260626160326.54457-1-vulab@iscas.ac.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
dangling of_node pointer
In as3722_get_regulator_dt_data(), of_get_child_by_name() acquires a
reference on np, which is then assigned to pdev->dev.of_node. The
function immediately calls of_node_put(np), releasing the reference and
leaving pdev->dev.of_node as a dangling pointer.
Remove the of_node_put(np) call to let the device hold the reference.
Cc: stable@vger.kernel.org
Fixes: bc407334e9a6 ("regulator: as3722: add regulator driver for AMS AS3722")
Signed-off-by: WenTao Liang <vulab@iscas.ac.cn>
Link: https://patch.msgid.link/20260626160150.54291-1-vulab@iscas.ac.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
In tps6594_regulator_probe(), the multi-phase configuration loop calls
of_find_node_by_name() to find buck nodes by name, and of_get_parent()
twice to navigate to the PMIC parent node. None of the acquired node
references (np, intermediate parent, np_pmic_parent) are ever released
via of_node_put(), causing a reference leak on every loop iteration.
Additionally, of_find_node_by_name() can return NULL, but the result was
immediately passed to of_node_full_name() and of_get_parent() without a
NULL check, which could lead to a NULL pointer dereference.
Fix this by:
- Adding a NULL check for np after of_find_node_by_name()
- Storing the intermediate parent node in a local variable np_parent
- Calling of_node_put() on np, np_parent and np_pmic_parent at the
end of each loop iteration
Fixes: f17ccc5deb4d ("regulator: tps6594-regulator: Add driver for TI TPS6594 regulators")
Signed-off-by: Uday Khare <udaykhare77@gmail.com>
Link: https://patch.msgid.link/20260618132327.11529-1-udaykhare77@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> says:
[Nothing]
Link: https://patch.msgid.link/cover.1782827697.git.u.kleine-koenig@baylibre.com
|
|
The two previous patches did some style improvements while adapting the
i2c_device_id arrays. Adapt all the remaining regulator drivers to use
the same style. That is:
- Use a comma after a initialisation value unless the closing } is in
the same line.
- Don't use a comma after the list terminator.
- Use a space after the opening { and one before the closing }; a
single space for an empty pair.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
Link: https://patch.msgid.link/221a2e634f6bbf9638b906470ffb1b2b413e0a5a.1782827697.git.u.kleine-koenig@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
