Re: [PATCH v7 4/7] reset: rzg2l-usbphy-ctrl: Add support for USB PWRRDY

[Philipp Zabel <p.zabel@pengutronix.de>]

Hi Claudiu,

On Di, 2025-10-21 at 11:48 +0300, Claudiu Beznea wrote:
> Hi, Philipp,
> 
> On 10/15/25 11:19, Claudiu Beznea wrote:
> > > > > > > > I see v2 and v3 tried to control the bit from the PHY drivers, and in
> > > > > > > > v4 we were are already back to the reset driver.
> > > > > > > v2 passed the system controller (SYSC) phandle to the USB PHYs only (though
> > > > > > > renesas,sysc-signals DT property) where the PWRRDY bit was set. The PWRRDY
> > > > > > > bit was referenced counted in the SYSC driver though regmap APIs.
> > > > > > > 
> > > > > > > v3 used the approach from v2 but passed the renesas,sysc-signals to all the
> > > > > > > USB related drivers.
> > > > > > > 
> > > > > > > Then, in v4, the PWRRDY refcounting was dropped and passed
> > > > > > > renesas,sysc-signals only to the USB PHY CTRL DT node in the idea that this
> > > > > > > is the node that will always be probed first as all the other USB blocks
> > > > > > > need it and request resets from it.
> > > > > > > 
> > > > > > > v5 and v6 kept the approach from v4 and only addressed misc comments or
> > > > > > > things that I noticed.
> > > > > > Could you please let me know if you are OK with the approach proposed in
> > > > > > v7, so that I can start preparing a new version addressing your comments?
> > > > > If the PWRRDY signal is an input to the USB2PHY control block, and not
> > > > > only to the PHY blocks, I have no issue with this being handled in the
> > > > > usb2phy reset driver -
> > > > Yes, this is how the Renesas HW team confirmed they are related.
> > > Ok, understood. I concur that usb2phy-ctrl is the right place for the
> > > sysc property then.
> > > 
> > > > > iff it is not sensible to just control the
> > > > > signal from the power domain driver.
> > > > As mentioned above, that can be done as well but, passing a SYSC phandle to
> > > > the CPG DT node will not be valid from the HW description point of view.
> > > > 
> > > > > If we have to handle it in the reset driver, I'd prefer to see this
> > > > > controlled with a dev_pm_genpd_add_notifier(). If that is not possible,
> > > > > I'd like to understand why.
> > > > From the code inspection I did, that can be done. From what I can tell at
> > > > the moment, I'll have to register a gepnd notifier from
> > > > reset-rzg2l-usbphy-ctrl, before runtime resuming the device and control the
> > > > SYSC PWRRDY from it.
> > > I'd like that.
> > Now, that we found the genpd notifier is not a solution, could you please
> > let me know how would you like me to proceed?
> 
> After discussing all the possible (known) solutions, could you please let
> me know if you are OK with the approach in this series?

Yes, I don't have a better idea. Let's revisit the issue of ordering
guarantees when suspend/resume is implemented.

regards
Philipp