summaryrefslogtreecommitdiff
path: root/include/linux/regulator
AgeCommit message (Collapse)Author
2024-10-23regulator: doc: remove documentation comment for regulator_initJerome Brunet
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>
2024-10-23regulator: doc: add missing documentation for init_cbJerome Brunet
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>
2024-10-22regulator: init_data handling updateMark Brown
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
2024-10-22regulator: core: remove machine init callback from configJerome Brunet
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>
2024-10-22regulator: core: add callback to perform runtime initJerome Brunet
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>
2024-09-30regulator: Add devres version of of_regulator_get_optional()Chen-Yu Tsai
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>
2024-09-30regulator: Add of_regulator_get_optional() for pure DT regulator lookupChen-Yu Tsai
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>
2024-08-30regulator: core: Stub devm_regulator_bulk_get_const() if !CONFIG_REGULATORDouglas Anderson
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>
2024-06-26Add USB VBUS regulator for RZ/G2LMark Brown
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.
2024-06-26regulator: core: Add helper for allow HW access to enable/disable regulatorBiju Das
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>
2024-05-27regulator: consumer: Reorder fields in 'struct regulator_bulk_data'Christophe JAILLET
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>
2024-05-23Merge tag 'regulator-fix-v6.10-merge-window' of ↵Linus Torvalds
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
2024-05-20regulator: pickable ranges: don't always cache vselMatti Vaittinen
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>
2024-05-14Merge tag 'regulator-v6.10' of ↵Linus Torvalds
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 ...
2024-05-06regulator: new API for voltage reference suppliesMark Brown
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.
2024-05-03regulator: devres: add API for reference voltage suppliesDavid Lechner
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>
2024-04-24regulator: change devm_regulator_get_enable_optional() stub to return OkMatti Vaittinen
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>
2024-04-23regulator: change stubbed devm_regulator_get_enable to return OkMatti Vaittinen
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>
2024-03-25regulator: pca9450: add pca9451a supportJoy Zou
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>
2024-02-26regulator: max8973: Finalize switch to GPIO descriptorsLinus Walleij
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>
2023-12-19regulator: Reuse LINEAR_RANGE() in REGULATOR_LINEAR_RANGE()Andy Shevchenko
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>
2023-12-06regulator: event: Add regulator netlink event supportNaresh Solanki
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>
2023-11-13regulator: Implement uv_survival_time for handling under-voltage eventsOleksij Rempel
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>
2023-11-13regulator: Introduce handling for system-critical under-voltage eventsOleksij Rempel
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>
2023-10-02regulator: mt6358: Add missing regulators for MT6366Chen-Yu Tsai
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>
2023-08-18regulator: db8500-prcmu: Remove unused declaration ↵Yue Haibing
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>
2023-07-25regulator: Use bitfield values for range selectorsChen-Yu Tsai
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>
2023-06-28Merge tag 'regulator-v6.5' of ↵Linus Torvalds
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 ...
2023-06-19regulator: pca9450: Fix LDO3OUT and LDO4OUT MASKTeresa Remmet
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>
2023-06-14regulator: mt6358: Drop *_SSHUB regulatorsChen-Yu Tsai
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>
2023-06-14regulator: mt6358: Merge VCN33_* regulatorsChen-Yu Tsai
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>
2023-05-23regulator: expose regulator_find_closest_biggerSebastian Reichel
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>
2022-12-08regulator: core: Use different devices for resource allocation and DT lookupChiYuan Huang
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>
2022-12-02regulator: add mt6357 regulatorFabien Parent
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>
2022-11-18regulator: Add of_regulator_bulk_get_all()Mark Brown
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.
2022-11-18regulator: Add of_regulator_bulk_get_allCorentin Labbe
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>
2022-11-03regulator: userspace-consumer: Handle regulator-output DT nodesZev Weiss
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>
2022-11-03regulator: devres: Add devm_regulator_bulk_get_exclusive()Zev Weiss
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>
2022-09-29regulator: gpio: Add input_supply support in gpio_regulator_configJerome Neanne
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>
2022-09-13MediaTek Helio X10 MT6795 - MT6331/6332 RegulatorsMark Brown
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.
2022-09-13regulator: Add driver for MT6332 PMIC regulatorsAngeloGioacchino Del Regno
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>
2022-09-13regulator: Add driver for MT6331 PMIC regulatorsAngeloGioacchino Del Regno
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>
2022-08-18regulator: Add devm helpers for get and enableMatti Vaittinen
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>
2022-07-28regulator: Consumer load management improvementsMark Brown
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.
2022-07-27regulator: core: Allow drivers to define their init data as constDouglas Anderson
Drivers tend to want to define the names of their regulators somewhere in their source file as "static const". This means, inevitable, that every driver out there open codes something like this: static const char * const supply_names[] = { "vcc", "vccl", }; static int get_regulators(struct my_data *data) { int i; data->supplies = devm_kzalloc(...) if (!data->supplies) return -ENOMEM; for (i = 0; i < ARRAY_SIZE(supply_names); i++) data->supplies[i].supply = supply_names[i]; return devm_regulator_bulk_get(data->dev, ARRAY_SIZE(supply_names), data->supplies); } Let's make this more convenient by doing providing a helper that does the copy. I have chosen to have the "const" input structure here be the exact same structure as the normal one passed to devm_regulator_bulk_get(). This is slightly inefficent since the input data can't possibly have anything useful for "ret" or consumer and thus we waste 8 bytes per structure. This seems an OK tradeoff for not introducing an extra structure. Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20220726103631.v2.6.I38fc508a73135a5c1b873851f3553ff2a3a625f5@changeid Signed-off-by: Mark Brown <broonie@kernel.org>
2022-07-27regulator: core: Allow specifying an initial load w/ the bulk APIDouglas Anderson
There are a number of drivers that follow a pattern that looks like this: 1. Use the regulator bulk API to get a bunch of regulators. 2. Set the load on each of the regulators to use whenever the regulators are enabled. Let's make this easier by just allowing the drivers to pass the load in. As part of this change we need to move the error printing in regulator_bulk_get() around; let's switch to the new dev_err_probe() to simplify it. Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20220726103631.v2.4.Ie85f68215ada39f502a96dcb8a1f3ad977e3f68a@changeid Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-28regulator: fix a kernel-doc warningMauro Carvalho Chehab
document n_ramp_values field at struct regulator_desc, in order to solve this warning: include/linux/regulator/driver.h:434: warning: Function parameter or member 'n_ramp_values' not described in 'regulator_desc' Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Link: https://lore.kernel.org/r/15efc16e878aa327aa2769023bcdf959a795f41d.1656409369.git.mchehab@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2022-05-03regulator: pca9450: Make I2C Level Translator configurablePer-Daniel Olsson
Make the I2C Level Translator included in PCA9450 configurable from devicetree. The reset state is off. By setting nxp,i2c-lt-enable, the I2C Level Translator will be enabled while in STANDBY or RUN state. Signed-off-by: Per-Daniel Olsson <perdo@axis.com> Signed-off-by: Rickard x Andersson <rickaran@axis.com> Link: https://lore.kernel.org/r/20220429072211.24957-2-rickaran@axis.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-04-04regulator: mt6366: Add support for MT6366 regulatorJohnson Wang
The MT6366 is a regulator found on boards based on MediaTek MT8186 and probably other SoCs. It is a so called pmic and connects as a slave to SoC using SPI, wrapped inside the pmic-wrapper. Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Johnson Wang <johnson.wang@mediatek.com> Link: https://lore.kernel.org/r/20220401080212.27383-2-johnson.wang@mediatek.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-01-11Merge tag 'regulator-v5.17' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator Pull regulator updates from Mark Brown: "This has been a fairly quiet release for the regulator API, the main thing has been the addition of helpers for interrupt handling from Matti Vaittinen. We do also have support for quite a few new devices. Summary: - Helpers for trivial interrupt notifications, making it easier for drivers to handle error interrupts. - Support for Dialog DA914x, Maxim MAX2008x, Qualcomm PM8826, PMG1100, and PM8450 and TI TPS68470" * tag 'regulator-v5.17' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: (30 commits) regulator: Add MAX20086-MAX20089 driver dt-bindings: regulators: Add bindings for Maxim MAX20086-MAX20089 regulator: qcom_smd: Align probe function with rpmh-regulator regulator: remove redundant ret variable regulator: qcom-labibb: OCP interrupts are not a failure while disabled regulator: dt-bindings: samsung,s5m8767: Move fixed string BUCK9 to 'properties' regulator: Introduce tps68470-regulator driver drivers/regulator: remove redundant ret variable regulator: fix bullet lists of regulator_ops comment regulator: Fix type of regulator-coupled-max-spread property regulator: maxim,max8973: Document interrupts property regulator: qcom-rpmh: Add support for PM8450 regulators regulator: qcom,rpmh: Add compatible for PM8450 regulator: da9121: Add DA914x binding info regulator: da9121: Remove erroneous compatible from binding regulator: da9121: Add DA914x support regulator: da9121: Prevent current limit change when enabled regulator: qcom-rpmh: Add PMG1110 regulators dt-bindings: regulator: Add compatible for pmg1110 regulator: qcom_spmi: Add pm8226 regulators ...