ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: "Arınç ÜNAL" <arinc.unal@arinc9.com>
To: Conor Dooley <conor@kernel.org>
Cc: Rob Herring <robherring2@gmail.com>,
	ksummit@lists.linux.dev, Krzysztof Kozlowski <krzk@kernel.org>
Subject: Re: [MAINTAINERS SUMMIT] State of dt-bindings and DT source files, and invitation request
Date: Fri, 13 Sep 2024 08:50:14 +0300	[thread overview]
Message-ID: <644df50c-29df-4c2b-804b-fb6a34e89ac3@arinc9.com> (raw)
In-Reply-To: <20240912-marxism-doorway-eac24989e4b4@spud>

On 12/09/2024 20:05, Conor Dooley wrote:
> On Thu, Sep 12, 2024 at 04:01:20PM +0300, Arınç ÜNAL wrote:
>> On 11/09/2024 00:53, Conor Dooley wrote:
>>> On Tue, Sep 10, 2024 at 10:46:03AM -0500, 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.
>>>
>>> What does "fixing DT source files that did not comply" have to do with
>>> Linux, I'm afraid I do not understand what your point is there. The
>>> bindings are the ABI, and fixing incorrect source files would happen
>>> regardless of how the project is hosted?
>>
>> That's exactly what I think. I had a maintainer that argued otherwise is my
>> point. Which is why I want to strengthen the Linux documentation.
> 
> On a bunch of older platforms it's pretty common that the bindings were
> lacklustre or didn't match the devicetree and kernel source code, and in
> those cases (which are almost always text bindings) two outweighs one.
> Ordinarily though, if the kernel or dts don't match the binding they get
> adjusted, and if there are maintainers resisting this, then point them
> our way.
> 
> If things have been wrong for enough time for it to affect users,
> usually the correct thing to do is fix the kernel to support the
> incorrect as well as the correct. The same, however, goes for other
> projects: if something long established is being fixed, the other users
> need to be accounted for, particularly those that automatically import
> from the devicetree-rebasing repository.

The users in mention are the Linux kernel users, of course. So a maintainer
must not demand patches fixing the kernel to support the incorrect to be
submitted before accepting device tree patches; do we agree? This is what I
mean when I say complete autonomy from the Linux kernel development.

Arınç

  reply	other threads:[~2024-09-13  5:50 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-10 10:52 Arınç ÜNAL
2024-09-10 15:46 ` Rob Herring
2024-09-10 21:53   ` Conor Dooley
2024-09-12 13:01     ` Arınç ÜNAL
2024-09-12 15:12       ` Mark Brown
2024-09-12 17:05       ` Conor Dooley
2024-09-13  5:50         ` Arınç ÜNAL [this message]
2024-09-12 12:57   ` Arınç ÜNAL
2024-09-13  8:08     ` David Woodhouse
2024-09-13 15:38       ` Arınç ÜNAL
2024-09-13 16:13         ` Conor Dooley
2024-09-14 13:49           ` Arınç ÜNAL
2024-09-19 14:55             ` Rob Herring
2024-09-20  9:53               ` Arınç ÜNAL

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=644df50c-29df-4c2b-804b-fb6a34e89ac3@arinc9.com \
    --to=arinc.unal@arinc9.com \
    --cc=conor@kernel.org \
    --cc=krzk@kernel.org \
    --cc=ksummit@lists.linux.dev \
    --cc=robherring2@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox