All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <jonathan.cameron@huawei.com>
To: Paresh Chaudhary <paresh.chaudhary@rockwellcollins.com>
Cc: <jic23@kernel.org>,
	Matthew Weber <matthew.weber@rockwellcollins.com>,
	<linux-iio@vger.kernel.org>, <knaack.h@gmx.de>, <lars@metafoo.de>,
	<pmeerw@pmeerw.net>
Subject: Re: [PATCH v2 1/2] iio:temperature: Add MAX31856 thermocouple support
Date: Fri, 2 Nov 2018 09:33:35 +0000	[thread overview]
Message-ID: <20181102093335.000042d9@huawei.com> (raw)
In-Reply-To: <CAGSBOwZ-KfbGDrOHZqDd6piXJOCG2zdwjJ5naCrTBKvXtS_mgQ@mail.gmail.com>

Just the one outstanding discussion I think so I've heavily cropped the email..

On Tue, 16 Oct 2018 10:28:40 -0500
Paresh Chaudhary <paresh.chaudhary@rockwellcollins.com> wrote:

> > > +static int max31856_probe(struct spi_device *spi)
> > > +{
> > > +     const struct spi_device_id *id = spi_get_device_id(spi);
> > > +     struct iio_dev *indio_dev;
> > > +     struct max31856_data *data;
> > > +     int ret;
> > > +
> > > +     indio_dev = devm_iio_device_alloc(&spi->dev, sizeof(*data));
> > > +     if (!indio_dev)
> > > +             return -ENOMEM;
> > > +
> > > +     data = iio_priv(indio_dev);
> > > +     data->spi = spi;
> > > +
> > > +     spi_set_drvdata(spi, indio_dev);
> > > +
> > > +     indio_dev->info = &max31856_info;
> > > +     indio_dev->name = id->name;
> > > +     indio_dev->modes = INDIO_DIRECT_MODE;
> > > +     indio_dev->channels = max31856_channels;
> > > +     indio_dev->num_channels = ARRAY_SIZE(max31856_channels);
> > > +
> > > +     data->one_shot = of_property_read_bool(spi->dev.of_node, "one-shot");  
> >
> > This does not look to me like something that should be controlled in devicetree.
> > Normally we'd switch between oneshot and continuous modes based on some sort
> > of rule such as whether we are doing buffered reads vs polled ones, or perhaps
> > switch to oneshot if there hasn't been a reading taken for a 'while'.
> > (a form of runtime power management).
> >  
>    I am totally agree with your runtime power management concern but
> as of now, current
>    driver does not have support for runtime coversion mode change.

So to make this clear as we are going in circles, what I am saying is that
until you implement some dynamic control you need to make a decision on
which mode to support and only support one of them.

We do not want this property in the devicetree bindings at all as we will
then have to work with it forever and it is control that does not belong
there.  It is not a function of the board design, it is a policy decision.

> > > +
> > > +     ret = of_property_read_u32(spi->dev.of_node, "type",
> > > +                                &data->thermocouple_type);
> > > +
> > > +     if (ret) {
> > > +             pr_info("Could not read thermocouple type DT property, Configuring as a K-Type\n");
> > > +             data->thermocouple_type = 0x03; /* K-Type */
> > > +     }
> > > +
> > > +     ret = max31856_init(data);
> > > +     if (ret) {
> > > +             pr_err("error: Failed to configure max31856\n");
> > > +             return ret;
> > > +     }
> > > +

      reply	other threads:[~2018-11-02 18:40 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-11 16:38 [PATCH v2 1/2] iio:temperature: Add MAX31856 thermocouple support Matt Weber
2018-10-11 16:38 ` [PATCH v2 2/2] iio:temperature:max31856:Add device tree bind info Matt Weber
2018-10-13 13:54   ` Jonathan Cameron
2018-10-16 22:16     ` Paresh Chaudhary
2018-10-21 14:19       ` Jonathan Cameron
2018-10-13 13:51 ` [PATCH v2 1/2] iio:temperature: Add MAX31856 thermocouple support Jonathan Cameron
2018-10-15 22:27   ` Paresh Chaudhary
2018-10-16 15:28   ` Paresh Chaudhary
2018-11-02  9:33     ` Jonathan Cameron [this message]

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=20181102093335.000042d9@huawei.com \
    --to=jonathan.cameron@huawei.com \
    --cc=jic23@kernel.org \
    --cc=knaack.h@gmx.de \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=matthew.weber@rockwellcollins.com \
    --cc=paresh.chaudhary@rockwellcollins.com \
    --cc=pmeerw@pmeerw.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.