Update header inclusions to follow IWYU (Include What You Use)
principle.
Note that kernel.h is discouraged to be included as it's written
at the top of that file.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20250626152307.322627-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
When restarting a CPU powered by the PCA9450 power management IC, it
is beneficial to use the PCA9450 to power cycle the CPU and all its
connected peripherals to start up in a known state. The PCA9450 features
a cold start procedure initiated by an I2C command.
Add a restart handler so that the PCA9450 is used to restart the CPU.
The restart handler sends command 0x14 to the SW_RST register,
initiating a cold reset (Power recycle all regulators except LDO1, LDO2
and CLK_32K_OUT)
As the PCA9450 is a PMIC specific for the i.MX8M family CPU, the restart
handler priority is set just slightly higher than imx2_wdt and the PSCI
restart handler. This makes sure this restart handler takes precedence.
Signed-off-by: Paul Geurts <paul.geurts@prodrive-technologies.com>
Link: https://patch.msgid.link/20250505115936.1946891-1-paul.geurts@prodrive-technologies.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The Rockchip power-domain controller also plans to make use of
per-domain regulators similar to the MediaTek power-domain controller.
Since existing DTs are missing the regulator information, the kernel
should fallback to the automatically created dummy regulator if
necessary. Thus the version without the _optional suffix is needed.
The Rockchip driver plans to use the managed version, but to be
consistent with existing code the unmanaged version is added at the
same time.
Tested-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Link: https://patch.msgid.link/20250220-rk3588-gpu-pwr-domain-regulator-v6-1-a4f9c24e5b81@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
This was a very quiet release, aside from some smaller improvements we
have:
- Support for power budgeting on regulators, initially targeted at some
still in review support for PSE controllers but generally useful.
- Support for error interrupts from ROHM BD96801 devices.
- Support for NXP PCA9452.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmeOYVoACgkQJNaLcl1U
h9D5tAf/RHg2j8OHQlTIjx8nebxIr8RRVmI5ltIlOA6biHsRzIHxOt7HjBaGTl78
qnpOJ8X+JUP5BP0F1n792e5f1HJykyIJA6nQnZfLIeUnLU2KsRPf1hJzDXgIvIoU
1cWuMe0j7oI0+DZYYY5G1AHw1n1J4M3HfXQyuWhfz1hlZTqBAWQSdkRyBp6Yyyth
m6XoAf72ADaKHB0GU6jbdNJJyO8D7rlwk0j6nlm0qoAIi52Se2ZeeJH707Wd/zGI
G3RF4MLkNUzOmzi3hJkhLILG5XwEQiu4pZGgOnYK6AdbxV8fWwq8PNzMqq/lb4Sl
A17Ib8eAPUPfVfUctAvx9DnGnaJKBw==
=Ttps
-----END PGP SIGNATURE-----
Merge tag 'regulator-v6.14' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator updates from Mark Brown:
"This was a very quiet release, aside from some smaller improvements we
have:
- Support for power budgeting on regulators, initially targeted at
some still in review support for PSE controllers but generally
useful
- Support for error interrupts from ROHM BD96801 devices
- Support for NXP PCA9452"
* tag 'regulator-v6.14' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: dt-bindings: Add regulator-power-budget-milliwatt property
regulator: Add support for power budget
regulator: core: Resolve supply using of_node from regulator_config
regulator: of: Implement the unwind path of of_regulator_match()
regulator: tps65219: Remove debugging helper function
regulator: tps65219: Remove MODULE_ALIAS
regulator: tps65219: Update driver name
regulator: tps65219: Use dev_err_probe() instead of dev_err()
regulator: dt-bindings: mt6315: Drop regulator-compatible property
regulator: pca9450: Add PMIC pca9452 support
regulator: dt-bindings: pca9450: Add pca9452 support
regulator: pca9450: Use dev_err_probe() to simplify code
regulator: pca9450: add enable_value for all bucks
regulator: bd96801: Add ERRB IRQ
Introduce power budget management for the regulator device. Enable tracking
of available power capacity by providing helpers to request and release
power budget allocations.
Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
Link: https://patch.msgid.link/20250115-feature_regulator_pw_budget-v2-1-0a44b949e6bc@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Since these are hidden inside CONFIG_REGULATOR, building the consumer
drivers without CONFIG_REGULATOR will result in the following build error:
>> drivers/pci/pwrctrl/slot.c:39:15: error: implicit declaration of
function 'of_regulator_bulk_get_all'; did you mean 'regulator_bulk_get'?
[-Werror=implicit-function-declaration]
39 | ret = of_regulator_bulk_get_all(dev, dev_of_node(dev),
| ^~~~~~~~~~~~~~~~~~~~~~~~~
| regulator_bulk_get
cc1: some warnings being treated as errors
This also removes the duplicated definitions that were possibly added to
fix the build issues.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202501020407.HmQQQKa0-lkp@intel.com/
Fixes: 27b9ecc7a9 ("regulator: Add of_regulator_bulk_get_all")
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://patch.msgid.link/20250104115058.19216-3-manivannan.sadhasivam@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Since the definition is in drivers/regulator/of_regulator.c and compiled
only if CONFIG_OF is enabled, building the consumer driver without
CONFIG_OF and with CONFIG_REGULATOR will result in below build error:
ERROR: modpost: "of_regulator_bulk_get_all" [drivers/pci/pwrctrl/pci-pwrctl-slot.ko] undefined!
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202412181640.12Iufkvd-lkp@intel.com/
Fixes: 27b9ecc7a9 ("regulator: Add of_regulator_bulk_get_all")
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Link: https://patch.msgid.link/20250104115058.19216-2-manivannan.sadhasivam@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Add the PMIC pca9452 support, which add ldo3 compared with pca9451a.
Signed-off-by: Joy Zou <joy.zou@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20241205-pca9450-v1-4-aab448b74e78@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Remove documentation comment related to regulator_init callback.
This solves the following warning when building the kernel documentation:
./include/linux/regulator/machine.h:290: warning: Excess struct member 'regulator_init' description in 'regulator_init_data'
Fixes: 602ff58ae4 ("regulator: core: remove machine init callback from config")
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Closes: https://lore.kernel.org/lkml/20241023155257.0fa7211d@canb.auug.org.au/
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Link: https://patch.msgid.link/20241023-regulator-doc-fixup-v1-2-ec018742ad73@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The machine specific regulator_init() appears to be unused.
It does not allow a lot of interaction with the regulator framework,
since nothing from the framework is passed along (desc, config,
etc ...)
Machine specific init may also be done with the added init_cb() in
the regulator description, so remove regulator_init().
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Link: https://patch.msgid.link/20241008-regulator-ignored-data-v2-3-d1251e0ee507@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Provide an initialisation callback to handle runtime parameters.
The idea is similar to the regulator_init() callback, but it provides
regulator specific structures, instead of just the driver specific data.
As an example, this allows the driver to amend the regulator constraints
based on runtime parameters if necessary.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Link: https://patch.msgid.link/20241008-regulator-ignored-data-v2-2-d1251e0ee507@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There are existing uses for a devres version of of_regulator_get_optional()
in power domain drivers. On MediaTek platforms, power domains may have
regulator supplies tied to them. The driver currently tries to use
devm_regulator_get() to not have to manage the lifecycle, but ends up
doing it in a very hacky way by replacing the device node of the power
domain controller device to the device node of the power domain that is
currently being registered, getting the supply, and reverting the device
node.
Provide a better API so that the hack can be replaced.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://patch.msgid.link/20240925093807.1026949-3-wenst@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The to-be-introduced I2C component prober needs to enable regulator
supplies (and toggle GPIO pins) for the various components it intends
to probe. To support this, a new "pure DT lookup" method for getting
regulator supplies is needed, since the device normally requesting
the supply won't get created until after the component is probed to
be available.
Add a new of_regulator_get_optional() function for this. This mirrors
the existing regulator_get_optional() function, but is OF-specific.
The underlying code that supports the existing regulator_get*()
functions has been reworked in previous patches to support this
specific case.
Also convert an existing usage of "dev && dev->of_node" to
"dev_of_node(dev)".
Link: https://lore.kernel.org/all/20231220203537.83479-2-jernej.skrabec@gmail.com/ [1]
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://patch.msgid.link/20240925093807.1026949-2-wenst@chromium.org
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
When adding devm_regulator_bulk_get_const() I missed adding a stub for
when CONFIG_REGULATOR is not enabled. Under certain conditions (like
randconfig testing) this can cause the compiler to reports errors
like:
error: implicit declaration of function 'devm_regulator_bulk_get_const';
did you mean 'devm_regulator_bulk_get_enable'?
Add the stub.
Fixes: 1de452a0ed ("regulator: core: Allow drivers to define their init data as const")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202408301813.TesFuSbh-lkp@intel.com/
Cc: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patch.msgid.link/20240830073511.1.Ib733229a8a19fad8179213c05e1af01b51e42328@changeid
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Biju Das <biju.das.jz@bp.renesas.com>:
As per RZ/G2L HW manual, VBUS enable can be controlled by the VBOUT bit of
the VBUS Control Register(VBENCTL) register in the USBPHY Control. But
this IP is in the Reset block.
Reset driver exposes this register as regmap and instantiate the USB VBUS
regulator device. Consumers(phy device) can use regulator APIs to control
VBUS as controlling is done in the atomic context using a new API which
is added for the purpose.
Add a helper function that allow regulator consumers to allow low-level
HW access, in order to enable/disable regulator in atomic context.
The use-case for RZ/G2L SoC is to enable VBUS selection register based
on vbus detection that happens in interrupt context.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Link: https://patch.msgid.link/20240616105402.45211-4-biju.das.jz@bp.renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Based on pahole, 2 holes can be combined in 'struct regulator_bulk_data'.
On x86_64 and allmodconfig, this shrinks the size of the structure from 32
to 24 bytes.
This is usually a win, because this structure is often used for static
global variables.
As an example:
Before:
text data bss dec hex filename
3557 162 0 3719 e87 drivers/gpu/drm/msm/dsi/dsi_cfg.o
After:
text data bss dec hex filename
3477 162 0 3639 e37 drivers/gpu/drm/msm/dsi/dsi_cfg.o
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://msgid.link/r/35c4edf2dbc6d4f24fb771341ded2989ae32f779.1715512259.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Mark Brown <broonie@kernel.org>
A bunch of fixes that came in during the merge window, Matti found
several issues with some of the more complexly configured Rohm
regulators and the helpers they use and there were some errors in the
specification of tps6594 when regulators are grouped together.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmZPLEoACgkQJNaLcl1U
h9DNfQf7B5ppKeMfWEzJKGywWmmzG96AldSvl7rcMyFxdzXjFu/kptGO0tLkJwTs
DnlZF6TBooB/RezoHhVgq6nLtJcowQPlbhM3Y4gujzvumZiJ2k2Chsyy+H0YRvkZ
kC9Bb2VGk7v5PimZiSugwgc1ZF+AE3LsZyzwWo4d0LZxOE1EyeQQ3SzygoKXtqzF
QJxsT6+ynaeYBxVwW+pHztWca8b3o+kqNLauxcWb0J0sPJPu/dl2PIQrKIZBsOWC
E34Y8MrrktqPApGE7kVL7dkmofceZI7Qv71aq2UJvRJOhvWP47f2L7nYwYi3kuIH
EjioQuqa1Bf7Wms59Q68WLjn4e0ILA==
=NeiV
-----END PGP SIGNATURE-----
Merge tag 'regulator-fix-v6.10-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator fixes from Mark Brown:
"A bunch of fixes that came in during the merge window.
Matti found several issues with some of the more complexly configured
Rohm regulators and the helpers they use and there were some errors in
the specification of tps6594 when regulators are grouped together"
* tag 'regulator-fix-v6.10-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: tps6594-regulator: Correct multi-phase configuration
regulator: tps6287x: Force writing VSEL bit
regulator: pickable ranges: don't always cache vsel
regulator: rohm-regulator: warn if unsupported voltage is set
regulator: bd71828: Don't overwrite runtime voltages
Some PMICs treat the vsel_reg same as apply-bit. Eg, when voltage range
is changed, the new voltage setting is not taking effect until the vsel
register is written.
Add a flag 'range_applied_by_vsel' to the regulator desc to indicate this
behaviour and to force the vsel value to be written to hardware if range
was changed, even if the old selector was same as the new one.
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Link: https://msgid.link/r/ZktCpcGZdgHWuN_L@fedora
Signed-off-by: Mark Brown <broonie@kernel.org>
There's one API update here, a new API factoring out a common pattern
for reference voltage supplies. These are supplies uses as a reference
by analogue circuits where the consumer requests and enables the supply,
reads the voltage to calibrate the user and then never touches it again.
This is factored out into a single operation which just returns the
voltage and uses devm_ to manage the request and enable portion.
Otherwise this has been a very quiet release, we've got some new device
support, some small fixes, housekeeping and cleanup work but nothing
substantial.
There's also some non-regulator changes in here, a number of users for
the new reference voltage API were merged along with it and some MFD
changes were pulled in as dependencies for new driver work.
Highlights:
- Add a new API for single operation handling of reference voltages.
- Support for Allwinner AXP717 and D1, and NXP PCA9561A.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmZB3mMACgkQJNaLcl1U
h9DRmAf9Etp/ydeKGrbYD4K34Ptk4ZwchkTfvPEiNmJEDBlbcazRoeCF9asUVsDR
ByggQCahCWhEa+exT+IBQYswpwFRd1oZChSgGUmIS/7pvQDdaPL+53Fnw8SfzmdS
QygBEMNN8TGIu2Y+OqEEqINJ407NLbv2SbIlFX1CywZ5hDvCtvFdqhX/xCxTedBN
wXlyj2BLe/xmbTGxr3Ssb+l8a0oe1BZvLO6ddrg8DtS92l1zJ0sEk+fegHSQGPRI
wI4QehjEgphBsoGhybMGz3ny0nvSs3JkpgRiG/ly3cT97Cx6KSGctMtqjmy7Ynh5
TM3Qq5DS37pBKIm79zmQFbL1z2A9Bw==
=wV3x
-----END PGP SIGNATURE-----
Merge tag 'regulator-v6.10' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator updates from Mark Brown:
"There's one API update here, a new API factoring out a common pattern
for reference voltage supplies. These are supplies used as a reference
by analogue circuits where the consumer requests and enables the
supply, reads the voltage to calibrate the user and then never touches
it again. This is factored out into a single operation which just
returns the voltage and uses devm_ to manage the request and enable
portion.
Otherwise this has been a very quiet release, we've got some new
device support, some small fixes, housekeeping and cleanup work but
nothing substantial.
There's also some non-regulator changes in here, a number of users for
the new reference voltage API were merged along with it and some MFD
changes were pulled in as dependencies for new driver work.
Highlights:
- Add a new API for single operation handling of reference voltages
- Support for Allwinner AXP717 and D1, and NXP PCA9561A"
* tag 'regulator-v6.10' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: (33 commits)
regulator: sun20i: Add Allwinner D1 LDOs driver
regulator: dt-bindings: Add Allwinner D1 system LDOs
regulator: Mention regulator id in error message about dummy supplies
staging: iio: impedance-analyzer: ad5933: Use devm_regulator_get_enable_read_voltage()
iio: frequency: admv1013: Use devm_regulator_get_enable_read_voltage()
iio: addac: ad74115: Use devm_regulator_get_enable_read_voltage()
hwmon: (adc128d818) simplify final return in probe
regulator: devres: fix devm_regulator_get_enable_read_voltage() return
hwmon: (da9052) Use devm_regulator_get_enable_read_voltage()
hwmon: (adc128d818) Use devm_regulator_get_enable_read_voltage()
regulator: devres: add API for reference voltage supplies
regulator: rtq2208: Fix LDO discharge register and add vsel setting
regulator: dt-bindings: fixed-regulator: Add a preferred node name
regulator: axp20x: add support for the AXP717
mfd: axp20x: Add support for AXP717 PMIC
dt-bindings: mfd: x-powers,axp152: Document AXP717
regulator: axp20x: fix typo-ed identifier
dt-bindings: regulator: qcom,usb-vbus-regulator: Add PM7250B compatible
regulator: pca9450: add pca9451a support
regulator: dt-bindings: pca9450: add pca9451a support
...
Merge series from David Lechner <dlechner@baylibre.com>:
In the IIO subsystem, we noticed a pattern in many drivers where we need
to get, enable and get the voltage of a supply that provides a reference
voltage. In these cases, we only need the voltage and not a handle to
the regulator. Another common pattern is for chips to have an internal
reference voltage that is used when an external reference is not
available. There are also a few drivers outside of IIO that do the same.
So we would like to propose a new regulator consumer API to handle these
specific cases to avoid repeating the same boilerplate code in multiple
drivers.
As an example of how these functions are used, I have included a few
patches to consumer drivers. But to avoid a giant patch bomb, I have
omitted the iio/adc and iio/dac patches I have prepared from this
series. I will send those separately but these will add 36 more users
of devm_regulator_get_enable_read_voltage() in addition to the 6 here.
In total, this will eliminate nearly 1000 lines of similar code and will
simplify writing and reviewing new drivers in the future.
A common use case for regulators is to supply a reference voltage to an
analog input or output device. This adds a new devres API to get,
enable, and get the voltage in a single call. This allows eliminating
boilerplate code in drivers that use reference supplies in this way.
Signed-off-by: David Lechner <dlechner@baylibre.com>
Link: https://lore.kernel.org/r/20240429-regulator-get-enable-get-votlage-v2-1-b1f11ab766c1@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The devm_regulator_get_enable_optional() should be a 'call and forget'
API, meaning, when it is used to enable the regulators, the API does not
provide a handle to do any further control of the regulators. It gives
no real benefit to return an error from the stub if CONFIG_REGULATOR is
not set.
On the contrary, returning an error is causing problems to drivers when
hardware is such it works out just fine with no regulator control.
Returning an error forces drivers to specifically handle the case where
CONFIG_REGULATOR is not set, making the mere existence of the stub
questionalble.
Change the stub implementation for the
devm_regulator_get_enable_optional() to return Ok so drivers do not
separately handle the case where the CONFIG_REGULATOR is not set.
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Fixes: da279e6965 ("regulator: Add devm helpers for get and enable")
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/ZiedtOE00Zozd3XO@fedora
Signed-off-by: Mark Brown <broonie@kernel.org>
The devm_regulator_get_enable() should be a 'call and forget' API,
meaning, when it is used to enable the regulators, the API does not
provide a handle to do any further control of the regulators. It gives
no real benefit to return an error from the stub if CONFIG_REGULATOR is
not set.
On the contrary, returning and error is causing problems to drivers when
hardware is such it works out just fine with no regulator control.
Returning an error forces drivers to specifically handle the case where
CONFIG_REGULATOR is not set, making the mere existence of the stub
questionalble. Furthermore, the stub of the regulator_enable() seems to
be returning Ok.
Change the stub implementation for the devm_regulator_get_enable() to
return Ok so drivers do not separately handle the case where the
CONFIG_REGULATOR is not set.
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Reported-by: Aleksander Mazur <deweloper@wp.pl>
Suggested-by: Guenter Roeck <linux@roeck-us.net>
Fixes: da279e6965 ("regulator: Add devm helpers for get and enable")
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/ZiYF6d1V1vSPcsJS@drtxq0yyyyyyyyyyyyyby-3.rev.dnainternet.fi
Signed-off-by: Mark Brown <broonie@kernel.org>
The dvs gpio was still using a legacy number passed from the
platform data. There are no in-tree users of the platform data
so just switch it to a gpio descriptor and obtain it in probe(),
the device tree users will work just as fine with this.
Drop the entirely unused enable_gpio from the platform data
as well. The device tree bindings mentions this but the driver
does not look for it and makes no use of it: it should probably
be implemented properly in a separate patch.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://msgid.link/r/20240220-descriptors-regulators-v1-1-097f608694be@linaro.org
Acked-by: Lee Jones <lee@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
REGULATOR_LINEAR_RANGE() repeats what LINEAR_RANGE() provides.
Deduplicate the former by using the latter. No functional change
intended.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://msgid.link/r/20231219154012.2478688-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This commit introduces netlink event support to the regulator subsystem.
Changes:
- Introduce event.c and regnl.h for netlink event handling.
- Implement reg_generate_netlink_event to broadcast regulator events.
- Update Makefile to include the new event.c file.
Signed-off-by: Naresh Solanki <naresh.solanki@9elements.com>
Link: https://lore.kernel.org/r/20231205105207.1262928-1-naresh.solanki@9elements.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add 'uv_survival_time' field to regulation_constraints for specifying
survival time post critical under-voltage event. Update the regulator
notifier call chain and Device Tree property parsing to use this new
field, allowing a configurable timeout before emergency shutdown.
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Link: https://lore.kernel.org/r/20231026144824.4065145-6-o.rempel@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
Handle under-voltage events for crucial regulators to maintain system
stability and avoid issues during power drops.
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Link: https://lore.kernel.org/r/20231026144824.4065145-3-o.rempel@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
When support for the MT6366 PMIC regulators was added, it was assumed
that it had the same functionality as MT6358. In reality there are
differences. A few regulators have different ranges, or were renamed
and repurposed, or removed altogether.
Add the 3 regulators that were missing from the original submission.
These are added for completeness. VSRAM_CORE is not used in existing
projects. VM18 and VMDDR feed DRAM related consumers, and are not used
in-kernel.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Acked-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/20230928085537.3246669-11-wenst@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Right now the regulator helpers expect raw register values for the range
selectors. This is different from the voltage selectors, which are
normalized as bitfield values. This leads to a bit of confusion. Also,
raw values are harder to copy from datasheets or match up with them,
as datasheets will typically have bitfield values.
Make the helpers expect bitfield values, and convert existing users. The
field in regulator_desc is renamed to |linear_range_selectors_bitfield|.
This is intended to cause drivers added in the same merge window and
out-of-tree drivers using the incorrect variable and values to break,
preventing incorrect values being used on actual hardware and potentially
producing magic smoke.
Also include bitops.h explicitly for ffs(), and reorder the header include
statements. While at it, also replace module.h with export.h, since the
only use is EXPORT_SYMBOL_GPL.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20230714081408.274567-1-wenst@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
This release is almost all drivers, there's some small improvements in
the core but otherwise everything is updates to drivers, mostly the
addition of new ones.
There's also a bunch of changes pulled in from the MFD subsystem as
dependencies, Rockchip and TI core MFD code that the regulator drivers
depend on.
I've also yet again managed to put a SPI commit in the regulator tree, I
don't know what it is about those two trees (this for spi-geni-qcom).
- Support for Renesas RAA215300, Rockchip RK808, Texas Instruments
TPS6594 and TPS6287x, and X-Powers AXP15060 and AXP313a
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmSZkRUACgkQJNaLcl1U
h9A0bAf+IM6F/vTF7R/2NTlR3M/Z7HGinxK1oit6LuZfKnveaRRCEWvBVoZzZpjs
CzdWTPBWA2jyETzEqmX7gxYnxf2aaLieLEpKRZSh3uQd5OKmrizQDs5/OdaVUViK
/ytmqd/IFgFfwaI+az38CQlTf+dDyuJDB0OwlkEkoaxWjeiAh6INBh6xO9aKczoW
lFd0tOVQt1EcBKdB4tBJLTFIWWsG66xy9NZ018FrcA+bCmQVBvkbqcahayI5Q6Kw
m5H7cZuFbKV51AlyYMF/C4Lwhy1mOT166eRmSrgxBXCsqhpFeHYkJQkmumNd3gkQ
oSQPTZHqSblJA7Utw09mlT6r/xqL0Q==
=/f85
-----END PGP SIGNATURE-----
Merge tag 'regulator-v6.5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator updates from Mark Brown:
"This release is almost all drivers, there's some small improvements in
the core but otherwise everything is updates to drivers, mostly the
addition of new ones.
There's also a bunch of changes pulled in from the MFD subsystem as
dependencies, Rockchip and TI core MFD code that the regulator drivers
depend on.
I've also yet again managed to put a SPI commit in the regulator tree,
I don't know what it is about those two trees (this for
spi-geni-qcom).
Summary:
- Support for Renesas RAA215300, Rockchip RK808, Texas Instruments
TPS6594 and TPS6287x, and X-Powers AXP15060 and AXP313a"
* tag 'regulator-v6.5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: (43 commits)
regulator: Add Renesas PMIC RAA215300 driver
regulator: dt-bindings: Add Renesas RAA215300 PMIC bindings
regulator: ltc3676: Use maple tree register cache
regulator: ltc3589: Use maple tree register cache
regulator: helper: Document ramp_delay parameter of regulator_set_ramp_delay_regmap()
regulator: mt6358: Use linear voltage helpers for single range regulators
regulator: mt6358: Const-ify mt6358_regulator_info data structures
regulator: mt6358: Drop *_SSHUB regulators
regulator: mt6358: Merge VCN33_* regulators
regulator: dt-bindings: mt6358: Drop *_sshub regulators
regulator: dt-bindings: mt6358: Merge ldo_vcn33_* regulators
regulator: dt-bindings: pwm-regulator: Add missing type for "pwm-dutycycle-unit"
regulator: Switch two more i2c drivers back to use .probe()
spi: spi-geni-qcom: Do not do DMA map/unmap inside driver, use framework instead
soc: qcom: geni-se: Add interfaces geni_se_tx_init_dma() and geni_se_rx_init_dma()
regulator: tps6594-regulator: Add driver for TI TPS6594 regulators
regulator: axp20x: Add AXP15060 support
regulator: axp20x: Add support for AXP313a variant
dt-bindings: pfuze100.yaml: Add an entry for interrupts
regulator: stm32-pwr: Fix regulator disabling
...
L3_OUT and L4_OUT Bit fields range from Bit 0:4 and thus the
mask should be 0x1F instead of 0x0F.
Fixes: 0935ff5f1f ("regulator: pca9450: add pca9450 pmic driver")
Signed-off-by: Teresa Remmet <t.remmet@phytec.de>
Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Link: https://lore.kernel.org/r/20230614125240.3946519-1-t.remmet@phytec.de
Signed-off-by: Mark Brown <broonie@kernel.org>
The *_SSHUB regulators are actually alternate configuration interfaces
for their non *_SSHUB counterparts. They are not separate regulator
outputs. These registers are intended for the companion processor to
use to configure the power rails while the main processor is sleeping.
They are not intended for the main operating system to use.
Since they are not real outputs they shouldn't be modeled separately.
Remove them. Luckily no device tree actually uses them.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
Link: https://lore.kernel.org/r/20230609083009.2822259-5-wenst@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The VCN33_BT and VCN33_WIFI regulators are actually the same regulator,
having the same voltage setting and output pin. There are simply two
enable bits that are ORed together to enable the regulator.
Having two regulators representing the same output pin is misleading
from a design matching standpoint, and also error-prone in driver
implementations. If consumers try to set different voltages on either
regulator, the one set later would override the one set before. There
are ways around this, such as chaining them together and having the
downstream one act as a switch. But given there's only one output pin,
such a workaround doesn't match reality.
Remove the VCN33_WIFI regulator. During the probe phase, have the driver
sync the enable status of VCN33_WIFI to VCN33_BT. Also drop the suffix
so that the regulator name matches the pin name in the datasheet.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20230609083009.2822259-4-wenst@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Expose and document the table lookup logic used by
regulator_set_ramp_delay_regmap, so that it can be
reused for devices that cannot be configured via
regulator_set_ramp_delay_regmap.
Tested-by: Diederik de Haas <didi.debian@cknow.org> # Rock64, Quartz64 Model A + B
Tested-by: Vincent Legoll <vincent.legoll@gmail.com> # Pine64 QuartzPro64
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Link: https://lore.kernel.org/r/20230504173618.142075-11-sebastian.reichel@collabora.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Following by the below discussion, there's the potential UAF issue
between regulator and mfd.
https://lore.kernel.org/all/20221128143601.1698148-1-yangyingliang@huawei.com/
From the analysis of Yingliang
CPU A |CPU B
mt6370_probe() |
devm_mfd_add_devices() |
|mt6370_regulator_probe()
| regulator_register()
| //allocate init_data and add it to devres
| regulator_of_get_init_data()
i2c_unregister_device() |
device_del() |
devres_release_all() |
// init_data is freed |
release_nodes() |
| // using init_data causes UAF
| regulator_register()
It's common to use mfd core to create child device for the regulator.
In order to do the DT lookup for init data, the child that registered
the regulator would pass its parent as the parameter. And this causes
init data resource allocated to its parent, not itself. The issue happen
when parent device is going to release and regulator core is still doing
some operation of init data constraint for the regulator of child device.
To fix it, this patch expand 'regulator_register' API to use the
different devices for init data allocation and DT lookup.
Reported-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: ChiYuan Huang <cy_huang@richtek.com>
Link: https://lore.kernel.org/r/1670311341-32664-1-git-send-email-u0084500@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add regulator driver for the MT6357 PMIC.
Signed-off-by: Fabien Parent <fparent@baylibre.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com>
Link: https://lore.kernel.org/r/20221005-mt6357-support-v7-7-477e60126749@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Corentin Labbe <clabbe@baylibre.com>:
This adds a new regulator_bulk_get_all() which grab all supplies
properties in a DT node, for use in implementing generic handling
for things like MDIO PHYs where the physical standardisation of
the bus does not extend to power supplies.
It work exactly like regulator_bulk_get() but instead of working on a
provided list of names, it seek all consumers properties matching
xxx-supply.
Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
Link: https://lore.kernel.org/r/20221115073603.3425396-2-clabbe@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
In addition to adding some fairly simple OF support code, we make some
slight adjustments to the userspace-consumer driver to properly
support use with regulator-output hardware:
- We now do an exclusive get of the supply regulators so as to
prevent regulator_init_complete_work from automatically disabling
them.
- Instead of assuming that the supply is initially disabled, we now
query its state to determine the initial value of drvdata->enabled.
Signed-off-by: Zev Weiss <zev@bewilderbeest.net>
Link: https://lore.kernel.org/r/20221031233704.22575-4-zev@bewilderbeest.net
Signed-off-by: Mark Brown <broonie@kernel.org>
We had an exclusive variant of the devm_regulator_get() API, but no
corresponding variant for the bulk API; let's add one now. We add a
generalized version of the existing regulator_bulk_get() function that
additionally takes a get_type parameter and redefine
regulator_bulk_get() in terms of it, then do similarly with
devm_regulator_bulk_get(), and finally add the new
devm_regulator_bulk_get_exclusive().
Signed-off-by: Zev Weiss <zev@bewilderbeest.net>
Link: https://lore.kernel.org/r/20221031233704.22575-2-zev@bewilderbeest.net
Signed-off-by: Mark Brown <broonie@kernel.org>
This is simillar as fixed-regulator.
Used to extract regulator parent from the device tree.
Without that property used, the parent regulator can be shut down (if not an always on).
Thus leading to inappropriate behavior:
On am62-SP-SK this fix is required to avoid tps65219 ldo1 (SDMMC rail) to be shut down after boot completion.
Signed-off-by: Jerome Neanne <jneanne@baylibre.com>
Link: https://lore.kernel.org/r/20220929132526.29427-2-jneanne@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>:
In an effort to give some love to the apparently forgotten MT6795 SoC,
I am upstreaming more components that are necessary to support platforms
powered by this one apart from a simple boot to serial console.
This series adds support for the regulators found in MT6331 and MT6332
main/companion PMICs.
Adding support to each driver in each subsystem is done in different
patch series as to avoid spamming uninteresting patches to maintainers.
Tested on a MT6795 Sony Xperia M5 (codename "Holly") smartphone.
