linux-kernel - Re: [PATCH 09/24] arm64: dts: qcom: glymur-crd: Add RPMH regulator rails

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: <079b0120-efe2-43f9-b31e-8d65f6d7859b@oss.qualcomm.com>
Date: Mon, 20 Oct 2025 13:53:32 +0200
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: Kamal Wadhwa <kamal.wadhwa@....qualcomm.com>
Cc: Pankaj Patil <pankaj.patil@....qualcomm.com>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konradybcio@...nel.org>, Rob Herring <robh@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Conor Dooley
 <conor+dt@...nel.org>, linux-arm-msm@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 09/24] arm64: dts: qcom: glymur-crd: Add RPMH regulator
 rails

On 10/15/25 5:40 PM, Kamal Wadhwa wrote:
> On Thu, Sep 25, 2025 at 01:01:56PM +0200, Konrad Dybcio wrote:
>> On 9/25/25 8:32 AM, Pankaj Patil wrote:
>>> From: Kamal Wadhwa <kamal.wadhwa@....qualcomm.com>
>>>
>>> Add RPMH regulator rails for Glymur CRD.
>>>
>>> Signed-off-by: Kamal Wadhwa <kamal.wadhwa@....qualcomm.com>
>>> Signed-off-by: Pankaj Patil <pankaj.patil@....qualcomm.com>
>>> ---
>>
>> [...]
>>
>>> +	regulators-1 {
>>> +		compatible = "qcom,pmcx0102-rpmh-regulators";
>>> +		qcom,pmic-id = "C_E0";
>>> +		vdd-s1-supply = <&vph_pwr>;
>>> +		vdd-s8-supply = <&vph_pwr>;
>>> +
>>> +		vreg_s1c_e0_0p3: smps1 {
>>> +			regulator-name = "vreg_s1c_e0_0p3";
>>> +			regulator-min-microvolt = <300000>;
>>> +			regulator-max-microvolt = <1200000>;
>>> +			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
>>> +		};
>>> +
>>> +		vreg_s8c_e0_0p3: smps8 {
>>> +			regulator-name = "vreg_s8c_e0_0p3";
>>> +			regulator-min-microvolt = <300000>;
>>> +			regulator-max-microvolt = <1200000>
>>
>> Both of these regulators, having no consumers, will be parked to 0.3 V
>> (the lower bound)
>>
>> There are other similar cases in this patch
> 
> Ok. I will remove the unused rails.
> But just wanted to let you know currently i have exposed all the rails that
> are allowed to be controlled from APPS, mostly these rails will be staying
> OFF if no clients in SW are there to vote on them.
> 
> But do note that some of the clients may be getting added as more features
> get added, as lot of these rails are not unused in the HW. The client driver
> just isnt enabled as of now.
> 
> So wanted to check if I should remove ALL rails that are unused in SW?
>  or
> Can i keep the ones for which clients will be getting added in near future.
> 
> (i would prefer the later option, if that is ok with you?)

Please keep them but restrict them to the actually useful range, not just
what the hardware can do.

Most of them are presumably hardwired to specific peripherals and need
e.g. 1.8 V
>> Does the board still boot with all the expected functionality with only
>> patches 1-9 applied?
> 
> No. just tested, it seems not able to boot properly with just 1-9 patches.
> is your concern about squashing of the patches?
> (just trying to understand)

Yes, all boards must boot and not regress at any point, including at the
introductory commit. Otherwise bisecting is impossible.

Konrad