Linux IIO development
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Angelo Dureghello <adureghello@baylibre.com>
Cc: Lars-Peter Clausen <lars@metafoo.de>,
	Michael Hennerich <Michael.Hennerich@analog.com>,
	Mihail Chindris <mihail.chindris@analog.com>,
	Nuno Sa <nuno.sa@analog.com>,
	David Lechner <dlechner@baylibre.com>,
	Olivier Moysan <olivier.moysan@foss.st.com>,
	Jonathan Cameron <Jonathan.Cameron@huawei.com>,
	linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 6/8] iio: dac: ad3552r-hs: exit for error on wrong chip id
Date: Thu, 19 Dec 2024 16:54:46 +0000	[thread overview]
Message-ID: <20241219165446.7b8d0a9a@jic23-huawei> (raw)
In-Reply-To: <20241216-wip-bl-ad3552r-axi-v0-iio-testing-carlos-v1-6-856ff71fc930@baylibre.com>

On Mon, 16 Dec 2024 21:36:26 +0100
Angelo Dureghello <adureghello@baylibre.com> wrote:

> From: Angelo Dureghello <adureghello@baylibre.com>
> 
> Exit for error on wrong chip id, otherwise driver continues
> with wrong assumptions.
Why? Chip ID does not define all future compatible parts, just the
ones we know about today.

The reason not failing is that the moment we do exit on a mismatch
we can never support fallback device tree compatible IDs.  Is there
no chance that ADI will release a backwards compatible part in the
future that we'd like to work with old kernels?

Any mismatch in DT vs hardware present is considered a firmware
bug, not a kernel problem.
We used to reject missmatched IDs but after a long discussion with
DT maintainers it became clear that broke their model.

Thanks,

Jonathan

> 
> Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
> ---
>  drivers/iio/dac/ad3552r-hs.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/iio/dac/ad3552r-hs.c b/drivers/iio/dac/ad3552r-hs.c
> index 8974df625670..e613eee7fc11 100644
> --- a/drivers/iio/dac/ad3552r-hs.c
> +++ b/drivers/iio/dac/ad3552r-hs.c
> @@ -326,8 +326,9 @@ static int ad3552r_hs_setup(struct ad3552r_hs_state *st)
>  
>  	id |= val << 8;
>  	if (id != st->model_data->chip_id)
> -		dev_info(st->dev, "Chip ID error. Expected 0x%x, Read 0x%x\n",
> -			 AD3552R_ID, id);
> +		return dev_err_probe(st->dev, -ENODEV,
> +				     "chip id error, expected 0x%x, got 0x%x\n",
> +				     st->model_data->chip_id, id);
>  
>  	/* Clear reset error flag, see ad3552r manual, rev B table 38. */
>  	ret = st->data->bus_reg_write(st->back, AD3552R_REG_ADDR_ERR_STATUS,
> 


  reply	other threads:[~2024-12-19 16:54 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-16 20:36 [PATCH 0/8] iio: ad3552r-hs: add support for ad3541/42r Angelo Dureghello
2024-12-16 20:36 ` [PATCH 1/8] iio: dac: ad3552r-common: fix ad3541/2r ranges Angelo Dureghello
2024-12-19 16:44   ` Jonathan Cameron
2024-12-16 20:36 ` [PATCH 2/8] iio: dac: ad3552r-hs: clear reset status flag Angelo Dureghello
2024-12-19 16:45   ` Jonathan Cameron
2024-12-16 20:36 ` [PATCH 3/8] iio: dac: adi-axi-dac: modify stream enable Angelo Dureghello
2024-12-16 20:36 ` [PATCH 4/8] iio: backend: add API for interface configuration Angelo Dureghello
2024-12-17 10:13   ` Nuno Sá
2024-12-19 16:42     ` Jonathan Cameron
2024-12-19 16:51       ` Jonathan Cameron
2024-12-19 17:01         ` David Lechner
2024-12-20 12:03           ` Angelo Dureghello
2024-12-16 20:36 ` [PATCH 5/8] iio: dac: adi-axi-dac: add bus mode setup Angelo Dureghello
2024-12-16 20:36 ` [PATCH 6/8] iio: dac: ad3552r-hs: exit for error on wrong chip id Angelo Dureghello
2024-12-19 16:54   ` Jonathan Cameron [this message]
2024-12-20  9:55     ` Conor Dooley
2024-12-20 14:25     ` Angelo Dureghello
2024-12-16 20:36 ` [PATCH 7/8] iio: dac: ad3552r-hs: add ad3541/2r support Angelo Dureghello
2024-12-19 17:08   ` Jonathan Cameron
2024-12-16 20:36 ` [PATCH 8/8] iio: dac: ad3552r-hs: update function name (non functional) Angelo Dureghello

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=20241219165446.7b8d0a9a@jic23-huawei \
    --to=jic23@kernel.org \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=Michael.Hennerich@analog.com \
    --cc=adureghello@baylibre.com \
    --cc=dlechner@baylibre.com \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mihail.chindris@analog.com \
    --cc=nuno.sa@analog.com \
    --cc=olivier.moysan@foss.st.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