Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp2016873ybf; Mon, 2 Mar 2020 00:00:35 -0800 (PST) X-Google-Smtp-Source: APXvYqw7DXd7j2tvDHL5t2dkjr6xcl9Ggr+kIT1YdqhN9KoqmYTIGGvFkl8DCVpJeCkotD3Vuvmh X-Received: by 2002:a9d:bef:: with SMTP id 102mr12222721oth.225.1583136034969; Mon, 02 Mar 2020 00:00:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583136034; cv=none; d=google.com; s=arc-20160816; b=EfQk2j2IXyhfRLLzQDo15gbeSe+Lua1asbHGsdpQGZ7VsOB0y72x8LXNVs6hu+8UqJ fUY6VnBbcmOO6XhsQh3R34V4JdSJ5QuzQjZEeZgJWf50vlTBUnPPfQut3uGNZVmSLgpF d8bwCqpHdP9TQsXaBAHLgQFseS74VCbUN7cWcFPVyVN4oOFAGc4dSjjrUyyic2rpo4Es ZbGnkKdjGmamQy4JtcARFFd5KXXXRy1Nw9YtQpwGo0ytlZ9WPX0BE2uIG6bGv6D+0VAK d2uMDkD1tkvkRnATHwMDEzQqiID/eZTpEUhBYsa6cP/+8Gnei22awBx27D4cKa1USXb9 eNaQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=PxeM4rsaG27jbZ/Th6Ub8TSFWNcux0uDudaGCvFYQCY=; b=R/yODv7erno1itb3EiF14EmAuoN6IqFLqGMJ+PUshbA0oEUYLn+GFbcdVQcGs+28c4 cmdupY7HoPT51wWs2M3gjitZpZjoBTZWLtJtWeMNpbb/Txg+bbTRAmx600bfC/QGATjn NGufgRqEtgwOvxS9bIJb6j9ykexN5PV6F15nhMU9Mr0absOZWrDollzjxS28XwoikrjI FDslKmJqe4negViQBVq3VY6HTKrBGSynOLkxemjIHWn15ftcnJYz5i1sb9GejcZ1D/WS +UIwy89fjnk2QNYmj6UNx0bijZZii53VYCaj/6vAycx3IIF46NS8MQy6DzI4rgl03/nh L/Nw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=dlgTCryL; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i3si6330016otc.272.2020.03.02.00.00.23; Mon, 02 Mar 2020 00:00:34 -0800 (PST) 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; dkim=pass header.i=@kernel.org header.s=default header.b=dlgTCryL; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727399AbgCBIAD (ORCPT + 99 others); Mon, 2 Mar 2020 03:00:03 -0500 Received: from mail.kernel.org ([198.145.29.99]:51368 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727186AbgCBH7n (ORCPT ); Mon, 2 Mar 2020 02:59:43 -0500 Received: from mail.kernel.org (ip5f5ad4e9.dynamic.kabel-deutschland.de [95.90.212.233]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 876F8246C7; Mon, 2 Mar 2020 07:59:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1583135982; bh=Jzq/d13Lj8z2lnW0mDzJsr013tR8G799MjoHArJrvC0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=dlgTCryL7OO3/DmVSxJTgNxsr2+csmefxXL0oSWybbzboJfJcG61p3bT3fOHoPlx3 qcaKT4ryTjA0mPAzAFR70MHxrZoiNvt8HaAcJK0VnHZ9t0H/Bu1rA0q8xhHN+3b4mV Eq8XT16mKBHi2dFJAwqJ8jf8k8YW6j6LdLiZCumE= Received: from mchehab by mail.kernel.org with local (Exim 4.92.3) (envelope-from ) id 1j8fzH-0003gq-6l; Mon, 02 Mar 2020 08:59:39 +0100 From: Mauro Carvalho Chehab To: Linux Doc Mailing List Cc: Mauro Carvalho Chehab , linux-kernel@vger.kernel.org, Jonathan Corbet , Rob Herring , Pantelis Antoniou , Frank Rowand , devicetree@vger.kernel.org Subject: [PATCH v2 08/12] docs: dt: convert overlay-notes.txt to ReST format Date: Mon, 2 Mar 2020 08:59:33 +0100 Message-Id: <1685e79f7b53c70c64e37841fb4df173094ebd17.1583135507.git.mchehab+huawei@kernel.org> X-Mailer: git-send-email 2.21.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org - Add a SPDX header; - Adjust document title; - Some whitespace fixes and new line breaks; - Mark literal blocks as such; - Add it to devicetree/index.rst. Signed-off-by: Mauro Carvalho Chehab --- Documentation/devicetree/index.rst | 1 + .../{overlay-notes.txt => overlay-notes.rst} | 141 +++++++++--------- MAINTAINERS | 2 +- 3 files changed, 74 insertions(+), 70 deletions(-) rename Documentation/devicetree/{overlay-notes.txt => overlay-notes.rst} (56%) diff --git a/Documentation/devicetree/index.rst b/Documentation/devicetree/index.rst index ca83258fbba5..0669a53fc617 100644 --- a/Documentation/devicetree/index.rst +++ b/Documentation/devicetree/index.rst @@ -13,3 +13,4 @@ Open Firmware and Device Tree changesets dynamic-resolution-notes of_unittest + overlay-notes diff --git a/Documentation/devicetree/overlay-notes.txt b/Documentation/devicetree/overlay-notes.rst similarity index 56% rename from Documentation/devicetree/overlay-notes.txt rename to Documentation/devicetree/overlay-notes.rst index 3f20a39e4bc2..7e8e568f64a8 100644 --- a/Documentation/devicetree/overlay-notes.txt +++ b/Documentation/devicetree/overlay-notes.rst @@ -1,5 +1,8 @@ +.. SPDX-License-Identifier: GPL-2.0 + +========================= Device Tree Overlay Notes -------------------------- +========================= This document describes the implementation of the in-kernel device tree overlay functionality residing in drivers/of/overlay.c and is a @@ -15,68 +18,68 @@ Since the kernel mainly deals with devices, any new device node that result in an active device should have it created while if the device node is either disabled or removed all together, the affected device should be deregistered. -Lets take an example where we have a foo board with the following base tree: - ----- foo.dts ----------------------------------------------------------------- - /* FOO platform */ - / { - compatible = "corp,foo"; - - /* shared resources */ - res: res { - }; - - /* On chip peripherals */ - ocp: ocp { - /* peripherals that are always instantiated */ - peripheral1 { ... }; - } - }; ----- foo.dts ----------------------------------------------------------------- - -The overlay bar.dts, when loaded (and resolved as described in [1]) should - ----- bar.dts ----------------------------------------------------------------- -/plugin/; /* allow undefined label references and record them */ -/ { - .... /* various properties for loader use; i.e. part id etc. */ - fragment@0 { - target = <&ocp>; - __overlay__ { - /* bar peripheral */ - bar { - compatible = "corp,bar"; - ... /* various properties and child nodes */ - } - }; - }; -}; ----- bar.dts ----------------------------------------------------------------- - -result in foo+bar.dts - ----- foo+bar.dts ------------------------------------------------------------- - /* FOO platform + bar peripheral */ - / { - compatible = "corp,foo"; - - /* shared resources */ - res: res { - }; - - /* On chip peripherals */ - ocp: ocp { - /* peripherals that are always instantiated */ - peripheral1 { ... }; - - /* bar peripheral */ - bar { - compatible = "corp,bar"; - ... /* various properties and child nodes */ - } - } - }; ----- foo+bar.dts ------------------------------------------------------------- +Lets take an example where we have a foo board with the following base tree:: + + ---- foo.dts -------------------------------------------------------------- + /* FOO platform */ + / { + compatible = "corp,foo"; + + /* shared resources */ + res: res { + }; + + /* On chip peripherals */ + ocp: ocp { + /* peripherals that are always instantiated */ + peripheral1 { ... }; + } + }; + ---- foo.dts -------------------------------------------------------------- + +The overlay bar.dts, when loaded (and resolved as described in [1]) should:: + + ---- bar.dts -------------------------------------------------------------- + /plugin/; /* allow undefined label references and record them */ + / { + .... /* various properties for loader use; i.e. part id etc. */ + fragment@0 { + target = <&ocp>; + __overlay__ { + /* bar peripheral */ + bar { + compatible = "corp,bar"; + ... /* various properties and child nodes */ + } + }; + }; + }; + ---- bar.dts -------------------------------------------------------------- + +result in foo+bar.dts:: + + ---- foo+bar.dts ---------------------------------------------------------- + /* FOO platform + bar peripheral */ + / { + compatible = "corp,foo"; + + /* shared resources */ + res: res { + }; + + /* On chip peripherals */ + ocp: ocp { + /* peripherals that are always instantiated */ + peripheral1 { ... }; + + /* bar peripheral */ + bar { + compatible = "corp,bar"; + ... /* various properties and child nodes */ + } + } + }; + ---- foo+bar.dts ---------------------------------------------------------- As a result of the overlay, a new device node (bar) has been created so a bar platform device will be registered and if a matching device driver @@ -88,11 +91,11 @@ Overlay in-kernel API The API is quite easy to use. 1. Call of_overlay_fdt_apply() to create and apply an overlay changeset. The -return value is an error or a cookie identifying this overlay. + return value is an error or a cookie identifying this overlay. 2. Call of_overlay_remove() to remove and cleanup the overlay changeset -previously created via the call to of_overlay_fdt_apply(). Removal of an -overlay changeset that is stacked by another will not be permitted. + previously created via the call to of_overlay_fdt_apply(). Removal of an + overlay changeset that is stacked by another will not be permitted. Finally, if you need to remove all overlays in one-go, just call of_overlay_remove_all() which will remove every single one in the correct @@ -109,9 +112,9 @@ respective node it received. Overlay DTS Format ------------------ -The DTS of an overlay should have the following format: +The DTS of an overlay should have the following format:: -{ + { /* ignored properties by the overlay */ fragment@0 { /* first child node */ @@ -131,7 +134,7 @@ The DTS of an overlay should have the following format: ... }; /* more fragments follow */ -} + } Using the non-phandle based target method allows one to use a base DT which does not contain a __symbols__ node, i.e. it was not compiled with the -@ option. diff --git a/MAINTAINERS b/MAINTAINERS index 1380b1ed69a2..3f679cb4b330 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -12459,7 +12459,7 @@ M: Frank Rowand L: devicetree@vger.kernel.org S: Maintained F: Documentation/devicetree/dynamic-resolution-notes.rst -F: Documentation/devicetree/overlay-notes.txt +F: Documentation/devicetree/overlay-notes.rst F: drivers/of/overlay.c F: drivers/of/resolver.c K: of_overlay_notifier_ -- 2.21.1