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] [day] [month] [year] [list]

Message-ID: <680d3b17-7983-4522-89b9-13ad67f4bfe4@oss.qualcomm.com>
Date: Wed, 17 Dec 2025 11:30:31 +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/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