This converts some of the visually simpler cases that have been split
over multiple lines. I only did the ones that are easy to verify the
resulting diff by having just that final GFP_KERNEL argument on the next
line.
Somebody should probably do a proper coccinelle script for this, but for
me the trivial script actually resulted in an assertion failure in the
middle of the script. I probably had made it a bit _too_ trivial.
So after fighting that far a while I decided to just do some of the
syntactically simpler cases with variations of the previous 'sed'
scripts.
The more syntactically complex multi-line cases would mostly really want
whitespace cleanup anyway.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This was done entirely with mindless brute force, using
git grep -l '\<k[vmz]*alloc_objs*(.*, GFP_KERNEL)' |
xargs sed -i 's/\(alloc_objs*(.*\), GFP_KERNEL)/\1)/'
to convert the new alloc_obj() users that had a simple GFP_KERNEL
argument to just drop that argument.
Note that due to the extreme simplicity of the scripting, any slightly
more complex cases spread over multiple lines would not be triggered:
they definitely exist, but this covers the vast bulk of the cases, and
the resulting diff is also then easier to check automatically.
For the same reason the 'flex' versions will be done as a separate
conversion.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This is the result of running the Coccinelle script from
scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to
avoid scalar types (which need careful case-by-case checking), and
instead replace kmalloc-family calls that allocate struct or union
object instances:
Single allocations: kmalloc(sizeof(TYPE), ...)
are replaced with: kmalloc_obj(TYPE, ...)
Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...)
are replaced with: kmalloc_objs(TYPE, COUNT, ...)
Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...)
are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...)
(where TYPE may also be *VAR)
The resulting allocations no longer return "void *", instead returning
"TYPE *".
Signed-off-by: Kees Cook <kees@kernel.org>
Pull regulator fixes from Mark Brown:
"A few driver specific fixes, plus a patch from Bjorn which removes a
fixed limit on regulator names that was breaking some Qualcomm
systems"
* tag 'regulator-fix-v7.0-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: s2mps11: fix pctrlsel macro usage in s2mpg10_of_parse_cb()
regulator: s2mps11: drop redundant sanity checks in s2mpg10_of_parse_cb()
regulator: core: Remove regulator supply_name length limit
regulator: mt6363: Fix interrmittent timeout
Pull MFD updates from Lee Jones:
"New Support & Features:
- Add comprehensive support for the ROHM BD72720 PMIC, including core
MFD, regulator, GPIO, clock gate, RTC, and power-supply drivers
- Add support for the Rockchip RK801 PMIC, including core MFD and
regulator drivers
- Add support for the ROHM BD73900 PMIC by leveraging existing common
drivers
- Wire up RTC, hwmon, and input sub-devices for the Apple SMC
(macsmc) driver
- Add support for the Delta Networks TN48M switch CPLD via the
simple-mfd-i2c driver
- Add support for the TS133 variant to the QNAP MCU driver
- Provide support for the sama7d65 XLCD controller in the Atmel HLCDC
driver
- Add backlight sub-device support to the Congatec Board Controller
(cgbc)
- Add Intel Nova Lake-S (NVL-S) PCI IDs to the Intel LPSS driver
Improvements & Fixes:
- Implement a "wrapper regmap" for the ROHM BD72720 to handle dual
I2C slave addresses (0x4b and 0x4c) transparently for child devices
- Introduce mutex locking around 'mfd_of_node_list' in the MFD core
to ensure safe concurrent access
- Fix a potential regulator resource leak in the Arizona core driver
during boot sequence failures
- Resolve child device duplication issues on driver rebind for
Qualcomm PM8xxx and OMAP USB host drivers by using
of_platform_depopulate()
- Fix IRQ domain name duplication for the Samsung S2MPG10 by adding a
unique domain suffix
- Implement LOCK register handling for the TI TPS65214 variant to
unlock registers at probe time
- Fully convert the Loongson-2K BMC driver to use managed resources
(pcim) and the standard PCI resource API
- Ensure the Apple SMC mutex is correctly initialized during probe to
prevent NULL pointer dereferences
- Expand the ROHM BD71828 power-supply driver to support 9-bit
register addresses
- Simplify the Samsung S5M RTC driver by querying platform device IRQ
resources directly
- Revert an incorrect read-to-write mask change in the DA9052 SPI
driver to restore default OTP behavior
- Fix kernel-doc warnings in the TI TPS6105x driver
- Cleanups & Refactoring
- Simplify the MFD core by utilizing the scoped
for_each_child_of_node_scoped() macro and streamlining device_node
storage
- Rename ROHM BD71828 IC-specific entities to use consistent prefixes
for better extensibility
- Refactor ROHM BD71828 regmap definitions using the
regmap_reg_range() macro
- Update the ROHM BD71828 driver to use standard C-style comment
headers
- Remove the now unused 'irq_data' field from the Samsung SEC core
structure
- Drop unnecessary use of irqd_get_trigger_type() in the Maxim
MAX77759 driver
- Default MFD_SPACEMIT_P1 to 'm' if ARCH_SPACEMIT is selected
- Add missing charger-related registers to the ROHM BD71828 core
header and Type-C CC registers to the AXP717
Device Tree Binding Updates:
- Add new bindings for the ROHM BD72720 PMIC, Rockchip RK801 PMIC,
Bitmain BM1880 System Controller, and NXP LPC32xx System Control
Block
- Clarify trickle-charge terminology and add properties for voltage
drop (VDR) correction and upper charge limits to the generic
battery binding
- Document GPR syscon for NXP S32 SoCs and the smp-memram subnode for
Aspeed SCU
- Document numerous new Qualcomm SPMI PMIC compatibles (pmcx0102,
pmh0101, pmk8850, etc)
- Add compatibles for the sama7d65 XLCD (Atmel), LAN9691 Flexcom
(Microchip), and various MediaTek SCPSYS and regulator components
- Fix a dead link to the audio codec binding in the DA9055
documentation"
* tag 'mfd-next-6.20' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd: (41 commits)
dt-bindings: mfd: da9055: Fix dead link to codec binding
mfd: cgbc: Add support for backlight
dt-bindings: mfd: qcom,spmi-pmic: Document PMICs present on Glymur and Kaanapali
dt-bindings: mfd: Document smp-memram subnode for aspeed,ast2x00-scu
mfd: intel-lpss: Add Intel Nova Lake-S PCI IDs
mfd: ls2kbmc: Use PCI API instead of direct accesses
mfd: ls2kbmc: Fully convert to use managed resources
dt-bindings: mfd: mediatek: mt6397: Add missing MT6331 regulator compat
dt-bindings: mfd: mediatek,mt8195-scpsys: Add mediatek,mt6795-scpsys
dt-bindings: mfd: atmel,sama5d2-flexcom: Add microchip,lan9691-flexcom
mfd: omap-usb-host: Fix OF populate on driver rebind
mfd: qcom-pm8xxx: Fix OF populate on driver rebind
dt-bindings: mfd: syscon: Allow syscon compatible for mediatek,mt7981-topmisc
mfd: qnap-mcu: Add driver data for TS133 variant
dt-bindings: mfd: qnap,ts433-mcu: Add qnap,ts133-mcu compatible
mfd: sec: Fix IRQ domain names duplication
mfd: simple-mfd-i2c: Add Delta TN48M CPLD support
mfd: macsmc: Initialize mutex
dt-bindings: mfd: nxp: Add NXP LPC32xx System Control Block
mfd: Kconfig: Default MFD_SPACEMIT_P1 to 'm' if ARCH_SPACEMIT
...
When creating the regulator object, associated with a consumer device,
the supply_name is string formatted into a statically sized buffer on
the stack, then strdup()'ed onto the heap.
Not only is the dance on the stack unnecessary, but when the device's
name is long we might not fit the constructed supply_name in the fixed
64 byte buffer on the stack.
One such case can be seen on the Qualcomm Rb3Gen2 board, where we find a
PCIe controller, with a PCIe switch, with a USB controller, with a USB
hub, consuming a regulator. In this example the dev->kobj.name itself is
62 characters long.
Drop the temporary buffer on the stack and kasprintf() the string
directly on the heap, both to simplify the code, and to remove the
length limitation.
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
Link: https://patch.msgid.link/20260211-regulator-supply-name-length-v1-1-3875541c1576@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Pull gpio updates from Bartosz Golaszewski:
"There are two new drivers and some changes to GPIO core but mostly
just GPIO driver updates across a wide array of files, adding support
for new models as well as various refactoring changes. Nothing
controversial and everything has spent a good measure of time in
linux-next.
GPIOLIB core:
- shrink the GPIO bus driver stub code
- rework software node support for "undefined" software nodes
- provide and use devm_fwnode_gpiod_get_optional()
- only compile the OF quirk for MT2701 when needed
New drivers:
- add the GPIO driver for ROHM bd72720
- add the gpio-line-mux driver providing 1-to-many mapping for a
single real GPIO
Driver changes:
- refactor gpio-pca9570: use lock guard, add missing headers, use
devres consistently
- add support for a new model (G7 Aspeed sgpiom) to the aspeed-sgpio
driver along with some prerequisite refactoring
- use device_get_match_data() where applicable and save some lines
- add support for more models to gpio-cadence
- add the compatible property to reset-gpio and use it in shared GPIO
management
- drop unnecessary use of irqd_get_trigger_type() in gpio-max77759
- add support for a new variant to gpio-pca953x
- extend build coverage with COMPILE_TEST for more drivers
- constify configfs structures in gpio-sim and gpio-virtuser
- add support for the K3 SoC to gpio-spacemit
- implement the missing .get_direction() callback in gpio-max77620
- add support for Tegra264 to gpio-tegra186
- drop unneeded MODULE_ALIAS() from gpio-menz127
DT bindings:
- document support for the opencores GPIO controller in gpio-mmio
- document new variants for gpio-pca953x
Documentation:
- extensively describe interrupt source detection for gpio-pca953x
and add more models to the list of supported variants"
* tag 'gpio-updates-for-v7.0-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: (59 commits)
gpio: tegra186: Add support for Tegra264
dt-bindings: gpio: Add Tegra264 support
gpio: spacemit-k1: Use PDR for pin direction, not SDR/CDR
gpio: max77620: Implement .get_direction() callback
gpio: aspeed-sgpio: Support G7 Aspeed sgpiom controller
dt-bindings: gpio: aspeed,sgpio: Support ast2700
gpio: aspeed-sgpio: Convert IRQ functions to use llops callbacks
gpio: aspeed-sgpio: Create llops to handle hardware access
gpio: aspeed-sgpio: Remove unused bank name field
gpio: aspeed-sgpio: Change the macro to support deferred probe
regulator: bd71815: switch to devm_fwnode_gpiod_get_optional
gpiolib: introduce devm_fwnode_gpiod_get_optional() wrapper
gpio: mmio: Add compatible for opencores GPIO
dt-bindings: gpio-mmio: Correct opencores GPIO
gpio: pca9570: use lock guards
gpio: pca9570: Don't use "proxy" headers
gpio: pca9570: Use devm_mutex_init() for mutex initialization
MAINTAINERS: Add ROHM BD72720 PMIC
power: supply: bd71828-power: Support ROHM BD72720
power: supply: bd71828: Support wider register addresses
...
Pull regulator updates from Mark Brown:
"There's a bunch of new drivers here, plus a lot of hardening for the
supply resolution code which allow us to support systems where we have
two PMICs each of which has regulators supplied by the other. This did
work a long time ago but got broken as part of improved integration
with the device model, it's fairly rare so nobody noticed.
- Improvements for supply handling from André Draszik to allow
systems with two PMICs with supply/consumer relationships in both
directions to instantiate.
- New drivers for Maxim MAX776750, Realtek RT8902, Samsung S2MPG11,
Texas Instuments TPS65185.
This have also pulls in some MFD updates which are build dependencies
for the Samsung S2MPG11 support"
* tag 'regulator-v6.20' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: (42 commits)
regulator: s2mps11: more descriptive gpio consumer name
regulator: s2mps11: add S2MPG11 regulator
regulator: s2mps11: refactor S2MPG10 regulator macros for S2MPG11 reuse
regulator: s2mps11: refactor S2MPG10 ::set_voltage_time() for S2MPG11 reuse
regulator: s2mps11: add S2MPG10 regulator
regulator: s2mps11: refactor handling of external rail control
regulator: s2mps11: update node parsing (allow -supply properties)
regulator: s2mps11: place constants on right side of comparison tests
regulator: s2mps11: use dev_err_probe() where appropriate
regulator: s2mps11: drop two needless variable initialisations
regulator: add REGULATOR_LINEAR_VRANGE macro
regulator: dt-bindings: add s2mpg11-pmic regulators
regulator: dt-bindings: add s2mpg10-pmic regulators
dt-bindings: firmware: google,gs101-acpm-ipc: convert regulators to lowercase
mfd: sec: Add support for S2MPG11 PMIC via ACPM
mfd: sec: s2mpg10: Reorder regulators for better probe performance
dt-bindings: mfd: Add samsung,s2mpg11-pmic
dt-bindings: mfd: samsung,s2mpg10-pmic: Link to its regulators
dt-bindings: mfd: samsung,s2mps11: Split s2mpg10-pmic into separate file
mfd: sec: Drop now unused struct sec_pmic_dev::irq_data
...
Merge series from André Draszik <andre.draszik@linaro.org>:
This series extends the existing S2MPG10 PMIC driver to add support for
the regulators, and adds new S2MPG11 core and regulator drivers.
The patches are kept together in one series, due to S2MPG11 and its
regulators being very similar to S2MPG10.
The Samsung S2MPG11 PMIC is a Power Management IC for mobile
applications with buck converters, various LDOs, power meters, and
additional GPIO interfaces. It typically complements an S2MPG10 PMIC in
a main/sub configuration as the sub-PMIC and both are used on the
Google Pixel 6 and 6 Pro (oriole / raven).
A DT update for Oriole / Raven to enable these is required which I will
send out separately.
The S2MPG11 PMIC is a Power Management IC for mobile applications with
buck converters, various LDOs, power meters, and additional GPIO
interfaces. It typically complements an S2MPG10 PMIC in a main/sub
configuration as the sub-PMIC.
It has 12 buck, 1 buck-boost, and 15 LDO rails. Several of these can
either be controlled via software (register writes) or via external
signals, in particular by:
* input pins connected to a main processor's:
* GPIO pins
* other pins that are e.g. firmware- or power-domain-controlled
without explicit driver intervention
* a combination of input pins and register writes.
Control via input pins allows PMIC rails to be controlled by firmware,
e.g. during standby/suspend or as part of power domain handling where
otherwise that would not be possible. Additionally toggling a pin is
faster than register writes, and it also allows the PMIC to ensure that
any necessary timing requirements between rails are respected
automatically if multiple rails are to be enabled or disabled quasi
simultaneously.
This commit implements support for all these rails and control
combination.
Note1: For an externally controlled rail, the regulator_ops provide an
empty ::enable() and no ::disable() implementations, even though Linux
can not enable the rail and one might think ::enable could be NULL.
Without ops->enable(), the regulator core will assume enabling such a
rail failed, though, and in turn never add a reference to its parent
(supplier) rail. Once a different (Linux-controlled) sibling (consumer)
rail on that same parent rail gets disabled, the parent gets disabled
(cutting power to the externally controlled rail although it should
stay on), and the system will misbehave.
Note2: While external control via input pins appears to exist on other
versions of this PMIC, there is more flexibility in this version, in
particular there is a selection of input pins to choose from for each
rail (which must therefore be configured accordingly if in use),
whereas other versions don't have this flexibility.
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Link: https://patch.msgid.link/20260122-s2mpg1x-regulators-v7-19-3b1f9831fffd@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The upcoming S2MPG11 support needs a similar, but different version of
::set_voltage_time(). For S2MPG10, the downwards and upwards ramps for
a rail are at different offsets at the same bit positions, while for
S2MPG11 the ramps are at the same offset at different bit positions.
Refactor the existing version slightly to allow reuse.
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Link: https://patch.msgid.link/20260122-s2mpg1x-regulators-v7-17-3b1f9831fffd@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The S2MPG10 PMIC is a Power Management IC for mobile applications with
buck converters, various LDOs, power meters, RTC, clock outputs, and
additional GPIO interfaces.
It has 10 buck and 31 LDO rails. Several of these can either be
controlled via software (register writes) or via external signals, in
particular by:
* one out of several input pins connected to a main processor's:
* GPIO pins
* other pins that are e.g. firmware- or power-domain-controlled
without explicit driver intervention
* a combination of input pins and register writes.
Control via input pins allows PMIC rails to be controlled by firmware,
e.g. during standby/suspend, or as part of power domain handling where
otherwise that would not be possible. Additionally toggling a pin is
faster than register writes, and it also allows the PMIC to ensure that
any necessary timing requirements between rails are respected
automatically if multiple rails are to be enabled or disabled quasi
simultaneously.
This commit implements support for all these rails and control
combinations.
Additional data needs to be stored for each regulator, e.g. the input
pin for external control, or a rail-specific ramp-rate for when
enabling a buck-rail. Therefore, probe() is updated slightly to make
that possible.
Note1: For an externally controlled rail, the regulator_ops provide an
empty ::enable() and no ::disable() implementations, even though Linux
can not enable the rail and one might think ::enable could be NULL.
Without ops->enable(), the regulator core will assume enabling such a
rail failed, though, and in turn never add a reference to its parent
(supplier) rail. Once a different (Linux-controlled) sibling (consumer)
rail on that same parent rail gets disabled, the parent gets disabled
(cutting power to the externally controlled rail although it should
stay on), and the system will misbehave.
Note2: While external control via input pins appears to exist on other
versions of this PMIC, there is more flexibility in this version, in
particular there is a selection of input pins to choose from for each
rail (which must therefore be configured accordingly if in use),
whereas other versions don't have this flexibility.
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Link: https://patch.msgid.link/20260122-s2mpg1x-regulators-v7-16-3b1f9831fffd@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Refactor s2mps14_pmic_enable_ext_control() and s2mps11_of_parse_cb()
slightly as a preparation for adding S2MPG10 and S2MPG11 support, as
both of those PMICs also support control of rails via GPIOs.
This also includes the following to avoid further updates in follow-up
commits:
* On S2MPG10 and S2MPG11, external rail control can be via GPIO or via
non-GPIO signals, hence passing a GPIO is allowed to be optional.
This avoids inappropriate verbose driver messages.
* Prepare to allow use of standard DT property name 'enable-gpios' for
newer platforms instead of vendor-specific 'samsung,ext-control'.
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Link: https://patch.msgid.link/20260122-s2mpg1x-regulators-v7-15-3b1f9831fffd@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
For the upcoming S2MPG10 and S2MPG11 support, we need to be able to
parse -supply properties in the PMIC's DT node.
This currently doesn't work, because the code here currently points the
regulator core at each individual regulator sub-node, and therefore the
regulator core is unable to find the -supply properties.
Update the code to simply let the regulator core handle all the parsing
by adding the ::of_match and ::regulators_node members to all existing
regulator descriptions, by adding ::of_parse_cb() to those
regulators which support the vendor-specific samsung,ext-control-gpios
to parse it (S2MPS14), and by dropping the explicit call to
of_regulator_match().
Configuring the PMIC to respect the external control GPIOs via
s2mps14_pmic_enable_ext_control() is left outside ::of_parse_cb()
because the regulator core ignores errors other than -EPROBE_DEFER from
that callback, while the code currently fails probe on register write
errors and I believe it should stay that way.
The driver can now avoid the devm_gpiod_unhinge() dance due to
simpler error handling of GPIO descriptor acquisition.
This change also has the advantage of reducing runtime memory
consumption by quite a bit as the driver doesn't need to allocate a
'struct of_regulator_match' and a 'struct gpio_desc *' for each
regulator for all PMICs as the regulator core does that. This saves
40+8 bytes on arm64 for each individual regulator on all supported
PMICs (even on non-S2MPS14 due to currently unnecessarily allocating
the extra memory unconditionally). With the upcoming S2MPG10 and
S2MPG11 support, this amounts to 1640+328 and 1120+224 bytes
respectively.
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Link: https://patch.msgid.link/20260122-s2mpg1x-regulators-v7-14-3b1f9831fffd@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Higher voltage settings were unusable due to incorrect n_voltages values
causing registration failures. For example, setting aldo4 to 3.3V failed
with -EINVAL because the required selector (123) exceeded the allowed
range (n_voltages=117).
Fix by aligning n_voltages with the hardware register widths per the P1
datasheet [1]:
- BUCK: 255 (was 254), allows selectors 0-254, selector 255 is reserved
- LDO: 128 (was 117), allows selectors 0-127, selectors 0-10 are for
suspend mode, valid operational range is 11-127
This enables the full voltage range supported by the hardware.
Fixes: 8b84d712ad ("regulator: spacemit: support SpacemiT P1 regulators")
Link: https://developer.spacemit.com/documentation [1]
Signed-off-by: Guodong Xu <guodong@riscstar.com>
Link: https://patch.msgid.link/20260122-spacemit-p1-v1-1-309be27fbff9@riscstar.com
Signed-off-by: Mark Brown <broonie@kernel.org>
ROHM BD72720 is a power management IC which integrates 10 buck and 11 LDO
regulators. This PMIC has plenty of commonalities with the BD71828 and
BD71879.
The BD72720 does also have similar 'run-level'-concept as the BD71828 had.
It allows controlling the regulator's 'en masse', although only BUCK1
and LDO1 can utilize this in BD72720. Similar to BD71828, this 'en
masse' -control is not supported by this driver.
Support the voltage and enable/disable state control for the BD72720.
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
Link: https://patch.msgid.link/88b82128648516d9dbb173044042f2a7a5dfdf1c.1765804226.git.mazziesaccount@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
The new ROHM BD72720 PMIC has similarities with the BD71828. It makes
sense to support the regulator control for both PMICs using the same
driver. It is often more clear to have the IC specific functions and
globals named starting with the chip-name. So, as a preparatory step,
prefix the BD71828 specific functions and globals with the bd71828.
It would be tempting to try also removing the chip ID from those
functions which will be common for both PMICs. I have bad experiences on
this as it tends to lead to problems when yet another IC is being
supported with the same driver, and we will have some functions used for
all, some for two of the three, and some for just one. At this point
I used to start inventing wildcards like BD718XX or BD7272X. This
approach is pretty much always failing as we tend to eventually have
something like BD73900 - where all the wildcard stuff will break down.
So, my approach these days is to:
- keep the original chip-id prefix for anything that had it already
(and avoid the churn).
- use same prefix for all things that are used by multiple ICs -
typically the chip-ID of the first chip. This typically matches also
the driver and file names.
- use specific chip-ID as a prefix for anything which is specific to
just one chip.
As a preparatory step to adding the BD72720, add bd71828 prefix to all
commonly usable functions and globals.
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Acked-by: Mark Brown <broonie@kernel.org>
Link: https://patch.msgid.link/df5c98c6392c3b52cd41e3d98d60b65a1585b2dd.1765804226.git.mazziesaccount@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
Merge series from Andreas Kemnade <andreas@kemnade.info>:
Add a driver for the TPS65185 regulator which provides the
comparatively high voltages needed for electronic paper displays.
Datasheet for the TPS65185 is at https://www.ti.com/lit/gpn/tps65185
To simplify things, include the hwmon part directly which is only
one temperature sensor and there are no other functions besides regulators
in this chip.
When converting to faux_device the dummy_regulator_driver was
made non-static however it isn't exported or defined anywhere
outside the file it is in. Make it static to avoid the following
sparse warning:
drivers/regulator/dummy.c:59:24: warning: symbol 'dummy_regulator_driver' was not declared. Should it be static?
Fixes: dcd2a9a555 ("regulator: dummy: convert to use the faux device interface")
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Link: https://patch.msgid.link/20260112154909.601987-1-ben.dooks@codethink.co.uk
Signed-off-by: Mark Brown <broonie@kernel.org>
Add a driver for the TPS65185 regulator. Implement handling of the various
gpio pins. Because the PWRUP (=enable) pin functionality can be achieved
by just using two bits instead, just ensure that it is set to a stable
value.
Implement the pair of symmetric LDOs as a single regulator because they
share a single voltage set register. As the VCOM regulator sits behind that
machinery, just define that one as a supply.
For simplicity, just add the temperature sensor (depending on external NTC)
directly.
There is a mechanism to measure some kick-back voltage during a defined EPD
operation, to calibrate the VCOM voltage setting and store that
non-volatile in the chip to be the power up default setup. That is not
implemented yet in the driver, but that also means that there is a
non-factory default value in these registers after power-up.
Tested-by: Josua Mayer <josua.mayer@jm0.eu>
Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
Link: https://patch.msgid.link/20260102-tps65185-submit-v3-2-23bda35772f2@kemnade.info
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from André Draszik <andre.draszik@linaro.org>:
With these attached patches it becomes possible again to support
hardware designs with multiple PMICs where individual rails of each act
as required supplies for rails of the other (due to the latter being
e.g. always-on), and vice-versa.
Google Pixel 6 and 6 Pro (oriole and raven) are examples of such
designs.
Rather than returning -EPORBE_DEFER in regulator_register() when
set_machine_constraints() fails with -EPROBE_DEFER (due to missing
required supplies), we still allow rail registration and try to
reresolve supplies each time a new rail gets registered.
This is implemented using a bus (regulator bus), which allows the core
to reresolve supplies for regulators that still need them whenever new
regulators (i.e. devices) are added.
Using a bus also solves existing problems around late resolution of
supplies as mentioned in the commit message introducing that bus.
The series starts with a few bug fixes and the last two commits
implement the changes mentioned above, but do depend on the bug fixes.
Since commit 98e48cd928 ("regulator: core: resolve supply for
boot-on/always-on regulators"), the regulator core returns
-EPROBE_DEFER if a supply can not be resolved at regulator_register()
time due to set_machine_constraints() requiring that supply (e.g.
because of always-on or boot-on).
In some hardware designs, multiple PMICs are used where individual
rails of each act as supplies for rails of the other, and vice-versa.
In such a design no PMIC driver can probe when registering one top-
level regulator device (as is common practice for almost all regulator
drivers in Linux) since that commit. Supplies are only considered when
their driver has fully bound, but because in a design like the above
two drivers / devices depend on each other, neither will have fully
bound while the other probes. The Google Pixel 6 and 6 Pro (oriole and
raven) are examples of such a design.
One way to make this work would be to register each rail as an
individual device, rather than just one top-level regulator device.
Then, fw-devlink and Linux' driver core could do their usual handling
of deferred device probe as each rail would be probed individually.
This approach was dismissed in [1] as each regulator driver would have
to take care of this itself.
Alternatively, we can change the regulator core to not fail
regulator_register() if a rail's required supply can not be resolved
while keeping the intended change from above mentioned commit, and
instead retry whenever a new rail is registered. This commit implements
such an approach:
If set_machine_constraints() requests probe deferral,
regulator_register() still succeeds and we retry setting
constraints as part of regulator_resolve_supply().
We still do not enable the regulator or allow consumers to use it
until constraints have been set (including resolution of the
supply) to prevent enabling of a regulator before its supply.
With this change, we keep track of regulators with missing required
supplies and can therefore try to resolve them again and try to set
the constraints again once more regulators become available.
Care has to be taken to not allow consumers to use regulators that
haven't had their constraints set yet. regulator_get() ensures that
and now returns -EPROBE_DEFER in that case.
The implementation is straight-forward, thanks to our newly introduced
regulator-bus. Locking in regulator_resolve_supply() has to be done
carefully, as a combination of regulator_(un)lock_two() and
regulator_(un)lock_dependent() is needed. The reason is that
set_machine_constraints() might call regulator_enable() which needs
rdev and all its dependents locked, but everything else requires to
only have rdev and its supply locked.
Link: https://lore.kernel.org/all/aRn_-o-vie_QoDXD@sirena.co.uk/ [1]
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Link: https://patch.msgid.link/20260109-regulators-defer-v2-8-1a25dc968e60@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
When a regulator A and its supply B are provided by different devices,
the driver implementing B might be last to probe (with A still
pending resolution of its supply B). While we try to resolve all
pending supplies for all regulators (including A) during
regulator_register() of B via regulator_register_resolve_supply(),
supply resolution will still not work for A as the driver for B hasn't
finished binding to the PMIC device corresponding to B at that stage
yet. The regulator core explicitly only allows supplies from other
devices to be used once the relevant driver has fully bound, mainly to
avoid having to deal with cases where B itself might -EPROBE_DEFER.
In this case, A's supply will only be resolved as part of the core's
regulator_init_complete_work_function(), which currently is scheduled
to run after 30s. This was added as a work-around in
commit 3827b64dba ("regulator: core: Resolve supplies before
disabling unused regulators") to cover this situation.
There are two problems with that approach:
* it potentially runs long after all our consumers have probed
* an upcoming change will allow regulator_register() to complete
successfully even when required supplies (e.g. due to always-on or
boot-on) are missing at register time, deferring full configuration
of the regulator (and usability by consumers, i.e. usually consumer
probe) until the supply becomes available.
Resolving supplies in the late work func can therefore make it
impossible for consumers to probe at all, as the driver core will not
know to reprobe consumers when supplies have resolved.
We could schedule an earlier work to try to resolve supplies sooner,
but that'd be racy as consumers of A might try to probe before A's
supply gets fully resolved via this extra work.
Instead, add a very simple regulator bus and add a dummy device with a
corresponding driver to it for each regulator that is missing its
supply during regulator_register(). This way, the driver core will call
our bus' probe whenever a new (regulator) device was successfully
bound, allowing us to retry resolving the supply during (our bus) probe
and to bind this dummy device if successful. In turn this means the
driver core will see a newly bound device and retry probing of all
pending consumers, if any.
With that in place, we can avoid walking the full list of all known
regulators to try resolve missing supplies during regulator_register(),
as the driver core will invoke the bus probe for regulators that are
still pending their supplies. We can also drop the code trying to
resolve supplies one last time before unused regulators get disabled,
as all supplies should have resolved at that point in time, and if they
haven't then there's no point in trying again, as the outcome won't
change.
Note: We can not reuse the existing struct device created for each
rail, as a device can not be part of a class and a bus simultaneously.
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Link: https://patch.msgid.link/20260109-regulators-defer-v2-7-1a25dc968e60@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Receiving and forwarding critical supply events seems like they're
important information and we shouldn't ignore errors occurring during
registration for such events.
With this change the supply is unset on event registration failure,
allowing us to potentially retry another time.
Fixes: 433e294c3c ("regulator: core: forward undervoltage events downstream by default")
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Link: https://patch.msgid.link/20260109-regulators-defer-v2-6-1a25dc968e60@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Since commit 98e48cd928 ("regulator: core: resolve supply for
boot-on/always-on regulators") we require that a regulator's supply has
been resolved before enabling the regulator. Furthermore,
regulator_get() also fails if the supply hasn't been resolved yet
(preventing consumers from enabling a regulator without its supply
known). In combination this means that regulator_resolve_supply() now
always runs before the regulator has been enabled via
set_machine_constraints().
The code here was meant to run after enabling the regulator in case the
supply hadn't been resolved at that time and can therefore never
execute anymore since that commit.
Remove it.
No functional change intended.
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Link: https://patch.msgid.link/20260109-regulators-defer-v2-5-1a25dc968e60@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
For always-on and boot-on regulators, regulator_register() is currently
trying to anticipate the requirement to resolve a supply early.
Unfortunately, this code executes too early, before we have potentially
updated the regulator's always_on constraint as part of
set_machine_constraints(), causing it to miss cases.
Rather than trying to hack it more, just defer to the outcome of
set_machine_constraints(). The latter returns early (without doing any
regulator initialisation) with -EPROBE_DEFER as of commit 'regulator:
core: move supply check earlier in set_machine_constraints()' and is
therefore safe to call multiple times to determine if supplies need to
be resolved early.
Commit 8a866d527a ("regulator: core: Resolve supply name earlier to
prevent double-init") (later updated by
commit 520fb17821 ("regulator: core: Fix regulator supply
registration with sysfs")) added these tests originally to avoid
calling set_machine_constraints() multiple times to try to avoid
voltage glitches due to all the regulator initialisation happening each
time. This isn't an issue anymore as per above.
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Link: https://patch.msgid.link/20260109-regulators-defer-v2-4-1a25dc968e60@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Since commit 98e48cd928 ("regulator: core: resolve supply for
boot-on/always-on regulators"), set_machine_constraints() can return
-EPROBE_DEFER very late, after it has done a lot of work and
configuration of the regulator.
This means that configuration will happen multiple times for no
benefit in that case. Furthermore, this can lead to timing-dependent
voltage glitches as mentioned e.g. in commit 8a866d527a ("regulator:
core: Resolve supply name earlier to prevent double-init").
We can know that it's going to fail very early, in particular before
going through the complete regulator configuration by moving some code
around a little.
Do so to avoid re-configuring the regulator multiple times, also
avoiding the voltage glitches if we can.
Fixes: 98e48cd928 ("regulator: core: resolve supply for boot-on/always-on regulators")
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Link: https://patch.msgid.link/20260109-regulators-defer-v2-3-1a25dc968e60@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
If late enabling of a supply regulator fails in
regulator_resolve_supply(), the code currently triggers a lockdep
warning:
WARNING: drivers/regulator/core.c:2649 at _regulator_put+0x80/0xa0, CPU#6: kworker/u32:4/596
...
Call trace:
_regulator_put+0x80/0xa0 (P)
regulator_resolve_supply+0x7cc/0xbe0
regulator_register_resolve_supply+0x28/0xb8
as the regulator_list_mutex must be held when calling _regulator_put().
To solve this, simply switch to using regulator_put().
While at it, we should also make sure that no concurrent access happens
to our rdev while we clear out the supply pointer. Add appropriate
locking to ensure that.
While the code in question will be removed altogether in a follow-up
commit, I believe it is still beneficial to have this corrected before
removal for future reference.
Fixes: 36a1f1b6dd ("regulator: core: Fix memory leak in regulator_resolve_supply()")
Fixes: 8e5356a736 ("regulator: core: Clear the supply pointer if enabling fails")
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Link: https://patch.msgid.link/20260109-regulators-defer-v2-2-1a25dc968e60@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
1)
In print_constraints_debug(), the power budget is printed as:
lldo2: 450 <--> 1300 mV at 900 mV 2147483647 mW budge, enabled
(note the missing t in budget). This is because there is a --count just
below the call to scnprintf(), to make space for the comma. All similar
calls to scnprintf() above add an extra space to the format string to
allow for that, but this one doesn't, so the last character t is
stripped instead. Update the format string to fix the message.
2)
Add the name of the supply to the failure message printed when the
supply can not be resolved when debug messages are enabled to help with
debug.
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Link: https://patch.msgid.link/20260109-regulators-defer-v2-1-1a25dc968e60@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Add support for the Maxim Integrated MAX77675 PMIC regulator.
The MAX77675 is a compact, highly efficient SIMO (Single Inductor Multiple Output)
power management IC that provides four programmable buck-boost switching regulators
with only one inductor. It supports up to 700mA total output current and operates
from a single-cell Li-ion battery.
An integrated power-up sequencer and I2C interface allow flexible startup
configuration and runtime control.
Signed-off-by: Joan Na <joan.na@analog.com>
Link: https://patch.msgid.link/20251207032907.4850-3-joan.na@analog.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Pull regulator fixes from Mark Brown:
"A few fixes that came in during the merge window, nothing too
exciting - the one core fix improves error propagation from gpiolib
which hopefully shouldn't actually happen but is safer"
* tag 'regulator-fix-v6.19-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: spacemit: Align input supply name with the DT binding
regulator: fixed: Rely on the core freeing the enable GPIO
regulator: check the return value of gpiod_set_value_cansleep()
Pull regulator updates from Mark Brown:
"This is a relatively busy release for the regulator API, as well as a
good collection of new drivers we've got a little bit of core work and
a bunch of cleanup throughout the subsystem:
- Support for propagating undervoltage events to child regulators
- Undo enables done on supplies when setting enabling regulators via
constraints fails
- Pull in some gpiolib changes adding support for shared GPIOs to the
gpiolib core, using them to replace the open coded variant of this
that we've had in the regulator API for a long time
- Support for Fitipower FP9931 and JD9330, Mediatek MT6316, MT6363
and MT6373, NXP PF1550 and Qualcomm PMH01XX and PMCX0102
The PF1550 support was originally going to go via the MFD tree but
Krzysztof's cleanup work overlapped with it so I pulled in Lee's
signed tag with support for the device"
* tag 'regulator-v6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: (50 commits)
regulator: fp9931: Fix spelling mistake "failid" -> "failed"
regulator: core: Protect regulator_supply_alias_list with regulator_list_mutex
regulator: pf9453: Constify pointers to 'regulator_desc' wrap struct
regulator: pca9450: Constify pointers to 'regulator_desc' wrap struct
regulator: mt6358: Constify pointers to 'regulator_desc' wrap struct
regulator: bd96801: Constify pointers to 'regulator_desc' wrap struct
regulator: bd718x7: Constify pointers to 'regulator_desc' wrap struct
regulator: bd71828: Constify pointers to 'regulator_desc' wrap struct
regulator: bd71815: Constify pointers to 'regulator_desc' wrap struct
regulator: Use container_of_const() when all types are const
regulator: pca9450: Fix error code in probe()
regulator: qcomm-labibb: replace use of system_wq with system_dfl_wq
regulator: Add FP9931/JD9930 driver
dt-bindings: regulator: Add Fitipower FP9931/JD9930
dt-bindings: vendor-prefixes: Add Fitipower
regulator: make the subsystem aware of shared GPIOs
regulator: renesas-usb-vbus-regulator: Remove unused headers
regulator: pca9450: Add support for setting debounce settings
regulator: dt-bindings: pca9540: add debounce timer configuration
regulator: core: disable supply if enabling main regulator fails
...
