[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAL_JsqLs99Q7o32mqZROQSLuaf-_6vVg_wSVbpMr0u3eD9LVEw@mail.gmail.com>
Date: Mon, 3 Aug 2020 20:01:06 -0600
From: Rob Herring <robh+dt@...nel.org>
To: Stephen Boyd <swboyd@...omium.org>
Cc: Daniel Campello <campello@...omium.org>,
Jonathan Cameron <jic23@...nel.org>,
LKML <devicetree@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Hartmut Knaack <knaack.h@....de>,
Lars-Peter Clausen <lars@...afoo.de>,
Peter Meerwald-Stadler <pmeerw@...erw.net>,
Douglas Anderson <dianders@...omium.org>,
"open list:IIO SUBSYSTEM AND DRIVERS" <linux-iio@...r.kernel.org>
Subject: Re: [PATCH v3 01/15] dt-bindings: iio: Add bindings for sx9310 sensor
On Mon, Aug 3, 2020 at 1:00 PM Stephen Boyd <swboyd@...omium.org> wrote:
>
> Quoting Jonathan Cameron (2020-08-01 08:06:39)
> > On Fri, 31 Jul 2020 10:48:38 -0600
> > Daniel Campello <campello@...omium.org> wrote:
> > > diff --git a/Documentation/devicetree/bindings/iio/proximity/semtech,sx9310.yaml b/Documentation/devicetree/bindings/iio/proximity/semtech,sx9310.yaml
> > > new file mode 100644
> > > index 00000000000000..5739074d3592fe
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/iio/proximity/semtech,sx9310.yaml
> > > @@ -0,0 +1,65 @@
> [...]
> > > +
> > > + "#io-channel-cells":
> > > + const: 1
> > > +
> > > +required:
> > > + - compatible
> > > + - reg
> > > + - "#io-channel-cells"
> >
> > Missed this in earlier review (only noticed when I saw whilst santity
> > checking earlier versions.
> >
> > Fairly sure we should only need #io-channel-cells if we have
> > a consumer of a channel somewhere else in DT. So it's not
> > required as far as I can see.
> >
>
> This is mostly a decision for Rob to make, but I would make it required
> because the device is always an io channel provider. It may be that it
> isn't providing anything in the DT to something else in the DT but it is
> providing this information somewhere so always having to spell that out
> is simple and doesn't hurt.
I agree. If the user is split in a board file or overlay, we don't
want to have to be adding it to the provider at that time.
Rob
Powered by blists - more mailing lists