linux-kernel - Re: [PATCH 2/3] arm64: dts: renesas: r8a77961: Add lvds0 device node

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Thu, 30 Dec 2021 00:12:04 +0300
From:   Nikita Yushchenko <nikita.yoush@...entembedded.com>
To:     Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc:     Geert Uytterhoeven <geert+renesas@...der.be>,
        Magnus Damm <magnus.damm@...il.com>,
        Kieran Bingham <kieran.bingham+renesas@...asonboard.com>,
        David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>,
        Rob Herring <robh+dt@...nel.org>,
        dri-devel@...ts.freedesktop.org, linux-renesas-soc@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] arm64: dts: renesas: r8a77961: Add lvds0 device node

  Endpoints are meant to model a link between two ports, so an endpoint
> shouldn't exist in isolation. The issue with creating named endpoints in
> SoC files is that you can't tell there what remote devices may exist, so
> the endpoint may or may not match the actual hardware design of a board.
> I think it's better to create endpoints on both sides together in
> overlays.
> 
> https://lore.kernel.org/linux-renesas-soc/20211229193135.28767-2-laurent.pinchart+renesas@ideasonboard.com/T/#t

What I don't like here is: details of particular SoC (such as "panel gets video from port@1 of &lvds1) 
leak into per-panel DT fragment.

This limits possibilities to share DT fragments between different use cases. In the patch pointed by the 
above URL, you have to reference both board and panel in the dts file name.

I'd prefer to make each DT fragment to use only either entities defined in that fragment itself, or 
defined "interface entities" between this and "neighbor" DT fragment.

Such as:
- SoC's DT fragment defines a named port/endpoint to export video stream at
- board's DT fragment defines a named panel node corresponding to panel plugged into board's physical 
connector, and connects endpoints with SoC's video export,
- panel's DT fragment extends the panel node from board with video mode information for this particular 
panel.

And similar for backlight, power, and whatever else exposed on the physical panel connector.

So for the board's physical connector there is a set of board-DT-provided entities for use by DT 
fragment of whatever component plugged to the connector, without direct references to final SoC 
interfaces. And possibility to reuse DT fragments between boards, and probably have a library of DT 
fragments for hardware currently available in the market, usable with different boards where that 
hardware can be connected.

Nikita