Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp567338ybi; Fri, 24 May 2019 08:04:02 -0700 (PDT) X-Google-Smtp-Source: APXvYqxbB5+0sODLeoTUf5SDlMDTAjrUOMdwbIGm7CtgFdMsuvh0Fm/IWlAfq9l1SFItTg/azs1J X-Received: by 2002:a17:902:7581:: with SMTP id j1mr23220065pll.23.1558710242610; Fri, 24 May 2019 08:04:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558710242; cv=none; d=google.com; s=arc-20160816; b=BG8OrRS3hbmgMvwu3Hp39Xk6TsrW8thFvLGfxFXi5h7DoK6AwiavThhnklLDuM6nc/ lXp4eSDY9WKBelCxA9B/yY8uGrqrkuCcWZF9Fm+HbJUa/QM4fYgJ4wwQxRgMzr76yrdQ 0HlWxgTxYcXtugTCGqjl8D0Y6N8cRSoljPaqxbSQnQXvmJhSh2yjVjNQr1LvaBbhqOHo 5rum1Gu6GSML+o3I+kSn/TpizdDMzCpylLaHpxg+jf/SNibVvFHzVypH8AYlUxaDjC4N xaZFmXnLlQmtFFyMmrCJnlxePIfoZUFJHdpXBYi0vJ5OJSHX0BPRPROUr7VEgnT9sMVb 59aQ== 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=gIRW6wKSlWvrdQuF0X3NDv531vkoEQuquQI5QQOnuuU=; b=vSn3B7DQ+TAur6nGaMkm5Jsvw/ZA0A1CBQ49fnlzclLLhz4B8kiZenY9tnSzatSO48 8DWjNekz/wid+oBwY0OTK8+zEAZ/VHVu5fbpoBplOYrP3LkYbnstZjFTlXIfENV6bcLs beHvfIabFx8moXIgsVIG9B0LlRm3Qkt9DfqDU/7e6bFMD+YsCcHDTkXFxRgMYw1FY/Yl jkDHc/e1RngQrhXnFstxbvgt9V9Q5VU/p3WNpvHPcAplMcgV2+C4IFK6AhOQnhThVKKL +HuGiYKXvJpAC6lOoNROK07d/A0ptfX1/0FiaP8VZZgNJSldpdmJiHAq3ym+uRtdQiCJ NO6w== 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 s5si5184480pfd.210.2019.05.24.08.03.43; Fri, 24 May 2019 08:04:02 -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 S2389303AbfEXPBk (ORCPT + 99 others); Fri, 24 May 2019 11:01:40 -0400 Received: from foss.arm.com ([217.140.101.70]:44812 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2389057AbfEXPBk (ORCPT ); Fri, 24 May 2019 11:01:40 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D812980D; Fri, 24 May 2019 08:01:39 -0700 (PDT) Received: from lakrids.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 5D2813F575; Fri, 24 May 2019 08:01:38 -0700 (PDT) Date: Fri, 24 May 2019 16:01:35 +0100 From: Mark Rutland To: Saravana Kannan Cc: Rob Herring , Greg Kroah-Hartman , "Rafael J. Wysocki" , Frank Rowand , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@android.com Subject: Re: [PATCH v1 3/5] dt-bindings: Add depends-on property Message-ID: <20190524150135.GD15566@lakrids.cambridge.arm.com> References: <20190524010117.225219-1-saravanak@google.com> <20190524010117.225219-4-saravanak@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190524010117.225219-4-saravanak@google.com> User-Agent: Mutt/1.11.1+11 (2f07cb52) (2018-12-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 23, 2019 at 06:01:14PM -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. For clocks, regualtors, and pinctrl, that dependency is already implicit in the consumer node's properties. We should be able to derive those dependencies within the kernel. Can you give an example of where a dependency is not implicit in an existing binding? > Also, not all functional > +dependencies are mandatory as the device might be able to operate in a limited > +mode without some of the dependencies. Whether something is a mandatory dependency will depend on the driver and dynamic runtime details more than it will depend on the hardware. For example, assume I have an IP block that functions as both a clocksource and a watchdog that can reset the system, with those two functions derived from separate input clocks. I could use the device as just a clocksource, or as just a watchdog, and neither feature in isolation is necessarily mandatory for the device to be somewhat useful to the OS. We need better ways of dynamically providing and managing this information. For example, if a driver could register its dynamic dependencies at probe (or some new pre-probe callback), we'd be able to notify it immediately when its dependencies are available. Thanks, Mark.