linux-kernel - Re: [PATCH] regulator: qcom_smd: change MP5496 supply names

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <fef5ab5e-8b41-4a50-87d7-cb5e4169ff4e@gmail.com>
Date: Wed, 17 Dec 2025 21:32:55 +0100
From: Gabor Juhos <j4g8y7@...il.com>
To: Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
 Liam Girdwood <lgirdwood@...il.com>, Mark Brown <broonie@...nel.org>,
 Varadarajan Narayanan <quic_varada@...cinc.com>,
 Devi Priya <quic_devipriy@...cinc.com>,
 Praveenkumar I <quic_ipkumar@...cinc.com>,
 Konrad Dybcio <konradybcio@...nel.org>,
 Kathiravan T <quic_kathirav@...cinc.com>
Cc: linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] regulator: qcom_smd: change MP5496 supply names

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