Re: [PATCH v3 2/5] dt-bindings: power: reset: syscon-reboot-mode: allow supplies

[Rob Herring]

On Thu, Oct 08, 2026 at 01:58:55AM +0400, Alexey Charkov wrote:
> On Thu, Oct 8, 2026 at 1:24 AM Rob Herring <robh@xxxxxxxxxx> wrote:
> >
> > On Tue, Oct 06, 2026 at 08:02:40PM +0400, Alexey Charkov wrote:
> > > Whatever program that acts on a reboot mode runs before a full OS, so it
> > > may lack the capability to enable the regulators it depends on, and a
> > > reset that preserves the mode register generally leaves the regulators as
> > > the previously running system left them.
> > >
> > > Allow a reboot mode node to name such supplies, so that they can be
> > > turned on while the mode is being requested.
> > >
> > > Signed-off-by: Alexey Charkov <alchark@xxxxxxxxxxx>
> > > ---
> > >  .../devicetree/bindings/power/reset/syscon-reboot-mode.yaml       | 8 ++++++++
> > >  1 file changed, 8 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.yaml b/Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.yaml
> > > index 79ffc78b23ea..5ed70c87269e 100644
> > > --- a/Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.yaml
> > > +++ b/Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.yaml
> > > @@ -36,6 +36,14 @@ patternProperties:
> > >    "^mode-.*$":
> > >      maxItems: 1
> > >
> > > +  "^[a-z0-9]+(-[a-z0-9]+)*-supply$":
> > > +    description:
> > > +      Supply that has to be powered for whatever program acts on the mode.
> > > +      That could be a boot ROM with no access to regulators, and a warm reset
> > > +      leaves them as the previously running system left them and not necessarily
> > > +      what their expected out-of-reboot state is. Any supply described here is
> > > +      enabled when a mode is requested, and stays enabled.
> >
> > Sorry, but no. If we allow this, then what next? clocks? power-domains?
> > GPIO lines? The list is endless. Maybe if a not generic binding is used,
> > but still pretty much pure configuration.
> 
> These are the resources which are required to handle the reboot mode
> request, they are not exactly configuration. There is a limited and
> hardware defined number of IP blocks which need to be powered for the
> reboot mode request to complete successfully. In my case (Rockchip
> RK3576), these are the IPs that need to be made aware of the trained
> DDR memory parameters: if they are unpowered _at warm reboot_ then the
> boot process stalls immediately with an exception (cold reboot is
> handled by the power-on default state of the PMIC).

If you need certain h/w blocks, then you should list them and then you 
can get whatever resources they have. That's assuming we were to go down 
this path, not an endorsement for doing this.

> I see that this may be abused to hack around what should be a
> bootloader's job, so it would be great to find a way to explicitly
> limit the scope of these - though I couldn't think of one yet. Any
> suggestions would be much appreciated.

Maybe the boot phase stuff could work here?

Rob