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

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

On 13/09/2024 19:13, Conor Dooley wrote:
> On Fri, Sep 13, 2024 at 05:38:44PM +0200, Arınç ÜNAL wrote:
>> 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'm going to require that it is done, by someone, before I ack a
> dt-binding change. I'm also going to require that it's not breaking
> other projects, like U-Boot, that pull in the dt-rebasing repository.
> If you change the ABI, and therefore change the source files, you also
> need to change the users.
> 
> And I would have those requirements whether or not the bindings lie within,
> or outside of, the kernel tree :) Suggesting that decoupling the bindings
> and kernel would allow that to be relaxed is, in my view, silly - it
> would just prevent anyone from being "blindly" able to pull in whatever
> the latest revision of platform devicetree source files is, without
> substantial risk of regressions. That's a downgrade from the status quo
> in my view!

I agree. I have an idea for an approach that will keep the status quo and
allow us to have proper device tree bindings. Allow changing the device
tree binding documents; require the driver to be tested and fixed only if
you're changing the device tree source files. This way, we will have proper
device tree definitions without affecting the users and have upcoming
drivers implement the proper device tree bindings. The non-compliant device
tree source files will get a nice complaint when checked with the bindings,
encouraging to fix them.

We explain on the kernel documentation that if you change the device tree
source file to be compliant with the binding document, you are required to
test the driver and let the maintainers know that there are no regressions.
If there are regressions, a patch to fix the driver must be be included on
the patch series and come after the device tree source file patch.

> 
> The far harder thing to deal with at present is ABI "compliant" changes
> to devicetree source files, for example where a new dedicated clock node
> replaces a set of fixed-clocks, which is something we need platform
> maintainers to become more aware of as use of the dt-rebasing
> repo/OF_UPSTREAM grows in U-Boot.

I think this falls under the case of breaking the ABI to be able to
properly describe the hardware. In any case, I don't see this interfere
with my suggestion.

> 
> Cheers,
> Conor.
> 
>> 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ç

Arınç