From: Sudeep Holla <sudeep.holla@arm.com>
To: Saravana Kannan <saravanak@google.com>
Cc: Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Frank Rowand <frowand.list@gmail.com>,
David Collins <collinsd@codeaurora.org>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel-team@android.com, Sudeep Holla <sudeep.holla@arm.com>
Subject: Re: [RESEND PATCH v1 3/5] dt-bindings: Add depends-on property
Date: Wed, 12 Jun 2019 15:45:59 +0100 [thread overview]
Message-ID: <20190612144559.GA21466@e107155-lin> (raw)
In-Reply-To: <20190604003218.241354-4-saravanak@google.com>
On Mon, Jun 03, 2019 at 05:32:16PM -0700, Saravana Kannan wrote:
> The depends-on property is used to list the mandatory functional
> dependencies of a consumer device on zero or more supplier devices.
>
> Signed-off-by: Saravana Kannan <saravanak@google.com>
> ---
> .../devicetree/bindings/depends-on.txt | 26 +++++++++++++++++++
> 1 file changed, 26 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/depends-on.txt
>
> diff --git a/Documentation/devicetree/bindings/depends-on.txt b/Documentation/devicetree/bindings/depends-on.txt
> new file mode 100644
> index 000000000000..1cbddd11cf17
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/depends-on.txt
> @@ -0,0 +1,26 @@
> +Functional dependency linking
> +=============================
> +
> +Apart from parent-child relationships, devices (consumers) often have
> +functional dependencies on other devices (suppliers). Common examples of
> +suppliers are clock, regulators, pinctrl, etc. However not all of them are
> +dependencies with well defined devicetree bindings. Also, not all functional
> +dependencies are mandatory as the device might be able to operate in a limited
> +mode without some of the dependencies.
> +
> +The depends-on property allows marking these mandatory functional dependencies
> +between one or more devices. The depends-on property is used by the consumer
> +device to point to all its mandatory supplier devices.
> +
> +Optional properties:
> +- depends-on: A list of phandles to mandatory suppliers of the device.
> +
> +
> +Examples:
> +Here, the device is dependent on only 2 of the 3 clock providers
> +dev@40031000 {
> + compatible = "name";
> + reg = <0x40031000 0x1000>;
> + clocks = <&osc_1 1>, <&osc_2 7> <&osc_3 5>;
> + depends-on = <&osc_1>, <&osc_3>;
Why is this not implicit from clocks property and why is there need for
explicit mention of this ?
What happens if there's a cyclic dependency ? From hardware perspective,
cyclic dependency is quite feasible, so IMO it's hard to define this
property unambiguously.
And being optional, we need to deal with the absence of these, and if we
fallback to marking clock, regulators, pinctrl suppliers as depends-on,
this may end up redundant.
You may need to show examples(preferably with DTs in mainline just to
help understand it quickly and easily) that are beyond these standard
suppliers that are not implicit to add this property.
--
Regards,
Sudeep
next prev parent reply other threads:[~2019-06-12 14:45 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-04 0:32 [RESEND PATCH v1 0/5] Solve postboot supplier cleanup and optimize probe ordering Saravana Kannan
2019-06-04 0:32 ` [RESEND PATCH v1 1/5] of/platform: Speed up of_find_device_by_node() Saravana Kannan
2019-06-10 17:36 ` Rob Herring
2019-06-10 19:15 ` Saravana Kannan
2019-06-10 21:07 ` Rob Herring
2019-06-11 15:18 ` Frank Rowand
2019-06-11 20:56 ` Saravana Kannan
2019-06-11 21:52 ` Sandeep Patil
2019-06-12 13:53 ` Rob Herring
2019-06-12 14:21 ` Greg Kroah-Hartman
2019-06-12 16:53 ` Rob Herring
2019-06-12 17:08 ` Greg Kroah-Hartman
2019-06-12 18:19 ` Rob Herring
2019-06-12 19:29 ` Saravana Kannan
2019-06-12 20:23 ` Frank Rowand
2019-06-12 21:12 ` Rob Herring
2019-06-12 22:10 ` Saravana Kannan
2019-06-12 23:23 ` Rob Herring
2019-06-18 20:47 ` Sandeep Patil
2019-06-18 21:22 ` Saravana Kannan
2019-06-12 17:03 ` Frank Rowand
2019-06-12 16:07 ` Frank Rowand
2019-06-12 16:47 ` Frank Rowand
2019-06-12 19:03 ` Frank Rowand
2019-06-04 0:32 ` [RESEND PATCH v1 2/5] driver core: Add device links support for pending links to suppliers Saravana Kannan
2019-06-04 0:32 ` [RESEND PATCH v1 3/5] dt-bindings: Add depends-on property Saravana Kannan
2019-06-12 14:45 ` Sudeep Holla [this message]
2019-06-04 0:32 ` [RESEND PATCH v1 4/5] of/platform: Add functional dependency link from "depends-on" property Saravana Kannan
2019-06-04 0:32 ` [RESEND PATCH v1 5/5] driver core: Add sync_state driver/bus callback Saravana Kannan
2019-06-12 21:21 ` [RESEND PATCH v1 0/5] Solve postboot supplier cleanup and optimize probe ordering Frank Rowand
2019-06-13 13:19 ` Rob Herring
2019-06-24 22:37 ` Sandeep Patil
2019-06-25 3:53 ` Greg Kroah-Hartman
2019-06-26 4:30 ` Sandeep Patil
2019-06-26 5:49 ` Frank Rowand
2019-06-26 21:30 ` Rob Herring
2019-06-28 2: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=20190612144559.GA21466@e107155-lin \
--to=sudeep.holla@arm.com \
--cc=collinsd@codeaurora.org \
--cc=devicetree@vger.kernel.org \
--cc=frowand.list@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=kernel-team@android.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=rafael@kernel.org \
--cc=robh+dt@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 NNTP newsgroup(s).