linux-kernel - Re: [PATCH v2 1/5] dt-bindings: display: simple-framebuffer: Add interconnects property

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]

Message-ID: <20250630-stirring-kiwi-of-adventure-8f22ba@houat>
Date: Mon, 30 Jun 2025 10:38:21 +0200
From: Maxime Ripard <mripard@...nel.org>
To: Krzysztof Kozlowski <krzk@...nel.org>
Cc: Hans de Goede <hdegoede@...hat.com>, 
	Luca Weiss <luca.weiss@...rphone.com>, Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, 
	Thomas Zimmermann <tzimmermann@...e.de>, David Airlie <airlied@...il.com>, 
	Simona Vetter <simona@...ll.ch>, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Javier Martinez Canillas <javierm@...hat.com>, Helge Deller <deller@....de>, linux-fbdev@...r.kernel.org, 
	dri-devel@...ts.freedesktop.org, devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/5] dt-bindings: display: simple-framebuffer: Add
 interconnects property

On Mon, Jun 30, 2025 at 10:24:06AM +0200, Krzysztof Kozlowski wrote:
> On 29/06/2025 14:07, Hans de Goede wrote:
> > Hi Krzysztof,
> > 
> > On 28-Jun-25 1:49 PM, Krzysztof Kozlowski wrote:
> >> On 27/06/2025 11:48, Luca Weiss wrote:
> >>> Hi Krzysztof,
> >>>
> >>> On Fri Jun 27, 2025 at 10:08 AM CEST, Krzysztof Kozlowski wrote:
> >>>> On Mon, Jun 23, 2025 at 08:44:45AM +0200, Luca Weiss wrote:
> >>>>> Document the interconnects property which is a list of interconnect
> >>>>> paths that is used by the framebuffer and therefore needs to be kept
> >>>>> alive when the framebuffer is being used.
> >>>>>
> >>>>> Acked-by: Thomas Zimmermann <tzimmermann@...e.de>
> >>>>> Signed-off-by: Luca Weiss <luca.weiss@...rphone.com>
> >>>>> ---
> >>>>>  Documentation/devicetree/bindings/display/simple-framebuffer.yaml | 3 +++
> >>>>>  1 file changed, 3 insertions(+)
> >>>>>
> >>>>> diff --git a/Documentation/devicetree/bindings/display/simple-framebuffer.yaml b/Documentation/devicetree/bindings/display/simple-framebuffer.yaml
> >>>>> index 296500f9da05e296dbbeec50ba5186b6b30aaffc..f0fa0ef23d91043dfb2b220c654b80e2e80850cd 100644
> >>>>> --- a/Documentation/devicetree/bindings/display/simple-framebuffer.yaml
> >>>>> +++ b/Documentation/devicetree/bindings/display/simple-framebuffer.yaml
> >>>>> @@ -79,6 +79,9 @@ properties:
> >>>>>    power-domains:
> >>>>>      description: List of power domains used by the framebuffer.
> >>>>>  
> >>>>> +  interconnects:
> >>>>> +    description: List of interconnect paths used by the framebuffer.
> >>>>> +
> >>>>
> >>>> maxItems: 1, or this is not a simple FB anymore. Anything which needs
> >>>> some sort of resources in unknown way is not simple anymore. You need
> >>>> device specific bindings.
> >>>
> >>> The bindings support an arbitrary number of clocks, regulators,
> >>> power-domains. Why should I artificially limit the interconnects to only
> >>> one?
> >>
> >> And IMO they should not. Bindings are not supposed to be generic.
> > 
> > The simplefb binding is a binding to allow keeping the firmware, e.g.
> > uboot setup framebuffer alive to e.g. show a boot splash until
> > the native display-engine drive loads. Needing display-engine
> > specific bindings totally contradicts the whole goal of 
> 
> No, it does not. DT is well designed for that through expressing
> compatibility. I did not say you cannot have generic fallback for simple
> use case.
> 
> But this (and previous patchset) grows this into generic binding ONLY
> and that is not correct.

Can we have a proper definition of what a correct device tree binding is
then?

It's a bit surprising to have *that* discussion over a binding that is
now well older than a decade now, and while there is definitely some
generic bindings in ePAPR/DT spec, like the CPU ones.

If you don't consider that spec to be correct DT bindings, please
provide a definition of what that is, and / or reasonable alternatives.

Also, no, a device specific binding isn't reasonable here, because we
*don't* have a device. From a technical standpoint, the firmware creates
the framebuffer, Linux just uses it. Just like you don't have a
device/platform specific compatible for PSCI, SCPI, et al.

And from a process standpoint, that driver is typically used years
before we even get to writing a driver for the actual display driver.
And since bindings are far from standard and actually pretty
opionionated, even if we submitted a binding to use a proper binding
without having a clear idea of what the hardware is, or what a driver
would want, we would end up with either a broken binding, or a broken
driver.

Maxime

Download attachment "signature.asc" of type "application/pgp-signature" (274 bytes)