kernel/linux.git/include/linux/regulator, branch v6.6.132

regulator: core: Stub devm_regulator_bulk_get_const() if !CONFIG_REGULATOR

2024-09-12T09:11:32+00:00

[ Upstream commit 1a5caec7f80ca2e659c03f45378ee26915f4eda2 ] 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 Closes: https://lore.kernel.org/oe-kbuild-all/202408301813.TesFuSbh-lkp@intel.com/ Cc: Neil Armstrong Signed-off-by: Douglas Anderson Link: https://patch.msgid.link/20240830073511.1.Ib733229a8a19fad8179213c05e1af01b51e42328@changeid Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

regulator: pickable ranges: don't always cache vsel

2024-06-12T09:12:48+00:00

[ Upstream commit f4f4276f985a5aac7b310a4ed040b47e275e7591 ] 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 Link: https://msgid.link/r/ZktCpcGZdgHWuN_L@fedora Signed-off-by: Mark Brown Stable-dep-of: 1ace99d7c7c4 ("regulator: tps6287x: Force writing VSEL bit") Signed-off-by: Sasha Levin

regulator: change devm_regulator_get_enable_optional() stub to return Ok

2024-05-17T10:01:59+00:00

[ Upstream commit ff33132605c1a0acea59e4c523cb7c6fabe856b2 ] 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 Fixes: da279e6965b3 ("regulator: Add devm helpers for get and enable") Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/ZiedtOE00Zozd3XO@fedora Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

regulator: change stubbed devm_regulator_get_enable to return Ok

2024-05-17T10:01:58+00:00

[ Upstream commit 96e20adc43c4f81e9163a5188cee75a6dd393e09 ] 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 Reported-by: Aleksander Mazur Suggested-by: Guenter Roeck Fixes: da279e6965b3 ("regulator: Add devm helpers for get and enable") Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/ZiYF6d1V1vSPcsJS@drtxq0yyyyyyyyyyyyyby-3.rev.dnainternet.fi Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

regulator: db8500-prcmu: Remove unused declaration power_state_active_is_enabled()

2023-08-18T12:58:05+00:00

Commit 38e968380b27 ("regulators/db8500: split off shared dbx500 code") removed this but not its declaration. Signed-off-by: Yue Haibing Link: https://lore.kernel.org/r/20230818124227.15084-1-yuehaibing@huawei.com Signed-off-by: Mark Brown

regulator: Use bitfield values for range selectors

2023-07-25T11:14:27+00:00

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 Link: https://lore.kernel.org/r/20230714081408.274567-1-wenst@chromium.org Signed-off-by: Mark Brown

Merge tag 'regulator-v6.5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator

2023-06-28T20:32:47+00:00

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: pca9450: Fix LDO3OUT and LDO4OUT MASK

2023-06-19T14:13:17+00:00

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 Reviewed-by: Frieder Schrempf Link: https://lore.kernel.org/r/20230614125240.3946519-1-t.remmet@phytec.de Signed-off-by: Mark Brown

regulator: mt6358: Drop *_SSHUB regulators

2023-06-14T13:25:46+00:00

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 Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: Matthias Brugger Link: https://lore.kernel.org/r/20230609083009.2822259-5-wenst@chromium.org Signed-off-by: Mark Brown

regulator: mt6358: Merge VCN33_* regulators

2023-06-14T13:25:45+00:00

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 Link: https://lore.kernel.org/r/20230609083009.2822259-4-wenst@chromium.org Signed-off-by: Mark Brown