From: Saravana Kannan <saravanak@google.com>
To: Simon Glass <sjg@chromium.org>
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 18:36:22 -0700 [thread overview]
Message-ID: <CAGETcx-zOi7HHA+RYBD_CK99er9W4CYGY3qKz5WmAEYpwMdTGA@mail.gmail.com> (raw)
In-Reply-To: <CAFLszTgiyQXqVF48GnHAt1ANwKQK_GxwTrOXQVUrpuOYpocCqw@mail.gmail.com>
On Tue, Mar 12, 2024 at 3:09 PM Simon Glass <sjg@chromium.org> wrote:
>
> 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.
Thanks Simon. I understand your concerns, but once you hit the need
for this property in U-Boot, it'll be pretty obvious what it means in
that context.
Rob, can you pull this in please?
-Saravana
>
> 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.
prev parent reply other threads:[~2024-03-14 1:37 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
2024-03-14 1:36 ` Saravana Kannan [this message]
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=CAGETcx-zOi7HHA+RYBD_CK99er9W4CYGY3qKz5WmAEYpwMdTGA@mail.gmail.com \
--to=saravanak@google.com \
--cc=devicetree-spec@vger.kernel.org \
--cc=kernel-team@android.com \
--cc=robh@kernel.org \
--cc=sjg@chromium.org \
/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).