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 for Android: free password hash cracker in your pocket

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

Message-ID: <eaa41986-eaec-4953-8103-e8f83d90b1ed@oss.qualcomm.com>
Date: Thu, 18 Dec 2025 14:27:36 +0100
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: Gabor Juhos <j4g8y7@...il.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

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