[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CADRPPNRhVuHTxTpU8RCBMMTVe2V23pjqt8Z5vV=5efepWk6yPg@mail.gmail.com>
Date: Fri, 1 Oct 2021 12:37:54 -0500
From: Li Yang <leoyang.li@....com>
To: Rob Herring <robh+dt@...nel.org>
Cc: Shawn Guo <shawnguo@...nel.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@...r.kernel.org>,
Oleksij Rempel <linux@...pel-privat.de>,
linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 02/16] dt-bindings: i2c: imx: update schema to align
with original txt binding
On Fri, Oct 1, 2021 at 8:24 AM Rob Herring <robh+dt@...nel.org> wrote:
>
> On Thu, Sep 30, 2021 at 7:04 PM Li Yang <leoyang.li@....com> wrote:
> >
> > When the binding was converted from txt to yaml, it actually added more
> > constrains than the original txt binding which was already used in many
> > in-tree DTSes. Some of the newly added constrains are either not valid
> > or not neccessary.
>
> IMO, both of these should be fixed in the dts files.
>
> > Not all SoCs use ipg as the clock name for i2c. There is no point in
> > having SoC integration information defined in i2c binding. Remove the
> > clock name requirement in the schema.
>
> Any name you want is not fine. Your choices are remove clock-names,
> add all the names used, or change everyone to use 'ipg'.
I understand that the name should be important as clocks are
referenced by name. But since the i2c controller only has one clock ,
the name is never referenced in the driver.
If we really want to define the name, IMO, it should be from the
perspective of the i2c controller like "clkin" or "i2c" instead of the
"ipg" from the perspective of SoC integration which could be changing
with a different integration. I can list both "i2c" and "ipg" for now
as a workaround though.
>
> > The original txt binding didn't require the order of tx and rx for
> > dmas/dma-names. Many in tree DTSes are already using the other order.
> > Both orders should just work fine. Update the schema to allow both.
>
> Doesn't sound like a case where defining the order is challenging.
No, it is not challenging. But as dma channel is only referenced by
name instead of index. I don't see too much benefit in enforcing the
order other than easier to create the schema.
>
> Rob
Powered by blists - more mailing lists