From: Stephen Boyd <swboyd@chromium.org>
To: Jonathan Cameron <jic23@kernel.org>, Rob Herring <robh+dt@kernel.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>,
;
Subject: Re: [PATCH v3 01/15] dt-bindings: iio: Add bindings for sx9310 sensor
Date: Thu, 06 Aug 2020 16:03:35 -0700 [thread overview]
Message-ID: <159675501533.1360974.12010874193333451805@swboyd.mtv.corp.google.com> (raw)
In-Reply-To: <CAL_JsqJou=yHsyQB+TUvwbNHDh81g7Lm7oWJfavYmPuYtxhREQ@mail.gmail.com>
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> wrote:
> > > >
> > > > 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.
>
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.
next prev parent reply other threads:[~2020-08-06 23:03 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-31 16:48 [PATCH v3 00/15] sx9310 iio driver updates Daniel Campello
2020-07-31 16:48 ` [PATCH v3 01/15] dt-bindings: iio: Add bindings for sx9310 sensor Daniel Campello
2020-07-31 22:47 ` Rob Herring
2020-08-01 15:06 ` Jonathan Cameron
2020-08-03 19:00 ` Stephen Boyd
2020-08-04 2:01 ` Rob Herring
2020-08-06 18:14 ` Jonathan Cameron
2020-08-06 22:12 ` Rob Herring
2020-08-06 23:03 ` Stephen Boyd [this message]
2020-07-31 16:48 ` [PATCH v3 02/15] iio: sx9310: Update macros declarations Daniel Campello
2020-08-01 14:47 ` Jonathan Cameron
2020-07-31 16:48 ` [PATCH v3 03/15] iio: sx9310: Fix irq handling Daniel Campello
2020-07-31 18:03 ` Stephen Boyd
2020-07-31 18:35 ` Andy Shevchenko
2020-07-31 16:48 ` [PATCH v3 04/15] iio: sx9310: Remove acpi and of table macros Daniel Campello
2020-07-31 16:48 ` [PATCH v3 05/15] iio: sx9310: Change from .probe to .probe_new Daniel Campello
2020-07-31 16:48 ` [PATCH v3 06/15] iio: sx9310: Fixes various memory handling Daniel Campello
2020-07-31 19:24 ` Andy Shevchenko
2020-08-01 14:52 ` Jonathan Cameron
2020-07-31 16:48 ` [PATCH v3 07/15] iio: sx9310: Use long instead of int for channel bitmaps Daniel Campello
2020-07-31 18:38 ` Stephen Boyd
2020-07-31 16:48 ` [PATCH v3 08/15] iio: sx9310: Use regmap_read_poll_timeout() for compensation Daniel Campello
2020-07-31 18:39 ` Stephen Boyd
2020-07-31 16:48 ` [PATCH v3 09/15] iio: sx9310: Update copyright Daniel Campello
2020-07-31 16:48 ` [PATCH v3 10/15] iio: sx9310: Simplify error return handling Daniel Campello
2020-07-31 16:48 ` [PATCH v3 11/15] iio: sx9310: Use variable to hold &client->dev Daniel Campello
2020-07-31 16:48 ` [PATCH v3 12/15] iio: sx9310: Miscellaneous format fixes Daniel Campello
2020-07-31 16:48 ` [PATCH v3 13/15] iio: sx9310: Drop channel_users[] Daniel Campello
2020-07-31 16:48 ` [PATCH v3 14/15] iio: sx9310: Enable vdd and svdd regulators at probe Daniel Campello
2020-07-31 16:48 ` [PATCH v3 15/15] iio: sx9310: Use irq trigger flags from firmware Daniel Campello
2020-07-31 19:46 ` Andy Shevchenko
2020-08-01 15:01 ` Jonathan Cameron
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=159675501533.1360974.12010874193333451805@swboyd.mtv.corp.google.com \
--to=swboyd@chromium.org \
--cc=campello@chromium.org \
--cc=devicetree@vger.kernel.org \
--cc=dianders@chromium.org \
--cc=jic23@kernel.org \
--cc=knaack.h@gmx.de \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pmeerw@pmeerw.net \
--cc=robh+dt@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).