blaster4385/linux-IllusionX/drivers/regulator, branch v6.12.10

regulator: axp20x: AXP717: set ramp_delay

2024-12-19T17:13:14Z

[ Upstream commit f07ae52f5cf6a5584fdf7c8c652f027d90bc8b74 ] AXP717 datasheet says that regulator ramp delay is 15.625 us/step, which is 10mV in our case. Add a AXP_DESC_RANGES_DELAY macro and update AXP_DESC_RANGES macro to expand to AXP_DESC_RANGES_DELAY with ramp_delay = 0 For DCDC4, steps is 100mv Add a AXP_DESC_DELAY macro and update AXP_DESC macro to expand to AXP_DESC_DELAY with ramp_delay = 0 This patch fix crashes when using CPU DVFS. Signed-off-by: Philippe Simons Tested-by: Hironori KIKUCHI Tested-by: Chris Morgan Reviewed-by: Chen-Yu Tsai Fixes: d2ac3df75c3a ("regulator: axp20x: add support for the AXP717") Link: https://patch.msgid.link/20241208124308.5630-1-simons.philippe@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

regulator: qcom-rpmh: Update ranges for FTSMPS525

2024-12-14T19:04:07Z

[ Upstream commit eeecf953d697cb7f0d916f9908a2b9f451bb2667 ] All FTSMPS525 regulators support LV and MV ranges; however, the boot loader firmware will determine which range to use as the device boots. Nonetheless, the driver cannot determine which range was selected, so hardcoding the ranges as either LV or MV will not cover all cases as it's possible for the firmware to select a range not supported by the driver's current hardcoded values. To this end, combine the ranges for the FTSMPS525s into one struct and point all regulators to the updated combined struct. This should work on all boards regardless of which range is selected by the firmware and more accurately caputres the capability of this regulator on a hardware level. Signed-off-by: Melody Olvera Reviewed-by: Dmitry Baryshkov Link: https://patch.msgid.link/20241112002645.2803506-1-quic_molvera@quicinc.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

regulator: rk808: Restrict DVS GPIOs to the RK808 variant only

2024-12-05T13:01:29Z

[ Upstream commit 0d214f27c0e3d9694284c95bac1502c2d247355b ] The rk808-regulator driver supports multiple PMIC variants from the Rockckip RK80x and RK81x series, but the DVS GPIOs are supported on the RK808 variant only, according to the DT bindings [1][2][3][4][5][6] and the datasheets for the supported PMIC variants. [7][8][9][10][11][12] Thus, change the probe path so the "dvs-gpios" property is checked for and its value possibly used only when the handled PMIC variant is RK808. There's no point in doing that on the other PMIC variants, because they don't support the DVS GPIOs, and it goes against the DT bindings to allow a possible out- of-place "dvs-gpios" property to actually be handled in the driver. This eliminates the following messages, emitted when the "dvs-gpios" property isn't found in the DT, from the kernel log on boards that actually don't use the RK808 variant, which may have provided a source of confusion: rk808-regulator rk808-regulator.2.auto: there is no dvs0 gpio rk808-regulator rk808-regulator.2.auto: there is no dvs1 gpio Furthermore, demote these kernel messages to debug messages, because they are useful during the board bringup phase only. Emitting them afterwards, on the boards that use the RK808 variant, but actually don't use the DVS0/1 GPIOs, clutters the kernel log a bit, while they provide no value and may actually cause false impression that some PMIC-related issues are present. [1] Documentation/devicetree/bindings/mfd/rockchip,rk805.yaml [2] Documentation/devicetree/bindings/mfd/rockchip,rk806.yaml [3] Documentation/devicetree/bindings/mfd/rockchip,rk808.yaml [4] Documentation/devicetree/bindings/mfd/rockchip,rk816.yaml [5] Documentation/devicetree/bindings/mfd/rockchip,rk817.yaml [6] Documentation/devicetree/bindings/mfd/rockchip,rk818.yaml [7] https://rockchip.fr/RK805%20datasheet%20V1.2.pdf [8] https://wmsc.lcsc.com/wmsc/upload/file/pdf/v2/lcsc/2401261533_Rockchip-RK806-1_C5156483.pdf [9] https://rockchip.fr/RK808%20datasheet%20V1.4.pdf [10] https://rockchip.fr/RK816%20datasheet%20V1.3.pdf [11] https://rockchip.fr/RK817%20datasheet%20V1.01.pdf [12] https://rockchip.fr/RK818%20datasheet%20V1.0.pdf Fixes: 11375293530b ("regulator: rk808: Add regulator driver for RK818") Reported-by: Diederik de Haas Signed-off-by: Dragan Simic Link: https://patch.msgid.link/9a415c59699e76fc7b88a2552520a4ca2538f44e.1728902488.git.dsimic@manjaro.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

