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

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

On 10/09/2024 18:46, Rob Herring wrote:
> On Tue, Sep 10, 2024 at 5:53 AM Arınç ÜNAL<arinc.unal@arinc9.com> wrote:
>> Hello.
>>
>> I maintain the MediaTek DSA subdriver and some devicetree bindings and
>> source files for MediaTek hardware.
>>
>> I am especially interested in the best practices of maintaining dt-bindings
>> and DT source files.
>>
>> There's this false impression with some maintainers that, as the
>> dt-bindings and the DT source files are being hosted on the Linux
>> repository, Linux drivers have influence over the design of bindings or
>> fixing DT source files that did not comply with the bindings.
>>
>> I'd be very interested to be involved in or kick start the efforts to take
>> dt-bindings and DT source files out of the Linux repository into its own,
>> separate repository. I believe, this would be a great step in addressing
>> all the project-dependent bindings of Linux, U-Boot, OpenWrt, and all other
>> projects, to have a single, unified repository to describe all the hardware
>> that exists in the world.
> This! This is precisely why we don't move things out of the kernel.
> The kernel is the location that has the most hardware support in the
> world by far. It is not even close. Really, the only h/w missing are
> things too small to run Linux. And with all that h/w support, comes
> the people who understand the various classes of h/w. Those people are
> not going to come along to a separate project. It would be more work
> and there aren't any maintainers looking for extra work.

Understood. I can only speculate the reasons for having the device tree
binding documents and source files - let's call them device tree
definitions - on the Linux repository in the first place. It seems
convenience was a big if not the only factor.

On top of what you've pointed out, device tree source files are associated
with Linux architecture code. Therefore, there is a single menu to choose
both the architecture code and the device tree. This and the fact that
device tree source files are compiled along with the architecture code is
quite convenient. However, there is a case in which I just want to compile
a source file. I shouldn't need to have anything to do with Linux drivers
to achieve that.

> 
> We already have a separate repository[1]. U-boot has recently
> incorporated it and is happily (AFAIK) using it. It happens to be
> generated from the kernel tree, but what doesn't work for you there?
> I'm happy to discuss what it needs to work better.

The separate repository with the device tree definitions extracted is
excellent. It seems to bring the best of both worlds. I can build a single
device tree binary without having anything to do with the Linux repository.
And the device tree definitions on the Linux repository is kept so the
submissions for them still work through the means laid out by decades of
Linux and device tree development. Though, the repository seems to be
missing the functionality to validate the device tree binding documents and
source files.

However, this doesn't address the fact that device tree definitions have
nothing to do with Linux as a kernel. Because that the device tree
definitions are part of the Linux repository, on the surface, this gives
the false impression that Linux drivers have influence over the device tree
definitions. This is what I am in discontent with.

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.

I understand that developers naturally become maintainers of the device
tree definitions for the hardware they've developed the driver for. So they
may not know better and fall into these false understandings. There are
currently Linux-driver-specific device tree definitions on the repository.
Device tree bindings for "DSA" switches which are actually Ethernet
switches with CPU ports. I hope to address this when I can.

I'd like to improve the Linux documentation so that I can refer to it in
the future instead of arguing the same points with folks every single time.
I'm thinking of making changes on two documents [1] [2]. I intend to
include the points below in these documents.

The device tree binding documents and device tree source files, to be
collectively referred to as the device tree definitions, on the Linux
repository are to be treated completely separately from the Linux kernel
development. The design of the device tree definitions is not to be
influenced by Linux or any other project. That means the device tree
definitions are described first, then the implementation is made by any OS
or project. Maintainers, do not block device tree patches until a patch for
a Linux driver is taken in.

> 
>> I am already working towards this goal by
>> improving the dt-bindings and DT source files on the Linux repository
>> whenever I can.
> That's great, still plenty of work to do there no matter what
> repository is hosting it.

I agree. There is serious, hard work to do here. I'm looking to turn this
into a full time job if there's such interest from Linaro to further employ
folks with experience and interest in this line of work.

> 
>> I must be quite late to make a topic suggestion but I'd be very happy to be
>> able to attend to the maintainers summit. I've already registered for the
>> Linux Plumbers Conference 2024.
> This is probably not a maintainers summit topic. There's a DT BoF
> scheduled already that Krzysztof is running and supporting other
> projects is on the agenda already. I won't be there in person nor will
> I be awake at the scheduled time.

I see it. I'll be there.

Arınç