In case of the MP5496 regulators, the driver uses the same name both for
the regulator and for its supply. Due to this, in some cases the supply
gets resolved to the regulator itself, and the regulator core code throwns
an error message.

For example, booting the kernel with the 'ipq9574-rdp433' device tree,
results in the following message in the log:

  [    1.710392] qcom_rpm_smd_regulator remoteproc:glink-edge:rpm-requests:regulators: Supply for s1 (s1) resolved to itself

Additionally, the driver uses different supply names for the 's2' and for
the 'l2' regulators which is incorrect. Here is the supply map based on the
datasheet of the MP5496:

  VIN1 -> Buck1
  VIN2 -> Buck2, LDO2, LDO3
  VIN3 -> Buck3
  VIN4 -> Buck4
  VIN5 -> LDO4, LDO5

This indicates that both 's2' (Buck2) and 'l2' (LDO2) are connected
to the same supply internally within the PMIC, so those should use
the same supply name.

Change the supply names according to the naming schema used by the other
regulators in the same driver to fix the above problems.

Although this breaks backward compatibility, but the risk of causing
issues is quite low because none of the in-kernel device tree sources
are defining supplies with the removed names.

Fixes: ad663ce67804 ("regulator: qcom_smd: Add LDO5 MP5496 regulator")
Fixes: 60bbee7db43b ("regulator: qcom_smd: Add MP5496 S1 regulator")
Fixes: 47894c859479 ("regulator: qcom_smd: Add MP5496 regulators")
Signed-off-by: Gabor Juhos <j4g8y7@gmail.com>
---
 drivers/regulator/qcom_smd-regulator.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/regulator/qcom_smd-regulator.c b/drivers/regulator/qcom_smd-regulator.c
index 25ed9f713974ba25058c9dbf38d36e88f70a940b..91bfea06b98682fca3c41f49ac127884143d282f 100644
--- a/drivers/regulator/qcom_smd-regulator.c
+++ b/drivers/regulator/qcom_smd-regulator.c
@@ -792,10 +792,10 @@ struct rpm_regulator_data {
 };
 
 static const struct rpm_regulator_data rpm_mp5496_regulators[] = {
-	{ "s1", QCOM_SMD_RPM_SMPA, 1, &mp5496_smps, "s1" },
-	{ "s2", QCOM_SMD_RPM_SMPA, 2, &mp5496_smps, "s2" },
-	{ "l2", QCOM_SMD_RPM_LDOA, 2, &mp5496_ldoa2, "l2" },
-	{ "l5", QCOM_SMD_RPM_LDOA, 5, &mp5496_ldoa2, "l5" },
+	{ "s1", QCOM_SMD_RPM_SMPA, 1, &mp5496_smps, "vdd_s1" },
+	{ "s2", QCOM_SMD_RPM_SMPA, 2, &mp5496_smps, "vdd_s2_l2_l3" },
+	{ "l2", QCOM_SMD_RPM_LDOA, 2, &mp5496_ldoa2, "vdd_s2_l2_l3" },
+	{ "l5", QCOM_SMD_RPM_LDOA, 5, &mp5496_ldoa2, "vdd_l4_l5" },
 	{}
 };
 

---
base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
change-id: 20251211-qcom_smd-mp5496-supply-fix-9086dad3cbc5

Best regards,
-- 
Gabor Juhos <j4g8y7@gmail.com>

On 12/16/25 7:38 PM, Gabor Juhos wrote:
> In case of the MP5496 regulators, the driver uses the same name both for
> the regulator and for its supply. Due to this, in some cases the supply
> gets resolved to the regulator itself, and the regulator core code throwns
> an error message.
> 
> For example, booting the kernel with the 'ipq9574-rdp433' device tree,
> results in the following message in the log:
> 
>   [    1.710392] qcom_rpm_smd_regulator remoteproc:glink-edge:rpm-requests:regulators: Supply for s1 (s1) resolved to itself
> 
> Additionally, the driver uses different supply names for the 's2' and for
> the 'l2' regulators which is incorrect. Here is the supply map based on the
> datasheet of the MP5496:
> 
>   VIN1 -> Buck1
>   VIN2 -> Buck2, LDO2, LDO3
>   VIN3 -> Buck3
>   VIN4 -> Buck4
>   VIN5 -> LDO4, LDO5

One thing this reveals is that there's an LDO3 and an LDO4 which
we don't describe today.. are they managed as power-domains, or
are there other other reasons?

Konrad

Hi Konrad,

