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

Message-ID: <9b352f6a-0040-4efd-9971-45375036a16a@quicinc.com>
Date: Tue, 5 Nov 2024 15:47:30 +0800
From: Tingguo Cheng <quic_tingguoc@...cinc.com>
To: Elliot Berman <quic_eberman@...cinc.com>,
        Dmitry Baryshkov
	<dmitry.baryshkov@...aro.org>
CC: Konrad Dybcio <konrad.dybcio@....qualcomm.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 11/1/2024 4:28 AM, Elliot Berman wrote:
> 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.
Sure, we could continue to program the SDAM from Linux. Regarding PSCI 
and PMIC both are dealing with reboot-modes, we need to consider more.
> 
> 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.
> 
About mode-recovery:
pm8150.dtsi is originally designed for mobile/android devices in which 
reboot modes are managed by PMIC driver, that's why I think the modes 
are there in pm8150.dtsi.

About QCS615 Ride:
QCS615 Ride use a pmm6155au(that's a variant of pm8150) and it's a Linux 
system. But we involved pm8150.dtsi for "the meaning of variant". That's 
why the "recovery-mode" is there. Maybe we can treat this as a change 
for "the variant" as well(Only for QCS615 ride as Dmitry said).
>>>
>>> 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?
> 
Of course, Should we split the "moving modes out of pm8150.dtsi" into 
another patch series? Because there are some boards need to change and 
this patch series is for "Adds SPMI bus, PMIC and peripherals for qcs615".
> Regards,
> Elliot
> 
> *: In general, the cookie values are consistent. Some values are only
> applicable on automotive board or mobile board though (or IOT).
> 

-- 
Thank you & BRs
Tingguo