| 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
| ||
|
Message-ID: <bea47f98-30ed-47d1-a1a2-0b56d4133bad@beagleboard.org>
Date: Tue, 10 Dec 2024 15:00:23 +0530
From: Ayush Singh <ayush@...gleboard.org>
To: Andrew Davis <afd@...com>, Herve Codina <herve.codina@...tlin.com>
Cc: Geert Uytterhoeven <geert@...ux-m68k.org>, Rob Herring <robh@...nel.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 09/12/24 23:17, Andrew Davis wrote:
> On 12/9/24 11:03 AM, Herve Codina wrote:
>> On Mon, 9 Dec 2024 10:47:50 -0600
>> Andrew Davis <afd@...com> wrote:
>>
>>> On 12/9/24 9:18 AM, Herve Codina 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>;
>>>> };
>>>> It used the GPIO 0 from the connector it is applied on.
>>>>
>>>> A board with two connectors can be described with:
>>>> connector1: connector1 {
>>>> ...
>>>> export-symbols {
>>>> connector = <&connector1>;
>>>> };
>>>> };
>>>>
>>>> connector2: connector2 {
>>>> ...
>>>> export-symbols {
>>>> connector = <&connector2>;
>>>> };
>>>> };
>>>>
>>>> In that case, the same overlay with unresolved 'connector' symbol
>>>> can be
>>>> applied on both connectors and the correct symbol resolution
>>>> (connector1
>>>> or connector2) will be done.
>>>
>>> I might be missing something, but how is the correct connector
>>> (connector1
>>> or connector2) selected? Let's say I connect my addon board to
>>> connector2,
>>> then I apply the addon board's overlay to the base DTB. What connector
>>> just got referenced?
>>>
>>
>> A driver for the connector is needed.
>> The driver applies the overlay using of_overlay_fdt_apply().
>> The node the overlay has to be applied to is passed by the driver to
>> of_overlay_fdt_apply().
>>
>
> So every connector needs a driver? Most connectors are dumb connectors,
> just a bunch of wires broken out to a header.
>
> What if an addon board overlay uses multiple connectors?
>
> If you need a connector-specific driver, and that driver needs to know
> which node this overlay will be applied to, then why not just do a
> fixup directly to the overlay in the driver?
>
> Andrew
Well, even in the symbols based approach, a driver is needed since stuff
like nexus nodes does need a dummy driver (else the device enters
deferred probing). So it is not a big deal.
>
>> Even if obsolete because I added one more parameter (export_symbols_name)
>> in of_overlay_fdt_apply() in this current series, you can have a look
>> at the
>> following patch to see the connector driver:
>> https://lore.kernel.org/lkml/20240917-hotplug-drm-bridge-v4-8-
>> bc4dfee61be6@...tlin.com/
>>
>> Best regards,
>> Hervé
>>
Ayush Singh
Powered by blists - more mailing lists