public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Dan Carpenter <error27@gmail.com>
Cc: "Maxwell Doose" <m32285159@gmail.com>,
	lars@metafoo.de, Michael.Hennerich@analog.com,
	gregkh@linuxfoundation.org,
	"David Lechner" <dlechner@baylibre.com>,
	"Nuno Sá" <nuno.sa@analog.com>,
	"Andy Shevchenko" <andy@kernel.org>,
	linux-iio@vger.kernel.org, linux-staging@lists.linux.dev,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] staging: iio: adt7316: Add error handling to adt7316_spi_probe()
Date: Mon, 27 Apr 2026 11:02:15 +0100	[thread overview]
Message-ID: <20260427110215.1d3eb495@jic23-huawei> (raw)
In-Reply-To: <ae8b6wdyNR-G-i1m@stanley.mountain>

On Mon, 27 Apr 2026 11:18:51 +0300
Dan Carpenter <error27@gmail.com> wrote:

> On Sun, Apr 26, 2026 at 03:50:38PM -0500, Maxwell Doose wrote:
> > Currently, the return values of the adt7316_spi_write() calls in
> > adt7316_spi_probe() are unchecked. Add error handling to return early
> > and pass on the error code if we receive an error from
> > adt7316_spi_write().
> > 
> > While at it, move all three adt7316_spi_write() calls inside a for loop
> > to condense the logic.
> > 
> > Signed-off-by: Maxwell Doose <m32285159@gmail.com>
> > ---  
> 
> A lot of the time, functions can't fail or if they do it means
> you need to buy a new computer and there is nothing the
> operating system can do to help you.  spi_write() feels like
> one of those things.

We do normally check spi and i2c writes.  Though given spi doesn't
have known markers like I2C does, it's not always clear we can detect
an error.  However, these are 'special' as the comment above makes
clear. Device is in i2c mode and a magic SPI hammering sequence is
used to make it switch. For this sort of stuff all bets are off.
If it were the other way around we'd definitely expect errors from
the i2c transfers - though as mentioned above it is really hard
to tell if SPI failed.

Anyhow as far as I'm concerned adding checks to normal calls is
fine, but not to things around reset, mode switches or power
management unless you can test them.


> 
> Plus we wouldn't add new checks like this unless they had been
> tested.
> 
> regards,
> dan carpenter
> 


  reply	other threads:[~2026-04-27 10:02 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-26 20:50 [PATCH] staging: iio: adt7316: Add error handling to adt7316_spi_probe() Maxwell Doose
2026-04-27  8:18 ` Dan Carpenter
2026-04-27 10:02   ` Jonathan Cameron [this message]
2026-04-27 12:38     ` Maxwell Doose
2026-04-27  8:32 ` Andy Shevchenko
2026-04-27  9:59 ` 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=20260427110215.1d3eb495@jic23-huawei \
    --to=jic23@kernel.org \
    --cc=Michael.Hennerich@analog.com \
    --cc=andy@kernel.org \
    --cc=dlechner@baylibre.com \
    --cc=error27@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=m32285159@gmail.com \
    --cc=nuno.sa@analog.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