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: <4h4wm5jja4wadh6bmbouuxjvoai6cokqqgxsl4kmhurvqnd7tu@y65y5pakijpq>
Date: Tue, 10 Sep 2024 12:20:21 -0500
From: Andrew Halaney <ahalaney@...hat.com>
To: "Kumar, Udit" <u-kumar1@...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

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?


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