Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp2002912ybf; Sun, 1 Mar 2020 23:39:37 -0800 (PST) X-Google-Smtp-Source: APXvYqwuoD4tPmhWx864ojcR8Zzkofa0xmkY5pzWg+yZ/j+nUqGfRl7stcI3SpVQufO+T+bJx0PN X-Received: by 2002:a05:6808:8d5:: with SMTP id k21mr10804973oij.121.1583134776873; Sun, 01 Mar 2020 23:39:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583134776; cv=none; d=google.com; s=arc-20160816; b=nDcDlZs3t6Qmg/QeZWbj4BRCPa0th4Tcoooff8EkhS5RTGJ1P3YIuvpNwS0UPMCSaM qx1Ps6rfZyaQN2H+ZKz/1sreterL4S9EHypNr8NCdm2YBR+bp89Svr5snZYGvPgS4hP6 y/QO17Jnja7oirI0si643szi8TyMzFWrwwswM38yCxH8maxJ3yNhlP4Oe0tDK8AFCGiS 0RDz0nhOwoy1QaY+cBuFKAaHq/bwwFsPHpBIlDd9RmYVVMdglFbfzxQ+DF2c5E8PQb67 Ntz1/mLTa8Ev9eaLwraOlxudvI5CFal8wnZx2af8hPq7EqCJjnZak7tToFIjMGpW3clg 0FzQ== 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=9+QUF/bztHWczXI5D0ZwaG0yI7YDKvE0GQR4Qg+T48o=; b=shLl4P1bvmsJfTyqHV0R80NojCCQD6bLTWg/eZcY2mW9KPOf70kYDFiMJ5f/iWkuYX cbUi9va592vn0MfG3050cpSh2vJJyRMLU8RPe0cFu97gbdb61GYQzSFP4yaPyqsX9HYV qvgFJbh0fCFlJcqP3LjBFyzllyJE3xVTPrYZw8BkVPpmvvv4RJ763vSE8Yc9maQT+UWH dQtbuyljibnK4s9wAgKIDz0pHYvF9x96HQp0V2Hc/FEeHWL7lZf3k7Ee1Sf0hT7C89v5 TuylimjcKS8rgmI90SybJNpD2rSKYserscKZcoGJ9aF/k+kmUoeGZGH/E26adoeSXFtr sXCw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="HpLp/Mj+"; 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 z14si5542963oth.15.2020.03.01.23.39.24; Sun, 01 Mar 2020 23:39:36 -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="HpLp/Mj+"; 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 S1727322AbgCBHiz (ORCPT + 99 others); Mon, 2 Mar 2020 02:38:55 -0500 Received: from mail.kernel.org ([198.145.29.99]:44680 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726313AbgCBHiQ (ORCPT ); Mon, 2 Mar 2020 02:38:16 -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 6FC83246BB; Mon, 2 Mar 2020 07:38:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1583134694; bh=RkXMP+0rmN7FNXRM/XfkcziqjvG6FZE3i0bVd54Myrc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=HpLp/Mj+uYiwKgMivoxWnH1wHYG+pWQe3AuVP3NIFfVQkV1hrOnDwTT2yGFh76uT/ IQ4Bdqjq7l+prw1CEJT9wHch4VD3PkR2yRhtf0ZB7rClpMn8uJPUQY1+GCfy4oDkAp YFBNsMKogmnY5KYaQjJCqHjl8JOywmRRr+s71j/U= Received: from mchehab by mail.kernel.org with local (Exim 4.92.3) (envelope-from ) id 1j8feV-0003Vu-W9; Mon, 02 Mar 2020 08:38:12 +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, Mauro Carvalho Chehab Subject: [PATCH 08/12] docs: dt: convert overlay-notes.txt to ReST format Date: Mon, 2 Mar 2020 08:38:03 +0100 Message-Id: <1685e79f7b53c70c64e37841fb4df173094ebd17.1583134242.git.mchehab+samsung@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 From: Mauro Carvalho Chehab - 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 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