Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20200731164853.3020946-1-campello@chromium.org>
 <20200731104555.v3.1.I0925046377211b8b6f06764857f03b4ab592bddb@changeid>
 <20200801160639.1410944e@archlinux> <159648122347.1360974.1094560524092762187@swboyd.mtv.corp.google.com>
 <CAL_JsqLs99Q7o32mqZROQSLuaf-_6vVg_wSVbpMr0u3eD9LVEw@mail.gmail.com> <20200806191451.3ce5ec57@archlinux>
In-Reply-To: <20200806191451.3ce5ec57@archlinux>
From:   Rob Herring <robh+dt@kernel.org>
Date:   Thu, 6 Aug 2020 16:12:34 -0600
Message-ID: <CAL_JsqJou=yHsyQB+TUvwbNHDh81g7Lm7oWJfavYmPuYtxhREQ@mail.gmail.com>
Subject: Re: [PATCH v3 01/15] dt-bindings: iio: Add bindings for sx9310 sensor
To:     Jonathan Cameron <jic23@kernel.org>
Cc:     Stephen Boyd <swboyd@chromium.org>,
        Daniel Campello <campello@chromium.org>,
        LKML <devicetree@vger.kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Hartmut Knaack <knaack.h@gmx.de>,
        Lars-Peter Clausen <lars@metafoo.de>,
        Peter Meerwald-Stadler <pmeerw@pmeerw.net>,
        Douglas Anderson <dianders@chromium.org>,
        "open list:IIO SUBSYSTEM AND DRIVERS" <linux-iio@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, Aug 6, 2020 at 12:14 PM Jonathan Cameron <jic23@kernel.org> wrote:
>
> On Mon, 3 Aug 2020 20:01:06 -0600
> Rob Herring <robh+dt@kernel.org> wrote:
>
> > On Mon, Aug 3, 2020 at 1:00 PM Stephen Boyd <swboyd@chromium.org> wrote:
> > >
> > > Quoting Jonathan Cameron (2020-08-01 08:06:39)
> > > > On Fri, 31 Jul 2020 10:48:38 -0600
> > > > Daniel Campello <campello@chromium.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.
>
> That is perhaps a reasonable view point for devices with channels that
> are likely to be used by consumer drivers, but in this particular case we
> are talking about a proximity sensor.  So far I don't think we
> have any consumer drivers for this type of sensor (I might have forgotten
> one of course!)

Indeed, I didn't consider whether it made sense in the first place. So
should it just not be specified at all in this case? I can't really
picture what the usecase for a consumer node would be.

Rob