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

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

On 19/09/2024 17:55, Rob Herring wrote:
> On Sat, Sep 14, 2024 at 8:49 AM Arınç ÜNAL <arinc.unal@arinc9.com> wrote:
>>
>> 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.
> 
> This is not how an ABI works. If you have to change both sides for
> things to work, then you've broken the ABI.
> 
> With no ABI, the order you suggest for the series is backwards. The
> series is not bisectable. That assumes you mean the driver change
> supports a DT with and without the DT change. If not, it's just
> completely broken.

Thanks for pointing that out Rob. Yes, the order should be that the driver
is fixed first to comply with the binding document, then the device tree
source file is fixed to do the same. With that addressed, what's your
opinion on my proposal overall?

Arınç