linux-kernel - RE: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC

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:
 <TY3PR01MB1134690F9D37E3BB4814D864386932@TY3PR01MB11346.jpnprd01.prod.outlook.com>
Date: Tue, 3 Sep 2024 13:45:04 +0000
From: Biju Das <biju.das.jz@...renesas.com>
To: Claudiu.Beznea <claudiu.beznea@...on.dev>, Ulf Hansson
	<ulf.hansson@...aro.org>
CC: "vkoul@...nel.org" <vkoul@...nel.org>, "kishon@...nel.org"
	<kishon@...nel.org>, "robh@...nel.org" <robh@...nel.org>,
	"krzk+dt@...nel.org" <krzk+dt@...nel.org>, "conor+dt@...nel.org"
	<conor+dt@...nel.org>, "p.zabel@...gutronix.de" <p.zabel@...gutronix.de>,
	"geert+renesas@...der.be" <geert+renesas@...der.be>, "magnus.damm@...il.com"
	<magnus.damm@...il.com>, "gregkh@...uxfoundation.org"
	<gregkh@...uxfoundation.org>, "mturquette@...libre.com"
	<mturquette@...libre.com>, "sboyd@...nel.org" <sboyd@...nel.org>, Yoshihiro
 Shimoda <yoshihiro.shimoda.uh@...esas.com>, "linux-phy@...ts.infradead.org"
	<linux-phy@...ts.infradead.org>, "devicetree@...r.kernel.org"
	<devicetree@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "linux-renesas-soc@...r.kernel.org"
	<linux-renesas-soc@...r.kernel.org>, "linux-usb@...r.kernel.org"
	<linux-usb@...r.kernel.org>, "linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "linux-clk@...r.kernel.org"
	<linux-clk@...r.kernel.org>, "linux-pm@...r.kernel.org"
	<linux-pm@...r.kernel.org>, Claudiu Beznea <claudiu.beznea.uj@...renesas.com>
Subject: RE: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC

Hi Claudiu,