regulator: qcom-smd: make smd_vreg_rpm static

2024-12-05T13:01:24Z

[ Upstream commit 18be43aca2c0ec475037923a8086d0a29fcc9d16 ] Since smd_vreg_rpm is used only in drivers/regulator/qcom_smd-regulator.c, make it static and fix the following sparse warning: drivers/regulator/qcom_smd-regulator.c:14:21: sparse: warning: symbol 'smd_vreg_rpm' was not declared. Should it be static? No functional changes intended. Fixes: 5df3b41bd6b5 ("regulator: qcom_smd: Keep one rpm handle for all vregs") Signed-off-by: Min-Hua Chen Reviewed-by: Dmitry Baryshkov Link: https://patch.msgid.link/20240926231038.31916-1-minhuadotchen@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

regulator: rk808: Add apply_bit for BUCK3 on RK809

2024-11-01T14:47:08Z

Currently, RK809's BUCK3 regulator is modelled in the driver as a configurable regulator with 0.5-2.4V voltage range. But the voltage setting is not actually applied, because when bit 6 of PMIC_POWER_CONFIG register is set to 0 (default), BUCK3 output voltage is determined by the external feedback resistor. Fix this, by setting bit 6 when voltage selection is set. Existing users which do not specify voltage constraints in their device trees will not be affected by this change, since no voltage setting is applied in those cases, and bit 6 is not enabled. Signed-off-by: Mikhail Rudenko Link: https://patch.msgid.link/20241017-rk809-dcdc3-v1-1-e3c3de92f39c@gmail.com Signed-off-by: Mark Brown

regulator: rtq2208: Fix uninitialized use of regulator_config

2024-10-25T13:10:19Z

Fix rtq2208 driver uninitialized use to cause kernel error. Fixes: 85a11f55621a ("regulator: rtq2208: Add Richtek RTQ2208 SubPMIC") Signed-off-by: ChiYuan Huang Link: https://patch.msgid.link/00d691cfcc0eae9ce80a37b62e99851e8fdcffe2.1729829243.git.cy_huang@richtek.com Signed-off-by: Mark Brown

regulator: sm5703: Remove because it is unused and fails to build

2024-09-13T18:08:14Z

This file does not compile because is missing. In KConfig, it depends on MFD_SM5703. Both MFD_SM5703 and the missing include rely on another patch that never got merged. The last iteration related to this patch is [1]. So remove this dead-code and undo commit e8858ba89ca3 ("regulator: sm5703-regulator: Add regulators support for SM5703 MFD") [1]: https://lore.kernel.org/lkml/20220423085319.483524-5-markuss.broks@gmail.com/ Signed-off-by: Christophe JAILLET Link: https://patch.msgid.link/0f5da91a05e7343d290c88e3c583b674cf6219ac.1725910247.git.christophe.jaillet@wanadoo.fr Signed-off-by: Mark Brown

regulator: Split up _regulator_get()

2024-09-13T16:39:48Z

_regulator_get() contains a lot of common code doing checks prior to the regulator lookup and housekeeping work after the lookup. Almost all the code could be shared with a OF-specific variant of _regulator_get(). Split out the common parts so that they can be reused. The OF-specific version of _regulator_get() will be added in a subsequent patch. No functional changes were made. Signed-off-by: Chen-Yu Tsai Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/20240911072751.365361-4-wenst@chromium.org Signed-off-by: Mark Brown

regulator: update some comments ([gs]et_voltage_vsel vs [gs]et_voltage_sel)

2024-09-13T13:57:08Z

Some comments here are referring to a non-existent regulator_ops::get_voltage_vsel() where ::get_voltage_sel() is meant, and similar for ::set_voltage_vsel() / ::set_voltage_sel(). Update the comments. Signed-off-by: André Draszik Link: https://patch.msgid.link/20240913-regulator-typos-v1-1-92781c93f638@linaro.org Signed-off-by: Mark Brown

regulator: max8973: Use irq_get_trigger_type() helper

2024-09-13T13:57:07Z

Use irq_get_trigger_type() to replace irq_get_irq_data() and then irqd_get_trigger_type(), if the irq data is NULL it will return 0. Signed-off-by: Jinjie Ruan Link: https://patch.msgid.link/20240913013503.3754712-1-ruanjinjie@huawei.com Signed-off-by: Mark Brown