2025. 12. 17. 11:30 keltezéssel, Konrad Dybcio írta:
> On 12/16/25 7:38 PM, Gabor Juhos wrote:
>> In case of the MP5496 regulators, the driver uses the same name both for
>> the regulator and for its supply. Due to this, in some cases the supply
>> gets resolved to the regulator itself, and the regulator core code throwns
>> an error message.
>>
>> For example, booting the kernel with the 'ipq9574-rdp433' device tree,
>> results in the following message in the log:
>>
>>   [    1.710392] qcom_rpm_smd_regulator remoteproc:glink-edge:rpm-requests:regulators: Supply for s1 (s1) resolved to itself
>>
>> Additionally, the driver uses different supply names for the 's2' and for
>> the 'l2' regulators which is incorrect. Here is the supply map based on the
>> datasheet of the MP5496:
>>
>>   VIN1 -> Buck1
>>   VIN2 -> Buck2, LDO2, LDO3
>>   VIN3 -> Buck3
>>   VIN4 -> Buck4
>>   VIN5 -> LDO4, LDO5
> 
> One thing this reveals is that there's an LDO3 and an LDO4 which
> we don't describe today.. 

The same is true for Buck3 and Buck4 too.

> are they managed as power-domains, or are there other other reasons?

Unfortunately, I don't know the exact reason.

I have no detailed hardware information about the reference boards, but it seems
that it depends on what is supported by the actual RPM firmware on the board.

For example, currently I have this RPM version on my IPQ9574 based board:

  # cat /sys/kernel/debug/qcom_socinfo/rpm/name
  03:RPM.BF.2.4.1-00116
  # cat /sys/kernel/debug/qcom_socinfo/rpm/oem
  CRM
  # cat /sys/kernel/debug/qcom_socinfo/rpm/variant
  CAAAANAAR

This version does not even support LDO5. At least, trying to use that results in
the following error:

  [    2.120281] l5: Bringing 0uV into 1800000-1800000uV
  [    2.127721] l5: failed to enable: -ENXIO

In this special case, the -ENXIO error code comes from qcom_smd_rpm_callback()
and it means that the resource does not exists.

So my guess is that the undescribed regulators are simply not used on the boards
supported currently.

Regards,
Gabor

On 12/17/25 9:32 PM, Gabor Juhos wrote:
> Hi Konrad,
> 
> 2025. 12. 17. 11:30 keltezéssel, Konrad Dybcio írta:
>> On 12/16/25 7:38 PM, Gabor Juhos wrote:
>>> In case of the MP5496 regulators, the driver uses the same name both for
>>> the regulator and for its supply. Due to this, in some cases the supply
>>> gets resolved to the regulator itself, and the regulator core code throwns
>>> an error message.
>>>
>>> For example, booting the kernel with the 'ipq9574-rdp433' device tree,
>>> results in the following message in the log:
>>>
>>>   [    1.710392] qcom_rpm_smd_regulator remoteproc:glink-edge:rpm-requests:regulators: Supply for s1 (s1) resolved to itself
>>>
>>> Additionally, the driver uses different supply names for the 's2' and for
>>> the 'l2' regulators which is incorrect. Here is the supply map based on the
>>> datasheet of the MP5496:
>>>
>>>   VIN1 -> Buck1
>>>   VIN2 -> Buck2, LDO2, LDO3
>>>   VIN3 -> Buck3
>>>   VIN4 -> Buck4
>>>   VIN5 -> LDO4, LDO5
>>
>> One thing this reveals is that there's an LDO3 and an LDO4 which
>> we don't describe today.. 
> 
> The same is true for Buck3 and Buck4 too.
> 
>> are they managed as power-domains, or are there other other reasons?
> 
> Unfortunately, I don't know the exact reason.

OK, so the bucks are all managed by RPM as power domains indeed

L[2345] are all defined

*but*

I don't quite know how this is all mapped - it may be that LDO2 is mapped
as "l1", but I'm really not sure

Konrad

> 
> I have no detailed hardware information about the reference boards, but it seems
> that it depends on what is supported by the actual RPM firmware on the board.
> 
> For example, currently I have this RPM version on my IPQ9574 based board:
> 
>   # cat /sys/kernel/debug/qcom_socinfo/rpm/name
>   03:RPM.BF.2.4.1-00116
>   # cat /sys/kernel/debug/qcom_socinfo/rpm/oem
>   CRM
>   # cat /sys/kernel/debug/qcom_socinfo/rpm/variant
>   CAAAANAAR
> 
> This version does not even support LDO5. At least, trying to use that results in
> the following error:
> 
>   [    2.120281] l5: Bringing 0uV into 1800000-1800000uV
>   [    2.127721] l5: failed to enable: -ENXIO
> 
> In this special case, the -ENXIO error code comes from qcom_smd_rpm_callback()
> and it means that the resource does not exists.
> 
> So my guess is that the undescribed regulators are simply not used on the boards
> supported currently.
> 
> Regards,
> Gabor