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;
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <CAL_JsqJou=yHsyQB+TUvwbNHDh81g7Lm7oWJfavYmPuYtxhREQ@mail.gmail.com>
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> <CAL_JsqJou=yHsyQB+TUvwbNHDh81g7Lm7oWJfavYmPuYtxhREQ@mail.gmail.com>
Subject: Re: [PATCH v3 01/15] dt-bindings: iio: Add bindings for sx9310 sensor
From:   Stephen Boyd <swboyd@chromium.org>
Cc:     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>, ;
Illegal-Object: Syntax error in Cc: address found on vger.kernel.org:
        Cc:     ;
                        ^-missing semicolon to end mail group, extraneous tokens in mailbox, missing end of mailbox
To:     Jonathan Cameron <jic23@kernel.org>,
        Rob Herring <robh+dt@kernel.org>
Date:   Thu, 06 Aug 2020 16:03:35 -0700
Message-ID: <159675501533.1360974.12010874193333451805@swboyd.mtv.corp.google.com>
User-Agent: alot/0.9.1
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Quoting Rob Herring (2020-08-06 15:12:34)
> 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> wro=
te:
> > > >
> > > > This is mostly a decision for Rob to make, but I would make it requ=
ired
> > > > 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 forgott=
en
> > one of course!)
>=20
> 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.
>=20

I was thinking that a WiFi DT node may directly grab the channel from
this device and use this for SAR power changes. That would avoid going
all the way to userspace to figure out that something is close proximity
and then tell WiFi to reduce power.