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: <91916297-8156-44d9-b56f-9a67e651a9a4@tuxon.dev>
Date: Thu, 7 Nov 2024 12:00:05 +0200
From: Claudiu Beznea <claudiu.beznea@...on.dev>
To: Biju Das <biju.das.jz@...renesas.com>,
 Ulf Hansson <ulf.hansson@...aro.org>, Philipp Zabel <p.zabel@...gutronix.de>
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, all,

On 03.09.2024 17:48, claudiu beznea wrote:
> 
> 
> On 03.09.2024 16:45, Biju Das wrote:
>> 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.
> 
> As you may already know, this is open for quite some time and is ongoing.

I got more clarification about the USB PWRRDY signal from the HW team.

The conclusion is that the USB PWRRDY is a signal controlled by SYSC
controller that goes to the USB PHY and it tells the USB PHY if the power
supply is ready or not.

In the diagram at [1] the PWRRDY signal need to be asserted/de-asserted
before/after G6, G7, G8, G9, G10 signals.

Philipp,

Can you please confirm that you don't want this signal to be implemented as
a reset signal to know clearly your input on it? I would like to start
looking for another approach in that case.

Thank you,
Claudiu Beznea

[1] https://pasteboard.co/0a1zYBFZXZVb.png

> 
>>
>> Cheers,
>> Biju
>>
>>