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-tapir-of-astonishing-artistry-ad0bd8@houat>
Date: Mon, 30 Jun 2025 12:45:07 +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 11:36:51AM +0200, Krzysztof Kozlowski wrote:
> On 30/06/2025 10:38, Maxime Ripard wrote:
> > 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.
> 
> Hm? In ARM world at least they are specific, e.g. they have specific
> compatibles.
> 
> > 
> > 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
> 
> You touch internal parts of the SoC and you list very specific SoC
> parts. Interconnect is internal part of the SoC and only specific
> devices are using it.
> 
> You define here generic SW construct for something which is opposite of
> generic: the interconnect connecting two specific, unique components of
> one, given SoC.
> 
> > the framebuffer, Linux just uses it. Just like you don't have a
> > device/platform specific compatible for PSCI, SCPI, et al.
> 
> They follow some sort of spec and still they do not reference chosen
> SoC-design-specific properties.

ish.

I mean, on theory, you're absolutely correct. In practice,
assigned-clock-parents, assigned-clock-rates, or protected-clocks for
example exist and are *only* about SoC-design specific behaviours.

Maxime

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