RE: [PATCH 2/3] power: sequencing: Add Renesas RZ/G3L Power Ready driver

Biju Das <[email protected]>
Newsgroups org.kernel.vger.linux-pm,org.kernel.vger.linux-kernel,org.kernel.vger.linux-renesas-soc
Message-ID <TY3PR01MB11346732C04ED0DC52502267B86CA2@TY3PR01MB11346.jpnprd01.prod.outlook.com>
Hi Bartosz Golaszewski,

> -----Original Message-----
> From: Bartosz Golaszewski <[email protected]>
> Sent: 29 July 2026 14:09
> Subject: Re: [PATCH 2/3] power: sequencing: Add Renesas RZ/G3L Power Ready driver
> 
> On Tue, 28 Jul 2026 16:38:00 +0200, Biju Das <[email protected]> said:
> > Hi Bartosz Golaszewski,
> >
> > Thanks for the feedback.
> >
> >> -----Original Message-----
> >> From: Bartosz Golaszewski <[email protected]>
> >> Sent: 28 July 2026 15:22
> >> Subject: Re: [PATCH 2/3] power: sequencing: Add Renesas RZ/G3L Power
> >> Ready driver
> >>
> >> On Tue, 28 Jul 2026 13:55:22 +0200, Biju Das <[email protected]> said:
> >> > Hi Bartosz Golaszewski,
> >> >
> >> >> -----Original Message-----
> >> >> From: Bartosz Golaszewski <[email protected]>
> >> >> Sent: 28 July 2026 12:35
> >> >> Subject: Re: [PATCH 2/3] power: sequencing: Add Renesas RZ/G3L
> >> >> Power Ready driver
> >> >>
> >> >> On Tue, 28 Jul 2026 11:17:58 +0200, Biju Das <[email protected]> said:
> >> >> > Hi Bartosz Golaszewski,
> >> >> >
> >> >> > Thanks for the feedback.
> >> >> >
> >> >>
> >> >> ...
> >> >>
> >> >> >> > +
> >> >> >> > +static int pwrseq_rzg3l_pwrrdy_match(struct pwrseq_device *pwrseq,
> >> >> >> > +				     struct device *dev) {
> >> >> >> > +	return PWRSEQ_MATCH_OK;
> >> >> >>
> >> >> >> When I see an always-tru match() callback, it always raises an alarm bell.
> >> >> >> Typically, I'd expect there to be some validation of the consumer happening.
> >> >> >>
> >> >> >> Please at least provide an explanation of why it's ok.
> >> >> >
> >> >> > Without the match function the driver is not probing.
> >> >> >
> >> >>
> >> >> Yes, that's expected.
> >> >>
> >> >> > sysc(driver) ->powerseq(driver) ->{DSI,CSI,USB}(driver) there is
> >> >> > no property that I can match here as the resource is a register
> >> >> > on the SYSC IP and powerseq driver is instantiated by the SYSC driver.
> >> >> >
> >> >> > Maybe I can provide a comment here saying that??
> >> >> > "No DT property to match here, so it is OK always"
> >> >> >
> >> >>
> >> >> So the sysc is the parent of the pwrseq provider and the CSI, DSI
> >> >> and USB drivers are the consumers of the pwrseq descriptor? The
> >> >> latter are children of the platform bus, am I getting this right?
> >> >> Can you point me to the device tree that
> >> describes it?
> >> >
> >> > Yes,
> >> >
> >> > Please see [1], [2], [3]
> >> >
> >> > [1] sysc node
> >> >
> >> > [2] phyrst node (I planned to remove renesas,sysc-pwrrdy in the
> >> > next version as it is going to use pwrseq)
> >> >
> >> > [3] dsi node (I planned to remove renesas,sysc-pwrrdy in the next
> >> > version as it is going to use pwrseq)
> >> >
> >> > [1]
> >> > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> >> > /tr
> >> > ee/arch/arm64/boot/dts/renesas/r9a08g046.dtsi?h=next-20260727#n609
> >> >
> >> > [2]
> >> > https://lore.kernel.org/all/TY3PR01MB11346FA21EFADC8A3D53D81BE86CF2
> >> > @TY
> >> > 3PR01MB11346.jpnprd01.prod.outlook.com/T/#mf24ae1363925a97c840b275c
> >> > 108
> >> > a9b72942c40bc
> >> >
> >> > [3]
> >> > https://lore.kernel.org/all/20260704093433.273672-1-biju.das.jz@bp.
> >> > ren
> >> > esas.com/T/#m31c6711b5403c5a387b22467bb88371df73ae2b1
> >> >
> >> >
> >> > Cheers,
> >> > Biju
> >> >
> >>
> 
> Please wrap your emails at 80 characters as per the mailing list etiquette.

OK.

> 
> >> Then it seems you have a phandle from the DSI node to the sysc node:
> >>
> >> renesas,sysc-pwrrdy = <&sysc 0xd70 0x2>;
> >
> > But this is no more required after modelling the pwrrdy signal as powerseq driver.
> >
> 
> So can you show me what the actual DT nodes and connections look like?
> 
> >>
> >> In match() you can check if that phandle leads to the sysc device
> >> who's the parent of the power sequencer device and return MATCH_OK if it is.
> >
> > As per the DT maintainer Krzysztof Kozlowski, we should not use random phandles for pwrrdy signal.
> >
> > Also, I confirm that this property is unnecessary if we model it as Power sequencer.
> >
> > From ABI, point now only matters is the pwrseq_target_data.name in the
> > power sequence driver and consumers.
> >
> > dsi->pwrseq = devm_pwrseq_get(dsi->dev, "dsi-pwrrdy");
> > priv->pwrseq = devm_pwrseq_get(dev, "usb-pwrrdy");
> >
> > From the experience, I don't think, DT maintainers will allow to
> > define a vendor property just for the driver match.
> >
> 
> You pointed me to the node so I assumed this is what it will look like. I don't have the full context in
> my head.

My bad. Sorry for that, Today I have posted power sequence consumer drivers with DT.

> I still prefer there to be some connection and validation of the pwrseq consumer so I'm inquiring about
> the architecture.

OK.

> 
> Please respond with the relevant DT nodes' final form.

Here it is. Please find the relevant DT nodes usbphy-ctrl [1] and dsi [2]

[1] https://lore.kernel.org/all/[email protected]/
[2] https://lore.kernel.org/all/[email protected]/

Cheers,
Biju
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.