From: Simon Glass <sjg@chromium.org>
To: Saravana Kannan <saravanak@google.com>
Cc: Rob Herring <robh@kernel.org>,
devicetree-spec@vger.kernel.org, kernel-team@android.com
Subject: Re: [PATCH v1] schemas: Add schema for post-init-providers
Date: Wed, 13 Mar 2024 11:09:07 +1300 [thread overview]
Message-ID: <CAFLszTgiyQXqVF48GnHAt1ANwKQK_GxwTrOXQVUrpuOYpocCqw@mail.gmail.com> (raw)
In-Reply-To: <CAGETcx8cNP-xYFKbjvUnRgm7vPP9iHEqOUAhQBG+V8axOKVB4A@mail.gmail.com>
Hi Saravana,
On Fri, 8 Mar 2024 at 19:48, Saravana Kannan <saravanak@google.com> wrote:
>
> On Thu, Mar 7, 2024 at 12:55 PM Simon Glass <sjg@chromium.org> wrote:
> >
> > Hi Rob,
> >
> > On Thu, 7 Mar 2024 at 11:23, Rob Herring <robh@kernel.org> wrote:
> > >
> > > On Wed, Mar 6, 2024 at 1:17 PM Simon Glass <sjg@chromium.org> wrote:
> > > >
> > > > Hi Saravana,
> > > >
> > > > On Wed, 6 Mar 2024 at 13:30, Saravana Kannan <saravanak@google.com> wrote:
> > > > >
> > > > > The post-init-providers property can be used to break a dependency cycle by
> > > > > marking some provider(s) as a post device initialization provider(s). This
> > > >
> > > > Please can you add hyphens to avoid confusion? I believe this should
> > > > be 'post-device-initialization' throughout. There is no 'post' device.
> > >
> > > There is no 'post-device-initialization' thing either. Shrug.
> >
> > 'post-device-initialization' is intended to be an adjective and the
> > hyphens help to make that clear.
>
> I think it's clear enough, but I'll do it just for you :)
:)
>
> > >
> > > > > allows an OS to do a better job at ordering initialization and
> > > > > suspend/resume of the devices in a dependency cycle.
> > > > >
> > > > > Signed-off-by: Saravana Kannan <saravanak@google.com>
> > > > > ---
> > > > > dtschema/schemas/post-init-providers.yaml | 105 ++++++++++++++++++++++
> > > > > 1 file changed, 105 insertions(+)
> > > > > create mode 100644 dtschema/schemas/post-init-providers.yaml
> > > > >
> > > > > diff --git a/dtschema/schemas/post-init-providers.yaml b/dtschema/schemas/post-init-providers.yaml
> > > > > new file mode 100644
> > > > > index 0000000..92eb9a0
> > > > > --- /dev/null
> > > > > +++ b/dtschema/schemas/post-init-providers.yaml
> > > > > @@ -0,0 +1,105 @@
> > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > > +# Copyright (c) 2020, Google LLC. All rights reserved.
> > > > > +%YAML 1.2
> > > > > +---
> > > > > +$id: http://devicetree.org/schemas/post-init-providers.yaml#
> > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > +
> > > > > +title: Post device initialization providers
> > > > > +
> > > > > +maintainers:
> > > > > + - Saravana Kannan <saravanak@google.com>
> > > > > +
> > > > > +description: |
> > > > > + This property is used to indicate that the device(s) pointed to by the
> > > >
> > > > Should this be 'device node' instead of 'device'?
>
> I think device is more appropriate. Not every device node is a device
> (eg: the pinctrl map, the remote endpoints pointed to by
> remote-endpoints, etc). And with the property you are pointing to a
> device node that represents a device.
I see what you are saying. It's just that this is a devicetree with
nodes, not a device model. So whether a particular node produces a
device is really a separate issue..
Anyway, it is only a minor thing.
>
> > > >
> > > > > + property are not needed for the initialization of the device that lists this
> > > > > + property. This property does not make a device (that's previously not a
> > > > > + provider) into a provider. It simply downgrades an existing provider to a
> > > > > + post device initialization provider.
> > > > > +
> > > > > + A device can list its providers in devicetree using one or more of the
> > > > > + standard devicetree bindings. By default, it is assumed that the provider
> > > > > + device can be initialized before the consumer device is initialized.
> > > > > +
> > > > > + However, that assumption cannot be made when there are cyclic dependencies
> > > > > + between devices. Since each device is a provider (directly or indirectly) of
> > > > > + the others in the cycle, there is no guaranteed safe order for initializing
> > > > > + the devices in a cycle. We can try to initialize them in an arbitrary order
> > > > > + and eventually successfully initialize all of them, but that doesn't always
> > > > > + work well.
> > > > > +
> > > > > + For example, say,
> > > > > + * The device tree has the following cyclic dependency X -> Y -> Z -> X (where
> > > > > + -> denotes "depends on").
> > > > > + * But X is not needed to fully initialize Z (X might be needed only when a
> > > > > + specific functionality is requested post initialization).
> > > >
> > > > How about 'is requested after initialization of Z'
>
> Sure.
>
> > > >
> > > > > +
> > > > > + If all the other -> are mandatory initialization dependencies, then trying to
> > > > > + initialize the devices in a loop (or arbitrarily) will always eventually end
> > > > > + up with the devices being initialized in the order Z, Y and X.
> > > > > +
> > > > > + However, if Y is an optional provider for X (where X provides limited
> > > > > + functionality when Y is not initialized and providing its services), then
> > > > > + trying to initialize the devices in a loop (or arbitrarily) could end up with
> > > > > + the devices being initialized in the following order:
> > > > > +
> > > > > + * Z, Y and X - All devices provide full functionality
> > > > > + * Z, X and Y - X provides partial functionality
> > > > > + * X, Z and Y - X provides partial functionality
> > > > > +
> > > > > + However, we always want to initialize the devices in the order Z, Y and X
> > > > > + since that provides the full functionality without interruptions.
> > > > > +
> > > > > + One alternate option that might be suggested is to have the driver for X
> > > > > + notice that Y became available at a later point and adjust the functionality
> > > > > + it provides. However, other userspace applications could have started using X
> > > > > + with the limited functionality before Y was available and it might not be
> > > > > + possible to transparently transition X or the users of X to full
> > > > > + functionality while X is in use.
> > > >
> > > > This seems strange to me. It seems like something that could be
> > > > implemented. That said, I understand that such an implementation could
> > > > become painful.
> > >
> > > It has been implemented. And cycle detection has been implemented. And
> > > yet we are still here needing something more.
> >
> > Sure, I understand that.
> >
> > >
> > >
> > > > > + Similarly, when it comes to suspend (resume) ordering, it's unclear which
> > > > > + device in a dependency cycle needs to be suspended/resumed first and trying
> > > > > + arbitrary orders can result in system crashes or instability.
> > > > > +
> > > > > + Explicitly calling out which link in a cycle needs to be broken when
> > > > > + determining the order, simplifies things a lot, improves efficiency, makes
> > > > > + the behavior more deterministic and maximizes the functionality that can be
> > > > > + provided without interruption.
> > > > > +
> > > > > + This property is used to provide this additional information between devices
> > > > > + in a cycle by telling which provider(s) is not needed for initializing the
> > > > > + device that lists this property.
> > > > > +
> > > > > + In the example above, Z would list X as a post-init-providers and the
> > > > > + initialization dependency would become X -> Y -> Z -/-> X. So the best order
> > > > > + to initialize them becomes clear: Z, Y and then X.
> > > > > +
> > > > > +select: true
> > > > > +
> > > > > +properties:
> > > > > + post-init-providers:
> > > >
> > > > What is 'init'? It seems to mean when Linux probes the device. In
> > > > U-Boot, devices all are bound at the start, but only probed (lazilly)
> > > > when used. For some device types there is then an 'init' step which
> > > > actually starts using the device, before which no hardware is
> > > > accessed. So the use of the word 'init' seems a bit vague to me.
>
> I'm using the word init as a short form of English word
> "initialization" to mean the device has been initialized and ready to
> provide its services. Whether that means you do stuff lazily or touch
> the hardware is irrelevant. For example, you can probe a device in
> Linux without ever touching any hardware register of that specific
> device.
>
> I intentionally didn't use the word probe (Linux specific) or get into
> specifics because it can depends on the bootloader/OS/whatever driver
> model.
Sure, I understand that init means initialisation...my point is that
this depends on what is initialised at this point.
'probe' is used in U-Boot to mean that a bound device is activated.
>
> So, I'd keep the naming as is. All the other suggestions are more
> confusing in my opinion.
OK. I am not claiming that my suggestions are a lot better. I just
worry that post-initialisation is pretty vague, e.g. devices can go
through a few init steps. Anyway, I suppose we can deal with it later,
if this binding is not enough to get things working.
Regards,
Simon
>
> -Saravana
>
> > > >
> > > > In general this binding seems liable to be specific to the OS being
> > > > used. It also seems to be a hint, rather than something that must be
> > > > parsed and used. However I suppose adding the suffix '-hint' would
> > > > just confuse things.
> > > >
> > > > How about 'secondary-providers' or 'minor-providers' or
> > > > 'delayed-providers' or 'deferred-providers'?
> > > >
> > > > Separately/alternatively I wonder if the target node is always going
> > > > to be inited later, for any device that uses it. If so, perhaps a
> > > > property in the target node would be better, something like:
> > > >
> > > > dispcc: clock-controller@2000 {
> > > > ...
> > > > minor-provider;
> > >
> > > That doesn't work if a node is 2 or more providers and only some of
> > > them are optional/post-init/deferred.
> >
> > That's right. It would be nice though, if the situation you describe
> > does not actually happen in practice currently.
next prev parent reply other threads:[~2024-03-12 22:09 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-06 0:29 [PATCH v1] schemas: Add schema for post-init-providers Saravana Kannan
2024-03-06 13:11 ` Rob Herring
2024-03-06 20:52 ` Saravana Kannan
2024-03-06 19:17 ` Simon Glass
2024-03-06 22:22 ` Rob Herring
2024-03-07 20:55 ` Simon Glass
2024-03-08 6:47 ` Saravana Kannan
2024-03-12 22:09 ` Simon Glass [this message]
2024-03-14 1:36 ` Saravana Kannan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAFLszTgiyQXqVF48GnHAt1ANwKQK_GxwTrOXQVUrpuOYpocCqw@mail.gmail.com \
--to=sjg@chromium.org \
--cc=devicetree-spec@vger.kernel.org \
--cc=kernel-team@android.com \
--cc=robh@kernel.org \
--cc=saravanak@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).