[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAL_JsqLk3UbrXAymTvLQeeS-ACY7makTVYxa9CetO-G-v3TuqA@mail.gmail.com>
Date: Fri, 23 Feb 2024 09:34:34 -0700
From: Rob Herring <robh@...nel.org>
To: Wolfram Sang <wsa@...nel.org>, Rob Herring <robh@...nel.org>,
Théo Lebrun <theo.lebrun@...tlin.com>,
Linus Walleij <linus.walleij@...aro.org>, Andi Shyti <andi.shyti@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>, Conor Dooley <conor+dt@...nel.org>,
Thomas Bogendoerfer <tsbogend@...ha.franken.de>, linux-arm-kernel@...ts.infradead.org,
linux-i2c@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-mips@...r.kernel.org,
Gregory Clement <gregory.clement@...tlin.com>,
Vladimir Kondratiev <vladimir.kondratiev@...ileye.com>,
Thomas Petazzoni <thomas.petazzoni@...tlin.com>, Tawfik Bayouk <tawfik.bayouk@...ileye.com>
Subject: Re: [PATCH 01/13] dt-bindings: i2c: nomadik: add timeout-usecs
property bindings
On Thu, Feb 22, 2024 at 12:28 PM Wolfram Sang <wsa@...nel.org> wrote:
>
>
> > > @Rob: My memory fails a little bit about these two schemas: we have the
> > > github one for generic bindings, not strictly related to Linux, right?
> >
> > Well, NONE of the bindings are strictly related to linux unless they say
> > 'linux,' prefix.
>
> Ok, right, of course. What I meant was probably: why do we have
> controller bindings in the kernel and schema bindings in a github tree?
Generally the split is common, stable bindings go in dtschema. This is
anything we'd consider should be in the DT spec. Though I have 0 plans
to add anything to the spec because I'd like to generate the spec from
schema. (Not really working on doing that either though). What's
stable? Well, no solid definition there other than not new. So new
things generally go into the kernel tree first.
For device specific bindings, they will never go into dtschema and
will live where the dts files are.
> For me, this is a tad more difficult to maintain. Like
> i2c-controller.yaml file has the "no-detect" binding which IMO is wrong
> in many ways. I rejected the supporting code for Linux.
It was probably added to i2c.txt and I probably said, looks fine, but
add it to dtschema. Then the Linux support got rejected. We can simply
remove it if it is not being used.
This is why I'm generally against moving all the DT stuff out of the
kernel. The reviewing would dry up. I'll try to make sure you see any
future i2c changes. I take either patches on devicetree-spec list or
GH PR. Shockingly, I mainly get GH PR.
Rob
Powered by blists - more mailing lists