linux-kernel - Re: [PATCH 0/7] of: overlay: Add support for export-symbols node feature

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAL_JsqLT3prYBcxnsUwAShULCLJScYoU29ta29RJLGyiNkCrTg@mail.gmail.com>
Date: Mon, 9 Dec 2024 14:11:09 -0600
From: Rob Herring <robh@...nel.org>
To: Herve Codina <herve.codina@...tlin.com>
Cc: Andrew Davis <afd@...com>, Ayush Singh <ayush@...gleboard.org>, 
	Geert Uytterhoeven <geert@...ux-m68k.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, 
	Conor Dooley <conor+dt@...nel.org>, Arnd Bergmann <arnd@...db.de>, 
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Saravana Kannan <saravanak@...gle.com>, 
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Luca Ceresoli <luca.ceresoli@...tlin.com>, Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: Re: [PATCH 0/7] of: overlay: Add support for export-symbols node feature

On Mon, Dec 9, 2024 at 9:18 AM Herve Codina <herve.codina@...tlin.com> wrote:
>
> Hi,
>
> At Linux Plumbers Conference 2024, we (me and Luca Ceresolli) talked
> about issues we have with runtime hotplug on non-discoverable busses
> with device tree overlays [1].
>
> On our system, a base board has a connector and addon boards can be
> connected to this connector. Both boards are described using device
> tree. The base board is described by a base device tree and addon boards
> are describe by overlays device tree. More details can be found at [2].
>
> This kind of use case can be found also on:
>   - Grove Sunlight Sensor [3]
>   - mikroBUS [4]
>
> One of the issue we were facing on was referencing resources available
> on the base board device tree from the addon overlay device tree.
>
> Using a nexus node [5] helps decoupling resources and avoid the
> knowledge of the full base board from the overlay. Indeed, with nexus
> node, the overlay need to know only about the nexus node itself.
>
> For instance, suppose a connector where a GPIO is connected at PinA. On
> the base board this GPIO is connected to the GPIO 12 of the SoC GPIO
> controller.
>
> The base board can describe this GPIO using a nexus node:
>     soc_gpio: gpio-controller {
>       #gpio-cells = <2>;
>     };
>
>     connector1: connector1 {
>         /*
>          * Nexus node for the GPIO available on the connector.
>          * GPIO 0 (Pin A GPIO) is connected to GPIO 12 of the SoC gpio
>          * controller
>          */
>         #gpio-cells = <2>;
>         gpio-map = <0 0 &soc_gpio 12 0>;
>         gpio-map-mask = <0xf 0x0>;
>         gpio-map-pass-thru = <0x0 0xf>;
>     };
>
> The connector pin A GPIO can be referenced using:
>   <&connector1 0 GPIO_ACTIVE_HIGH>
>
> This implies that the overlay needs to know about exact label that
> references the connector. This label can be different on a different
> board and so applying the overlay could failed even if it is used to
> describe the exact same addon board. Further more, a given base board
> can have several connectors where the exact same addon board can be
> connected. In that case, the same overlay cannot be used on both
> connector. Indeed, the connector labels have to be different.
>
> The export-symbols node introduced by this current series solves this
> issue.
>
> The idea of export-symbols is to have something similar to the global
> __symbols__ node but local to a specific node. Symbols listed in this
> export-symbols are local and visible only when an overlay is applied on
> a node having an export-symbols subnode.
>
> Using export-symbols, our example becomes:
>     soc_gpio: gpio-controller {
>       #gpio-cells = <2>;
>     };
>
>     connector1: connector1 {
>         /*
>          * Nexus node for the GPIO available on the connector.
>          * GPIO 0 (Pin A GPIO) is connected to GPIO 12 of the SoC gpio
>          * controller
>          */
>         #gpio-cells = <2>;
>         gpio-map = <0 0 &soc_gpio 12 0>;
>         gpio-map-mask = <0xf 0x0>;
>         gpio-map-pass-thru = <0x0 0xf>;
>
>         export-symbols {
>           connector = <&connector1>;
>         };
>     };
>
> With that export-symbols node, an overlay applied on connector1 node can
> have the symbol named 'connector' resolved to connector1. Indeed, the
> export-symbols node available at connector1 node is used when the
> overlay is applied. If the overlay has an unresolved 'connector' symbol,
> it will be resolved to connector1 thanks to export-symbols.
>
> Our overlay using the nexus node can contains:
>    node {
>       foo-gpio = <&connector 0 GPIO_ACTIVE_HIGH>;
>    };

Couldn't we make something like this work:

connector: __overlay__ {

   node {
      foo-gpio = <&connector 0 GPIO_ACTIVE_HIGH>;
   };
};

We already have to process all the phandles in the overlay. So this
just changes handling of 'connector' from being a local phandle which
we just renumber to an unresolved phandle which we have to lookup and
replace the phandle uses with.

Rob