Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp5939128ybi; Wed, 12 Jun 2019 11:03:31 -0700 (PDT) X-Google-Smtp-Source: APXvYqyBwBy3dSAsG/22oPfKwlNOEz71gtwLsmSDMlH/7IU9IzvtFbWG+RRUl6zmXUAUJMrbQTOQ X-Received: by 2002:a63:d218:: with SMTP id a24mr19176977pgg.419.1560362611764; Wed, 12 Jun 2019 11:03:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560362611; cv=none; d=google.com; s=arc-20160816; b=PkPLfkGL6dMwxqZQcmlPOPcj9/b06/TUi7tbDYXnjNqMc6xwpoyF2zrM4uPJ2rfiGC zxLqsSHSZ49T73bIccTjHjNcrBoFTCZ4afZZ0nyGKh62xtjPlVDk/n+jIwNg3jJawgng FtaeLzA5OZVDWOzJDJiQN+CkuC4UfjMfEIiycfM0Q7GkytIu/CNzUlAXJQYL5bzROhYy Oyx6bWzJrJ2l9kb/tmX3a3NSQGopSPaCENhYuDgMMIHwc8FBrZU1/arffbQYjYmkDBk7 Ap+CiEOWcd/cLd8l0ERZ/d/9/y9UMDP8HEBbb9/cdCOgkgMe7WwpMTiwCv8W2g6EPyHh gUMw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=GNNhp5De0VSW1nflumt/Oj5JDfrGeIwdMN5s06v1W+o=; b=eRKZc/K6F5M87Y9MD2xQfjbGy68egcDQiUIQ+8UBbDIdQmVkdVCKQk7weIrZAlYYSJ ybN+Kd46N3maNvGhQDul4RPPK9x/vPtlGcrEt3GC+v324nHwTbSoiAGOQbdavKc9pxWR 5/VPXPPvkoYgFngh4bDCrFobA112tilKX5iaacasVHYwX1oTzR87GIA66rV1LJSJt9e7 obj79GIeOmCJB5CW5wSNg5PxI3Lo44nMSmUAu2AhlhP2isWHh+BegydX70M4ON3Mtl4Y XLrRayhDMKMqB60HwogDN+mjesVO5f2C7YLWTkVJzAjMwZq3E8f0FH3QnB4vr01mC2o7 UzNQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 21si400350pfa.144.2019.06.12.11.03.17; Wed, 12 Jun 2019 11:03:31 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732534AbfFLOqH (ORCPT + 99 others); Wed, 12 Jun 2019 10:46:07 -0400 Received: from foss.arm.com ([217.140.110.172]:54956 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728707AbfFLOqH (ORCPT ); Wed, 12 Jun 2019 10:46:07 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id CD29D2B; Wed, 12 Jun 2019 07:46:06 -0700 (PDT) Received: from e107155-lin (e107155-lin.cambridge.arm.com [10.1.196.42]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 5E4533F557; Wed, 12 Jun 2019 07:46:05 -0700 (PDT) Date: Wed, 12 Jun 2019 15:45:59 +0100 From: Sudeep Holla To: Saravana Kannan Cc: Rob Herring , Mark Rutland , Greg Kroah-Hartman , "Rafael J. Wysocki" , Frank Rowand , David Collins , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@android.com, Sudeep Holla Subject: Re: [RESEND PATCH v1 3/5] dt-bindings: Add depends-on property Message-ID: <20190612144559.GA21466@e107155-lin> References: <20190604003218.241354-1-saravanak@google.com> <20190604003218.241354-4-saravanak@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190604003218.241354-4-saravanak@google.com> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > --- > .../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