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: <e5910555-ace1-4abd-af09-136011cbe124@quicinc.com>
Date: Tue, 12 Nov 2024 17:42:47 +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/5/2024 3:47 PM, Tingguo Cheng wrote:
> 
> 
> 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).
>>
> 
update v4: 
https://lore.kernel.org/lkml/20241112-adds-spmi-pmic-peripherals-for-qcs615-v4-0-f0e54d8b6516@quicinc.com/

-- 
Thank you & BRs
Tingguo