On Fri, Sep 13, 2024 at 05:38:44PM +0200, Arınç ÜNAL wrote: > On 13 September 2024 10:08:41 CEST, David Woodhouse 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ç