> -----Original Message-----
> From: claudiu beznea <claudiu.beznea@...on.dev>
> Sent: Tuesday, September 3, 2024 1:57 PM
> Subject: Re: [PATCH 00/16] Add initial USB support for the Renesas RZ/G3S SoC
> 
> 
> 
> On 03.09.2024 15:37, Biju Das wrote:
> >
> >
> >> -----Original Message-----
> >> From: claudiu beznea <claudiu.beznea@...on.dev>
> >> Sent: Tuesday, September 3, 2024 1:26 PM
> >> To: Biju Das <biju.das.jz@...renesas.com>; Ulf Hansson
> >> <ulf.hansson@...aro.org>
> >> Cc: vkoul@...nel.org; kishon@...nel.org; robh@...nel.org;
> >> krzk+dt@...nel.org; conor+dt@...nel.org; p.zabel@...gutronix.de;
> >> geert+renesas@...der.be; magnus.damm@...il.com;
> >> gregkh@...uxfoundation.org; mturquette@...libre.com;
> >> sboyd@...nel.org; Yoshihiro Shimoda
> >> <yoshihiro.shimoda.uh@...esas.com>;
> >> linux-phy@...ts.infradead.org; devicetree@...r.kernel.org;
> >> linux-kernel@...r.kernel.org; linux- renesas-soc@...r.kernel.org;
> >> linux-usb@...r.kernel.org; linux-arm-kernel@...ts.infradead.org;
> >> linux- clk@...r.kernel.org; linux-pm@...r.kernel.org; Claudiu Beznea
> >> <claudiu.beznea.uj@...renesas.com>
> >> Subject: Re: [PATCH 00/16] Add initial USB support for the Renesas
> >> RZ/G3S SoC
> >>
> >>
> >>
> >> On 03.09.2024 15:00, Biju Das wrote:
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Biju Das <biju.das.jz@...renesas.com>
> >>>> Sent: Tuesday, September 3, 2024 12:07 PM
> >>>> To: Claudiu.Beznea <claudiu.beznea@...on.dev>; Ulf Hansson
> >>>> <ulf.hansson@...aro.org>
> >>>> Cc: vkoul@...nel.org; kishon@...nel.org; robh@...nel.org;
> >>>> krzk+dt@...nel.org; conor+dt@...nel.org; p.zabel@...gutronix.de;
> >>>> geert+renesas@...der.be; magnus.damm@...il.com;
> >>>> gregkh@...uxfoundation.org; mturquette@...libre.com;
> >>>> sboyd@...nel.org; Yoshihiro Shimoda
> >>>> <yoshihiro.shimoda.uh@...esas.com>;
> >>>> linux-phy@...ts.infradead.org; devicetree@...r.kernel.org;
> >>>> linux-kernel@...r.kernel.org; linux- renesas-soc@...r.kernel.org;
> >>>> linux-usb@...r.kernel.org; linux-arm-kernel@...ts.infradead.org;
> >>>> linux- clk@...r.kernel.org; linux-pm@...r.kernel.org; Claudiu
> >>>> Beznea <claudiu.beznea.uj@...renesas.com>
> >>>> Subject: RE: [PATCH 00/16] Add initial USB support for the Renesas
> >>>> RZ/G3S SoC
> >>>>
> >>>> Hi Claudiu,
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: claudiu beznea <claudiu.beznea@...on.dev>
> >>>>> Sent: Tuesday, September 3, 2024 12:00 PM
> >>>>> Subject: Re: [PATCH 00/16] Add initial USB support for the Renesas
> >>>>> RZ/G3S SoC
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 03.09.2024 13:31, Biju Das wrote:
> >>>>>>>> During boot clr USB PWR READY signal in TF-A.
> >>>>>>>> STR case, suspend set USB PWR READY signal in TF-A.
> >>>>>>>> STR case, resume clr USB PWR READY signal in TF-A.
> >>>>>>> As I said previously, it can be done in different ways. My point
> >>>>>>> was to let Linux set what it needs for all it's devices to work.
> >>>>>>> I think the way to go forward is a
> >>>>> maintainer decision.
> >>>>>>
> >>>>>> I agree, there can be n number of solution for a problem.
> >>>>>>
> >>>>>> Since you modelled system state signal (USB PWRRDY) as reset
> >>>>>> control signal, it is reset/DT maintainer's decision to say the
> >>>>>> final word whether this signal fits in reset
> >>>>> system framework or not?
> >>>>>
> >>>>> I was thinking:
> >>>>> 1/ Geert would be the best to say if he considers it OK to handle this
> >>>>>    in Linux
> >>>>
> >>>> I agree Geert is the right person for taking SYSTEM decisions,
> >>>> since the signal is used only during state transitions (Table
> >>>> 41.6.4 AWO to ALL_ON and 41.6.3 ALL_ON to AWO)
> >>>
> >>> One more info, as per [1], this USB PWRRDY signal setting to be before Linux kernel boots.
> >>
> >> The "controlled by" column mentions CA-55 on PWRRDY signal control
> >> line and it is b/w steps "DDR exits from retention mode" and  "clock
> >> start settings for system bus and peripheral modules". AFAICT, after DDR exists retention mode
> Linux is ready to run.
> >
> > DDR retention exit happens in TF-A and it jumps into reset code where it executes BL2 in TF_A. Bl2
> checks for warm or cold reset.
> > If it is warm reset, it sets required minimal clocks/resets and pass
> > the control to linux by calling the SMC callback handler. Which in turn calls resume(step 11-->14)
> path.
> 
> Is this from HW manual or some specific documentation? I'm referring at "resume" == "steps 11-->14"
> 
> >
> > Step 8, Cortex-A55 Exit from DDR retention mode (when using) Setting
> > for exiting form DDR retention mode Step 9, Cortex-A55 USB PHY PWRRDY
> > signal control (if use USB) SYS_USB_PWRRDY Step 10, Cortex-A55 PCIe
> > RST_RSM_B signal control (if use PCIe) SYS_PCIE_RST_RSM_B
> 
> Note *if use*: how does the TF-A know if USB/PCIe is used by Linux? The documentation mention to set
> it *if use*. Same note is on ALL_ON to VBATT transition documentation (namely "if using USB", "if
> using PCIe"). If TF-A will do this it should set this signals unconditionally. It will not be
> something wrong though. We don't know at the moment what this involves in terms of power consumption,
> if it means something...

IIUC,
The only information we have is,

"SYS_USB_PWRRDY and SYS_PCIE_RST_RSM_B are used when transition from ALL_ON to AWO (or from AWO to ALL_ON).
"When turning off USB PHY and PCIe PHY, if they are not controlled, PHY may break"

ALL_ON to AWO_MODE state transition: 
USB/PCIe are part of PD_ISOVCC power domain and before turning PD_ISOVCC to off,
we need to set USBPWRRDY signal.

AWO_MODE to ALL_ON state transition:

Turn on PD_ISOVCC first, then clr USBPWRRDY signal for USB usage in linux.

Maybe we need to ask hw team, exact usage of USBPWRRDY signal other than state transition.

Cheers,
Biju