From: Jonathan Cameron <jic23@kernel.org>
To: Matheus Tavares <matheus.bernardino@usp.br>
Cc: Mark Rutland <mark.rutland@arm.com>,
devel@driverdev.osuosl.org, Lars-Peter Clausen <lars@metafoo.de>,
Michael Hennerich <Michael.Hennerich@analog.com>,
devicetree@vger.kernel.org, linux-iio@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Mark Brown <broonie@kernel.org>,
linux-kernel@vger.kernel.org, kernel-usp@googlegroups.com,
Rob Herring <robh+dt@kernel.org>,
Peter Meerwald-Stadler <pmeerw@pmeerw.net>,
Hartmut Knaack <knaack.h@gmx.de>,
Alexandru Ardelean <alexandru.ardelean@analog.com>,
victorcolombo@gmail.com
Subject: Re: [PATCH 2/6] staging:iio:ad2s90: Remove spi setup that should be done via dt
Date: Sun, 11 Nov 2018 11:42:24 +0000 [thread overview]
Message-ID: <20181111114224.1d8cfaec@archlinux> (raw)
In-Reply-To: <20181109220044.24843-3-matheus.bernardino@usp.br>
On Fri, 9 Nov 2018 20:00:40 -0200
Matheus Tavares <matheus.bernardino@usp.br> wrote:
> The ad2s90 driver currently sets some spi settings (max_speed_hz and
> mode) at ad2s90_probe. This should, instead, be handled via device tree.
> This patch removes these configurations from the probe function.
>
> Note: The way in which the mentioned spi settings need to be specified
> on the ad2s90's node of a device tree will be documented in the future
> patch "dt-bindings:iio:resolver: Add docs for ad2s90".
>
> Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br>
I'd actually like to get Rob and Mark's views on this one. Previously
I would just have applied it without thinking on the basis these can
be easily specified from devicetree.
Recent discussions with Rob have suggested that the settings in devicetree
should perhaps be concerned with specifying constraints about the device
that are not visible to the driver. The driver itself should apply
the device constraints, but there are others such as wiring that
might reduce the maximum frequency for example...
So should a driver be clamping an over specified value from DT for
example? Or given that is optional in DT, should it be making sure
that a controller max frequency isn't too high for the sensor?
It seems to be unusual to do this, but to my mind it would make
sense and might be worth pushing out into more drivers.
Jonathan
> ---
> drivers/staging/iio/resolver/ad2s90.c | 11 -----------
> 1 file changed, 11 deletions(-)
>
> diff --git a/drivers/staging/iio/resolver/ad2s90.c b/drivers/staging/iio/resolver/ad2s90.c
> index ff32ca76ca00..95c118c48400 100644
> --- a/drivers/staging/iio/resolver/ad2s90.c
> +++ b/drivers/staging/iio/resolver/ad2s90.c
> @@ -77,7 +77,6 @@ static int ad2s90_probe(struct spi_device *spi)
> {
> struct iio_dev *indio_dev;
> struct ad2s90_state *st;
> - int ret;
>
> indio_dev = devm_iio_device_alloc(&spi->dev, sizeof(*st));
> if (!indio_dev)
> @@ -94,16 +93,6 @@ static int ad2s90_probe(struct spi_device *spi)
> indio_dev->num_channels = 1;
> indio_dev->name = spi_get_device_id(spi)->name;
>
> - /* need 600ns between CS and the first falling edge of SCLK */
> - spi->max_speed_hz = 830000;
> - spi->mode = SPI_MODE_3;
> - ret = spi_setup(spi);
> -
> - if (ret < 0) {
> - dev_err(&spi->dev, "spi_setup failed!\n");
> - return ret;
> - }
> -
> return devm_iio_device_register(indio_dev->dev.parent, indio_dev);
> }
>
next prev parent reply other threads:[~2018-11-11 11:42 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-09 22:00 [PATCH 0/6] staging:iio:ad2s90: Add dt support and move out of staging Matheus Tavares
2018-11-09 22:00 ` [PATCH 1/6] staging:iio:ad2s90: Add device tree support Matheus Tavares
2018-11-09 22:00 ` [PATCH 2/6] staging:iio:ad2s90: Remove spi setup that should be done via dt Matheus Tavares
2018-11-11 11:42 ` Jonathan Cameron [this message]
2018-11-15 14:44 ` Matheus Tavares Bernardino
2018-11-16 18:37 ` Jonathan Cameron
2018-11-09 22:00 ` [PATCH 3/6] staging:iio:ad2s90: Add max frequency check at probe Matheus Tavares
2018-11-11 11:46 ` Jonathan Cameron
2018-11-09 22:00 ` [PATCH 4/6] dt-bindings:iio:resolver: Add docs for ad2s90 Matheus Tavares
2018-11-11 11:48 ` Jonathan Cameron
2018-11-17 3:29 ` Matheus Tavares Bernardino
2018-11-09 22:00 ` [PATCH 5/6] staging:iio:ad2s90: Add SPDX license identifier Matheus Tavares
2018-11-09 22:13 ` Fabio Estevam
2018-11-09 23:19 ` Matheus Tavares Bernardino
2018-11-10 0:20 ` Greg Kroah-Hartman
2018-11-10 0:27 ` Matheus Tavares Bernardino
2018-11-10 13:22 ` Fabio Estevam
2018-11-10 18:23 ` Matheus Tavares Bernardino
2018-11-09 22:00 ` [PATCH 6/6] staging:iio:ad2s90: Move out of staging Matheus Tavares
2018-11-11 11:31 ` Jonathan Cameron
2018-11-11 11:34 ` [PATCH 0/6] staging:iio:ad2s90: Add dt support and move " 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=20181111114224.1d8cfaec@archlinux \
--to=jic23@kernel.org \
--cc=Michael.Hennerich@analog.com \
--cc=alexandru.ardelean@analog.com \
--cc=broonie@kernel.org \
--cc=devel@driverdev.osuosl.org \
--cc=devicetree@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=kernel-usp@googlegroups.com \
--cc=knaack.h@gmx.de \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=matheus.bernardino@usp.br \
--cc=pmeerw@pmeerw.net \
--cc=robh+dt@kernel.org \
--cc=victorcolombo@gmail.com \
/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).