summaryrefslogtreecommitdiffstats
path: root/include/linux/regulator
Commit message (Collapse)AuthorAgeFilesLines
* regulator: Add (devm_)of_regulator_get()Sebastian Reichel2025-02-241-0/+6
| | | | | | | | | | | | | | | | | 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>
* Merge tag 'regulator-v6.14' of ↵Linus Torvalds2025-01-224-0/+26
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * regulator: Add support for power budgetKory Maincent2025-01-173-0/+25
| | | | | | | | | | | | | | | | | | | | 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>
| * regulator: pca9450: Add PMIC pca9452 supportJoy Zou2024-12-091-0/+1
| | | | | | | | | | | | | | | | | | 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>
* | regulator: Move OF_ API declarations/definitions outside CONFIG_REGULATORManivannan Sadhasivam2025-01-061-46/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: 27b9ecc7a9ba ("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>
* | regulator: Guard of_regulator_bulk_get_all() with CONFIG_OFManivannan Sadhasivam2025-01-061-8/+9
|/ | | | | | | | | | | | | | | | 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: 27b9ecc7a9ba ("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>
* regulator: doc: remove documentation comment for regulator_initJerome Brunet2024-10-231-2/+0
| | | | | | | | | | | | | | 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: 602ff58ae4fe ("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>
* regulator: doc: add missing documentation for init_cbJerome Brunet2024-10-231-0/+5
| | | | | | | | | | | | | | Add comment documenting introduced init_cb. This solves the following warning when building the kernel documentation: ./include/linux/regulator/driver.h:435: warning: Function parameter or struct member 'init_cb' not described in 'regulator_desc' Fixes: cfcdf395c21e ("regulator: core: add callback to perform runtime init") Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Closes: https://lore.kernel.org/lkml/20241023155120.6c4fea20@canb.auug.org.au/ Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Link: https://patch.msgid.link/20241023-regulator-doc-fixup-v1-1-ec018742ad73@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: init_data handling updateMark Brown2024-10-222-2/+3
|\ | | | | | | | | | | | | | | | | Merge series from Jerome Brunet <jbrunet@baylibre.com>: This patchset groups the regulator patches around the init_data topic discussed on pmbus write protect patchset [1] [1]: https://lore.kernel.org/r/20240920-pmbus-wp-v1-0-d679ef31c483@baylibre.com
| * regulator: core: remove machine init callback from configJerome Brunet2024-10-221-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * regulator: core: add callback to perform runtime initJerome Brunet2024-10-221-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | regulator: Add devres version of of_regulator_get_optional()Chen-Yu Tsai2024-09-301-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | regulator: Add of_regulator_get_optional() for pure DT regulator lookupChen-Yu Tsai2024-09-301-0/+20
|/ | | | | | | | | | | | | | | | | | | | | | | | 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>
* regulator: core: Stub devm_regulator_bulk_get_const() if !CONFIG_REGULATORDouglas Anderson2024-08-301-0/+8
| | | | | | | | | | | | | | | | | | | | 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: 1de452a0edda ("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>
* Add USB VBUS regulator for RZ/G2LMark Brown2024-06-261-0/+7
|\ | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * regulator: core: Add helper for allow HW access to enable/disable regulatorBiju Das2024-06-261-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* | regulator: consumer: Reorder fields in 'struct regulator_bulk_data'Christophe JAILLET2024-05-271-3/+3
|/ | | | | | | | | | | | | | | | | | | | | | | 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>
* Merge tag 'regulator-fix-v6.10-merge-window' of ↵Linus Torvalds2024-05-231-0/+3
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * regulator: pickable ranges: don't always cache vselMatti Vaittinen2024-05-201-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge tag 'regulator-v6.10' of ↵Linus Torvalds2024-05-142-0/+8
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 ...
| * regulator: new API for voltage reference suppliesMark Brown2024-05-061-0/+7
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| | * regulator: devres: add API for reference voltage suppliesDavid Lechner2024-05-031-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | regulator: pca9450: add pca9451a supportJoy Zou2024-03-251-0/+1
| |/ | | | | | | | | | | | | | | Adding support for new pmic pca9451a. Signed-off-by: Joy Zou <joy.zou@nxp.com> Link: https://msgid.link/r/20240318095633.4079027-3-joy.zou@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
* | regulator: change devm_regulator_get_enable_optional() stub to return OkMatti Vaittinen2024-04-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: da279e6965b3 ("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>
* | regulator: change stubbed devm_regulator_get_enable to return OkMatti Vaittinen2024-04-231-1/+1
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | 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: da279e6965b3 ("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>
* regulator: max8973: Finalize switch to GPIO descriptorsLinus Walleij2024-02-261-6/+0
| | | | | | | | | | | | | | | | | 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: Reuse LINEAR_RANGE() in REGULATOR_LINEAR_RANGE()Andy Shevchenko2023-12-191-6/+1
| | | | | | | | | | 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>
* regulator: event: Add regulator netlink event supportNaresh Solanki2023-12-061-46/+1
| | | | | | | | | | | | | 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>
* regulator: Implement uv_survival_time for handling under-voltage eventsOleksij Rempel2023-11-131-0/+8
| | | | | | | | | | | 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>
* regulator: Introduce handling for system-critical under-voltage eventsOleksij Rempel2023-11-131-0/+10
| | | | | | | | | 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>
* regulator: mt6358: Add missing regulators for MT6366Chen-Yu Tsai2023-10-021-0/+3
| | | | | | | | | | | | | | | | | | 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>
* regulator: db8500-prcmu: Remove unused declaration ↵Yue Haibing2023-08-181-6/+0
| | | | | | | | | | | power_state_active_is_enabled() Commit 38e968380b27 ("regulators/db8500: split off shared dbx500 code") removed this but not its declaration. Signed-off-by: Yue Haibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20230818124227.15084-1-yuehaibing@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: Use bitfield values for range selectorsChen-Yu Tsai2023-07-251-5/+6
| | | | | | | | | | | | | | | | | | | | | | | 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>
* Merge tag 'regulator-v6.5' of ↵Linus Torvalds2023-06-282-8/+4
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 ...
| * regulator: mt6358: Drop *_SSHUB regulatorsChen-Yu Tsai2023-06-141-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * regulator: mt6358: Merge VCN33_* regulatorsChen-Yu Tsai2023-06-141-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * regulator: expose regulator_find_closest_biggerSebastian Reichel2023-05-231-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | regulator: pca9450: Fix LDO3OUT and LDO4OUT MASKTeresa Remmet2023-06-191-2/+2
|/ | | | | | | | | | | L3_OUT and L4_OUT Bit fields range from Bit 0:4 and thus the mask should be 0x1F instead of 0x0F. Fixes: 0935ff5f1f0a ("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>
* regulator: core: Use different devices for resource allocation and DT lookupChiYuan Huang2022-12-081-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* regulator: add mt6357 regulatorFabien Parent2022-12-021-0/+51
| | | | | | | | | | 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>
* regulator: Add of_regulator_bulk_get_all()Mark Brown2022-11-181-0/+8
|\ | | | | | | | | | | | | | | | | 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.
| * regulator: Add of_regulator_bulk_get_allCorentin Labbe2022-11-181-0/+8
| | | | | | | | | | | | | | | | | | | | 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>
* | regulator: userspace-consumer: Handle regulator-output DT nodesZev Weiss2022-11-031-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | regulator: devres: Add devm_regulator_bulk_get_exclusive()Zev Weiss2022-11-031-0/+2
|/ | | | | | | | | | | | | | 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>
* regulator: gpio: Add input_supply support in gpio_regulator_configJerome Neanne2022-09-291-0/+2
| | | | | | | | | | | | | 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>
* MediaTek Helio X10 MT6795 - MT6331/6332 RegulatorsMark Brown2022-09-132-0/+73
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * regulator: Add driver for MT6332 PMIC regulatorsAngeloGioacchino Del Regno2022-09-131-0/+27
| | | | | | | | | | | | | | | | | | Add a driver for the regulators found in the MT6332 PMICs, including six buck and four LDO regulators. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20220913123456.384513-5-angelogioacchino.delregno@collabora.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * regulator: Add driver for MT6331 PMIC regulatorsAngeloGioacchino Del Regno2022-09-131-0/+46
| | | | | | | | | | | | | | | | | | Add a driver for the regulators found in the MT6331 PMIC. This PMIC features six buck and 21 Low DropOut (LDO) regulators. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20220913123456.384513-3-angelogioacchino.delregno@collabora.com Signed-off-by: Mark Brown <broonie@kernel.org>
* | regulator: Add devm helpers for get and enableMatti Vaittinen2022-08-181-0/+27
|/ | | | | | | | | | | | | A few regulator consumer drivers seem to be just getting a regulator, enabling it and registering a devm-action to disable the regulator at the driver detach and then forget about it. We can simplify this a bit by adding a devm-helper for this pattern. Add devm_regulator_get_enable() and devm_regulator_get_enable_optional() Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Link: https://lore.kernel.org/r/ed7b8841193bb9749d426f3cb3b199c9460794cd.1660292316.git.mazziesaccount@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: Consumer load management improvementsMark Brown2022-07-281-4/+12
|\ | | | | | | | | | | | | | | | | Merge series from Douglas Anderson <dianders@chromium.org>: The main goal of this series is to make a small dent in cleaning up the way we deal with regulator loads. The idea is to add some extra functionality to the regulator "bulk" API so that consumers can specify the load using that.
generated by cgit v1.2.3 (git 2.46.0) at 2025-04-24 12:51:03 +0000