linux-kernel - Re: [PATCH 05/21] ARM: dts: omap: Bind panel to panel-dpi instead of ti,tilcdc,panel driver

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: <c6ae49de-d1e3-4f9c-b9d0-95cf7a9d9815@kernel.org>
Date: Tue, 2 Dec 2025 13:19:08 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Kory Maincent <kory.maincent@...tlin.com>
Cc: Tomi Valkeinen <tomi.valkeinen@...asonboard.com>,
 Markus Schneider-Pargmann <msp@...libre.com>,
 Luca Ceresoli <luca.ceresoli@...tlin.com>,
 Louis Chauvet <louis.chauvet@...tlin.com>,
 Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
 Miguel Gazquez <miguel.gazquez@...tlin.com>,
 dri-devel@...ts.freedesktop.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 linux-omap@...r.kernel.org, Jyri Sarha <jyri.sarha@....fi>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>, 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>, Russell King <linux@...linux.org.uk>,
 Bartosz Golaszewski <brgl@...ev.pl>, Tony Lindgren <tony@...mide.com>,
 Andrzej Hajda <andrzej.hajda@...el.com>,
 Neil Armstrong <neil.armstrong@...aro.org>, Robert Foss <rfoss@...nel.org>,
 Laurent Pinchart <Laurent.pinchart@...asonboard.com>,
 Jonas Karlman <jonas@...boo.se>, Jernej Skrabec <jernej.skrabec@...il.com>
Subject: Re: [PATCH 05/21] ARM: dts: omap: Bind panel to panel-dpi instead of
 ti,tilcdc,panel driver

On 02/12/2025 12:18, Kory Maincent wrote:
> On Tue, 2 Dec 2025 11:47:40 +0100
> Krzysztof Kozlowski <krzk@...nel.org> wrote:
> 
>> On 02/12/2025 11:44, Kory Maincent wrote:
>>> On Tue, 2 Dec 2025 11:28:55 +0100
>>> Krzysztof Kozlowski <krzk@...nel.org> wrote:
>>>   
>>>> On 02/12/2025 10:42, Kory Maincent wrote:  
>>>>>      
>>>>>> Stuffing DTS change in the middle of the driver change tries to hide
>>>>>> impact, which is not nice on its own.    
>>>>>
>>>>> As it needs driver change before the removal for not breaking things it
>>>>> can't be done at the beginning of the series.    
>>>>
>>>> And that is the problem which should stop you there and rethink how to
>>>> organize it without impacting users. DTS cannot go via DRM. If that was
>>>> your intention, that's my:
>>>>
>>>> NAK  
>>>
>>> My intention was to raise discussion over the ugly and legacy tilcdc-panel
>>> binding and what to do with it. But it seems you don't want to, that's a
>>> shame.  
>>
>> I don't see how you get to these conclusions. I comment that putting
>> here DTS in the middle without any explanation of the impact is not
>> correct and this one alone I disagree with.
> 
> Because you didn't replied to the first line of my answer:
> "Yes, I know this but I still wanted to try and begin a discussion on this, as I
> really thought it is not a good idea to add and maintain an new non-standard
> panel driver solely for this tilcdc panel binding."
> 
> But indeed you are right, I should have put more explanation on why there is DTS
> and binding change in the middle of the series. Sorry for that.
>  
>> From that you claim I don't want to fix things...
>>
>> DTS cannot go to drm, which means you either need to separate the change
>> and make entire work bisectable and backwards compatible for some time
>> OR at least document clearly the impact as we always ask.
> 
> The thing is, if I split it, it has to be in 3. One for the of DRM bus flags
> support, a second for the the devicetree and binding change and a third for the
> whole tilcdc and tda998x cleaning stuff. I think I will go for one series, with
> better documentation.
> 
> Now, what is your point of view on my question. Will you nak any binding
> removal even if the binding is ugly and legacy and imply maintaining an
> non-standard tilcdc panel driver? I know it breaks DTB compatibility but there
> is several argument to not keep it. See patch 6.

I will not NAK, removing bindings and breaking users is under some
conditions acceptable. You just need to come with the reasons and impact.

Reason "is ugly" is usually not good enough. Especially if things were
working.

Best regards,
Krzysztof