linux-kernel - Re: [PATCH RFC/RFT 1/2] arm64: dts: ti: k3-j784s4-evm: Mark tps659413 and children as bootph-all

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: <2f36c165-1ec5-4af9-a2aa-9484a38d87d3@ti.com>
Date: Wed, 11 Sep 2024 09:54:37 +0530
From: "Kumar, Udit" <u-kumar1@...com>
To: Andrew Halaney <ahalaney@...hat.com>
CC: Nishanth Menon <nm@...com>, Vignesh Raghavendra <vigneshr@...com>,
        Tero
 Kristo <kristo@...nel.org>, Rob Herring <robh@...nel.org>,
        Krzysztof
 Kozlowski <krzk+dt@...nel.org>,
        Conor Dooley <conor+dt@...nel.org>, Keerthy
	<j-keerthy@...com>,
        Neha Malcom Francis <n-francis@...com>,
        Eric Chanudet
	<echanude@...hat.com>,
        Enric Balletbo <eballetb@...hat.com>,
        <linux-arm-kernel@...ts.infradead.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, Manorit Chawdhry <m-chawdhry@...com>
Subject: Re: [PATCH RFC/RFT 1/2] arm64: dts: ti: k3-j784s4-evm: Mark tps659413
 and children as bootph-all

Hi Andrew,

On 9/10/2024 10:50 PM, Andrew Halaney wrote:
> On Sat, Sep 07, 2024 at 11:04:50AM GMT, Kumar, Udit wrote:
>> Thanks for your patch Andrew
>>
>>
>> On 9/7/2024 2:51 AM, Andrew Halaney wrote:
>>> In order for the MCU domain to access this PMIC and its children in
>>> u-boot SPL, the nodes need to be marked appropriately otherwise they
>>> are not seen by SPL.
>>>
>>> This is necessary if the MCU domain is to program the TPS6594 MCU ESM
>>> state machine, which is required to wire up the watchdog in a manner
>>> that will reset the board.
>>>
>>> Signed-off-by: Andrew Halaney <ahalaney@...hat.com>
>>> ---
>>>    arch/arm64/boot/dts/ti/k3-j784s4-evm.dts | 11 +++++++++++
>>>    1 file changed, 11 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts b/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
>>> index 6695ebbcb4d0..044a428136df 100644
>>> --- a/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
>>> +++ b/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
>>> @@ -642,6 +642,7 @@ eeprom@50 {
>>>    	};
>>>    	tps659413: pmic@48 {
>>> +		bootph-all;
>>>    		compatible = "ti,tps6594-q1";
>>>    		reg = <0x48>;
>>>    		system-power-controller;
>>> @@ -662,7 +663,10 @@ tps659413: pmic@48 {
>>>    		ldo4-supply = <&vsys_3v3>;
>>>    		regulators {
>>> +			bootph-all;
>>> +
>>>    			bucka12: buck12 {
>>> +				bootph-all;
>>
>> Add bootph in on regulator node should be enough,
>>
>> As I see SPL/u-boot does not need all nodes.
> Ahhh, I finally see now, all parents of a bootph-* node get that
> property. Makes sense.
>
> Would you rather see it in the regulators node, or all of the actual
> regulators (bucka12, buacka3... etc)?
>
> The former is all that's *needed* to get the PMIC ESM probing and
> programmed. The latter makes sense to me if we want to actual use the
> regulators in the future in that context... Doing just *one* of the
> regulators seems odd to me though, someone may want a different one,
> so if we describe one to SPL we may as well describe all.
>
> What are your thoughts?


For now, adding boothph for bucka12 regulator is enough

but other nodes may be needed in future so i suggest to keep in

all regulators nodes ( bucka12, buacka3... etc)


>