user/sven/linux.git/include/linux/regulator, branch v6.7.2

regulator: mt6358: Add missing regulators for MT6366

2023-10-02T18:43:49Z

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 Reviewed-by: AngeloGioacchino Del Regno Acked-by: Lee Jones Link: https://lore.kernel.org/r/20230928085537.3246669-11-wenst@chromium.org Signed-off-by: Mark Brown

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

2023-08-18T12:58:05Z

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:27Z

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:47Z

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:17Z

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:46Z

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:45Z

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

regulator: expose regulator_find_closest_bigger

2023-05-23T18:01:55Z

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 # Rock64, Quartz64 Model A + B Tested-by: Vincent Legoll # Pine64 QuartzPro64 Signed-off-by: Sebastian Reichel Link: https://lore.kernel.org/r/20230504173618.142075-11-sebastian.reichel@collabora.com Signed-off-by: Mark Brown

regulator: core: Use different devices for resource allocation and DT lookup

2022-12-08T13:02:37Z

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 Signed-off-by: ChiYuan Huang Link: https://lore.kernel.org/r/1670311341-32664-1-git-send-email-u0084500@gmail.com Signed-off-by: Mark Brown

regulator: add mt6357 regulator

2022-12-02T12:23:19Z

Add regulator driver for the MT6357 PMIC. Signed-off-by: Fabien Parent Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Alexandre Mergnat Link: https://lore.kernel.org/r/20221005-mt6357-support-v7-7-477e60126749@baylibre.com Signed-off-by: Mark Brown