linux-stable.git/drivers/regulator, branch v6.12.4

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

2024-12-05T13:01:29+00:00

[ 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:24+00:00

[ 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:08+00:00

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:19+00:00

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:14+00:00

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:48+00:00

_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:08+00:00

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:07+00:00

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

regulator: core: fix the broken behavior of regulator_dev_lookup()

2024-09-11T14:39:01+00:00

The behavior of regulator_dev_lookup() for non-DT way has been broken
since the commit b8c325545714 ("regulator: Move OF-specific regulator
lookup code to of_regulator.c").

Before the commit, of_get_regulator() was used to get the regulator,
which returns NULL if the regulator is not found. So the regulator
will be looked up through regulator_lookup_by_name() if no matching
regulator is found in regulator_map_list.

However, currently, of_regulator_dev_lookup() is used to instead of
of_get_regulator(), but the variable 'r' is set to ERR_PTR(-ENODEV)
instead of NULL if the regulator is not found. In this case, if no
regulator is found in regulator_map_list, the variable 'r' is still
ERR_PTR(-ENODEV), So regulator_dev_lookup() returns the value of 'r'
directly instead of continuing to look up the regulator through
regulator_lookup_by_name().

Fixes: b8c325545714 ("regulator: Move OF-specific regulator lookup code to of_regulator.c")
Signed-off-by: Wei Fang 
Link: https://patch.msgid.link/20240911120338.526384-1-wei.fang@nxp.com
Signed-off-by: Mark Brown

regulator: Few constifications of static data

2024-09-11T10:20:37+00:00

Merge series from Krzysztof Kozlowski :

Few cleanups (safer code), built tested.  Last two patches should
probably be tested.