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: <b9f010ca-1564-4a3a-b004-ef179d5c90a6@kernel.org>
Date: Mon, 30 Jun 2025 11:36:51 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Maxime Ripard <mripard@...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 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.



Best regards,
Krzysztof