From: Jonathan Cameron <jic23@kernel.org>
To: Jaakko Koivisto <jmatko@utu.fi>
Cc: "Andreas Klinger" <ak@it-klinger.de>,
"David Lechner" <dlechner@baylibre.com>,
"Nuno Sá" <nuno.sa@analog.com>,
"Andy Shevchenko" <andy@kernel.org>,
linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 4/5] iio: chemical: sgp40: Implement execute_self_test-command
Date: Sun, 8 Nov 2026 01:02:41 +0000 [thread overview]
Message-ID: <20261108010241.649992fc@jic23-hlaptop> (raw)
In-Reply-To: <20261102091258.247402-5-jmatko@utu.fi>
On Mon, 2 Nov 2026 11:12:57 +0200
Jaakko Koivisto <jmatko@utu.fi> wrote:
> Add functionality for running the SGP40 sensor self-test, testing
> the heater and MOX-material.
>
> Datasheet does not clearly state if the chip is completely unusable if
> the test fails. Because of this the driver will try to use the chip
> normally even if the self-test has failed.
>
> If the test fails to run, the driver probe is aborted.
>
> Signed-off-by: Jaakko Koivisto <jmatko@utu.fi>
> ---
> Is it ok to fail the probe if the self-test fails? Currently the driver
> will probe succesfully even if the device is powered down, or does
> not exist at all, so failing the probe is rather significant change
> from current behaviour.
Yes, it is fine to fail. In rare cases where selftest has known
issues such as a tight bound that fails one in a hundred times
we just retry it. If we think self test failing means broken device
then failing probe is definitely fine.
Given your comment on the lack of clarity above, it is reasonable
in this case to print a message but carry on anyway as long
as the test ran!
So to conclude, I think you have the right balance here.
thanks,
Jonathan
> +}
next prev parent reply other threads:[~2026-11-08 1:02 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-02 9:12 [PATCH v2 0/5] iio: chemical: sgp40: add funtions for serial number readback, self-test, and heater control Jaakko Koivisto
2026-11-02 9:12 ` [PATCH v2 1/5] iio: chemical: sgp40: Do not convert I2C errors to EIO Jaakko Koivisto
2026-11-02 9:54 ` Joshua Crofts
2026-11-02 9:12 ` [PATCH v2 2/5] iio: chemical: sgp40: Replace manual locking with guard() Jaakko Koivisto
2026-11-02 10:10 ` Joshua Crofts
2026-11-03 10:01 ` Andy Shevchenko
2026-11-02 9:12 ` [PATCH v2 3/5] iio: chemical: sgp40: Implement get_serial_number-command Jaakko Koivisto
2026-11-02 10:20 ` Joshua Crofts
2026-11-02 9:12 ` [PATCH v2 4/5] iio: chemical: sgp40: Implement execute_self_test-command Jaakko Koivisto
2026-11-02 10:21 ` Joshua Crofts
2026-11-08 1:02 ` Jonathan Cameron [this message]
2026-11-02 9:56 ` [PATCH v2 5/5] iio: chemical: sgp40: Implement turn_heater_off-command Jaakko Koivisto
2026-11-02 10:24 ` Joshua Crofts
2026-11-08 1:05 ` 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=20261108010241.649992fc@jic23-hlaptop \
--to=jic23@kernel.org \
--cc=ak@it-klinger.de \
--cc=andy@kernel.org \
--cc=dlechner@baylibre.com \
--cc=jmatko@utu.fi \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--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
all inboxes | Powered by JetHome®