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.

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.