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

[Conor Dooley <conor@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 4200 bytes --]

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!

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.

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ç

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]