Re: [MAINTAINERS SUMMIT] State of dt-bindings and DT source files, and invitation request

["Arınç ÜNAL" <arinc.unal@arinc9.com>]

On 13 September 2024 10:08:41 CEST, David Woodhouse <dwmw2@infradead.org> wrote:
>On Thu, 2024-09-12 at 15:57 +0300, Arınç ÜNAL wrote
>> Over the course of years, I've had maintainers resisting to or completely
>> blocking my changes on the device tree definitions because of Linux driver
>> related reasons. I couldn't have patches that fixed incorrect hardware
>> definitions to be applied, because the maintainer would demand a change on
>> Linux driver to happen beforehand. I've stumbled upon misconceptions such
>> as thinking that a Linux driver change could break ABI. In reality, that is
>> nonsense because a driver change represents the implementation being
>> changed, not the bindings. The implementation change can only be so that it
>> breaks compliance with the bindings.
>
>
>We should be careful here.
>
>The device-tree bindings are the definition of the ABI. But they are
>only words; what matters is the interface between the DT blob itself
>and the OS drivers which interpret them.
>
>If we want to *change* that ABI in a way which breaks users of it, then
>of *course* we have to consider a transition path for those users.
>
>That's true of *any* ABI, be it a command line, a library ABI, or the
>device-tree bindings.

First, let's agree on the two cases of changing the ABI. You either add
new properties and rules (let's call them definitions) to describe the
hardware more in detail, or you change the existing definitions which
would break the ABI. As it's irrelevant to my point, I'll simplify the
valid reasons to break the ABI as: The existing definitions wouldn't allow
the hardware to be properly described.

>
>So where you say, "blocking my changes on the device tree definitions
>because of Linux driver related reasons", that isn't necessarily wrong.
>A breaking change to an ABI *needs* to have a transition plan for how
>its users get from old to new without a flag day.

This is a concern for the Linux kernel. If we demand the compliance of the
Linux kernel with the changed device tree definitions from the people that
made the change, then we can't talk about a complete autonomy of the
device tree development from the Linux kernel development. I should be
able to submit patches with the only goal of adding or fixing hardware
definitions. Either I've broken the ABI with a valid reason or added
hardware definitions, I must not be forced to do Linux kernel development
for my device tree patches to be applied. I should not need to know the C
language to do device tree work. If we want more folks to do device tree
janitor work, let's not add in unnecessary requirements.

Device tree definitions are not just for being compiled into a blob for
drivers to interpret. For example, I do regularly read device tree
definitions to learn about the hardware being described. So it has a use
for documentation as well.

Arınç