linux-kernel - Re: [PATCH v3 2/2] arm64: dts: qcom: qcs615-ride: Enable PMIC peripherals

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: <20241031115300700-0700.eberman@hu-eberman-lv.qualcomm.com>
Date: Thu, 31 Oct 2024 13:28:58 -0700
From: Elliot Berman <quic_eberman@...cinc.com>
To: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
CC: Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
        Tingguo Cheng
	<quic_tingguoc@...cinc.com>,
        <quic_fenglinw@...cinc.com>, <quic_tingweiz@...cinc.com>,
        <kernel@...cinc.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 v3 2/2] arm64: dts: qcom: qcs615-ride: Enable PMIC
 peripherals

On Mon, Oct 28, 2024 at 03:14:49PM +0200, Dmitry Baryshkov wrote:
> On Mon, Oct 28, 2024 at 02:09:45PM +0100, Konrad Dybcio wrote:
> > On 28.10.2024 10:41 AM, Dmitry Baryshkov wrote:
> > > On Mon, 28 Oct 2024 at 10:40, Tingguo Cheng <quic_tingguoc@...cinc.com> wrote:
> > >> On 10/28/2024 4:23 PM, Dmitry Baryshkov wrote:
> > >>> On Mon, Oct 28, 2024 at 04:03:25PM +0800, Tingguo Cheng wrote:
> > >>>> Enable PMIC and PMIC peripherals for qcs615-ride board.
> > >>>>
> > >>>> Signed-off-by: Tingguo Cheng <quic_tingguoc@...cinc.com>
> > >>>> ---
> > >>>>   arch/arm64/boot/dts/qcom/qcs615-ride.dts | 15 +++++++++++++++
> > >>>>   1 file changed, 15 insertions(+)
> > >>>>
> > >>>> diff --git a/arch/arm64/boot/dts/qcom/qcs615-ride.dts b/arch/arm64/boot/dts/qcom/qcs615-ride.dts
> > >>>> index ee6cab3924a6d71f29934a8debba3a832882abdd..37358f080827bbe4484c14c5f159e813810c2119 100644
> > >>>> --- a/arch/arm64/boot/dts/qcom/qcs615-ride.dts
> > >>>> +++ b/arch/arm64/boot/dts/qcom/qcs615-ride.dts
> > >>>> @@ -6,6 +6,7 @@
> > >>>>
> > >>>>   #include <dt-bindings/regulator/qcom,rpmh-regulator.h>
> > >>>>   #include "qcs615.dtsi"
> > >>>> +#include "pm8150.dtsi"
> > >>>>   / {
> > >>>>      model = "Qualcomm Technologies, Inc. QCS615 Ride";
> > >>>>      compatible = "qcom,qcs615-ride", "qcom,qcs615";
> > >>>> @@ -210,6 +211,20 @@ &rpmhcc {
> > >>>>      clocks = <&xo_board_clk>;
> > >>>>   };
> > >>>>
> > >>>> +&pon {
> > >>>> +    /delete-property/ mode-bootloader;
> > >>>> +    /delete-property/ mode-recovery;
> > >>>
> > >>> Why?
> > >> Because boot modes will be supported on PSCI module from another patch,
> > >> reboot-modes are required to remove from PMIC side.

I don't know why "required to remove" is here. We *could* continue to
program the SDAM from Linux.

That being said, I don't know that the firmware/bootloader from the
QCS615 Ride has the concept of "reboot to recovery" since it's not an
Android ecosystem. I'd let Tingguo comment on it.

> > 
> > Do we know whether the PSCI call does the same thing under the hood?
> 
> It might be writing to the SDAM. For example, SAR2130P also uses PM8150
> and, if I'm not mistaken, SDAM for reboot mode.
> 

Yes, PSCI does the same thing under the hood.

What is going here is that we have introduced the SYSTEM_RESET2 vendor
resets in some firmwares which run on boards that use PM8150. Based on
context here (IOW: I might be a little wrong on the details), I guess
QCS615 Ride is being added to Qualcomm Linux stack, which has newer
firmware that supports using the SYSTEM_RESET2 vendor resets.

IMO, we should move the mode-bootloader/mode-recovery properties out of
pm8150.dtsi and into the applicable board.dts. As Bjorn mentioned, the
interpretation of the cookie values is specific to the board's firmware,
not the the pmic*. Tingguo, can you submit patches to do that?

Regards,
Elliot

*: In general, the cookie values are consistent. Some values are only
applicable on automotive board or mobile board though (or IOT).