From: Jonathan Cameron <jic23@kernel.org>
To: David Lechner <dlechner@baylibre.com>
Cc: Wadim Mueller <wafgo01@gmail.com>,
krzk+dt@kernel.org, robh@kernel.org, conor+dt@kernel.org,
nuno.sa@analog.com, andy@kernel.org, maxwell@maxwelld.cc,
linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, marcelo.schmitt1@gmail.com,
455.rodrigo.alencar@gmail.com
Subject: Re: [PATCH v6 4/4] iio: flow: add Sensirion SLF3S liquid flow sensor driver
Date: Sun, 2 Aug 2026 18:19:20 +0100 [thread overview]
Message-ID: <20260802181920.3cc8a259@jic23-huawei> (raw)
In-Reply-To: <1555adce-4cce-45c5-b3bc-1898d1bab46b@baylibre.com>
On Sun, 2 Aug 2026 11:07:27 -0500
David Lechner <dlechner@baylibre.com> wrote:
> On 7/28/26 4:49 PM, Wadim Mueller wrote:
> > Add a driver for the Sensirion SLF3S family of digital
> > liquid-flow sensors on I2C. Currently supported variants are
> > SLF3S-0600F, SLF3S-1300F and SLF3S-4000B; they share the same
> > register map and differ only in flow-scale factor and calibrated
> > measurement range. The variant (and therefore the scale) is
> > auto-detected from the product-information register at probe time;
> > a sensor reporting an unknown sub-type falls back to the variant
> > named in the device tree / I2C table, so a drop-in replacement part
> > keeps working on a kernel that does not know its sub-type yet.
> >
>
> ...
>
> > +static bool slf3s_crc_valid(const struct slf3s_data *sf, const u8 *block)
> > +{
> > + return crc8(sf->crc_table, block, 2, SLF3S_CRC8_INIT) == block[2];
> > +}
> > +
> > +/*
> > + * Read the product-info block and pick the matching variant. The
> > + * sub-type byte returned by the sensor is the source of truth; a
> > + * DT-supplied compatible only seeds an initial guess and is overridden
> > + * on mismatch (with an informational message so misconfigured device
> > + * trees are easy to spot).
>
> In the past, Jonathan has always argued that the devicetree should be
> trusted more than what the device self-reports. This seems a departure
> from that. Why are we making an exception here?
>
> We have to trust that the devicetree is correct for everything else
> that can't self-detect anyway.
>
Hi David
It's a slightly fuzzy boundary and I wouldn't ask anyone to spend
effort adding support for detection of where it differs from what firmware
reports. However, we have had a number of drivers do this in the past
and as long as it has a fallback to just believe the DT if you don't have
better info, I'm happy with this approach.
This is different from not believing firmware if the software has
no reason to believe it is wrong - i.e. the fallback compatible thing.
Jonathan
>
next prev parent reply other threads:[~2026-08-02 17:19 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-28 21:49 [PATCH v6 0/4] iio: flow: Sensirion SLF3S liquid flow sensor Wadim Mueller
2026-07-28 21:49 ` [PATCH v6 1/4] iio: types: add IIO_VOLUMEFLOW channel type Wadim Mueller
2026-08-03 9:32 ` Joshua Crofts
2026-07-28 21:49 ` [PATCH v6 2/4] dt-bindings: iio: flow: add Sensirion SLF3S liquid flow sensor Wadim Mueller
2026-08-01 23:46 ` Jonathan Cameron
2026-08-04 6:43 ` Krzysztof Kozlowski
2026-07-28 21:49 ` [PATCH v6 3/4] iio: core: add IIO_VAL_DECIMAL64_FEMTO format type Wadim Mueller
2026-08-02 16:01 ` David Lechner
2026-08-02 17:20 ` Jonathan Cameron
2026-07-28 21:49 ` [PATCH v6 4/4] iio: flow: add Sensirion SLF3S liquid flow sensor driver Wadim Mueller
2026-07-29 12:21 ` Uwe Kleine-König
2026-08-02 0:04 ` Jonathan Cameron
2026-08-02 16:07 ` David Lechner
2026-08-02 17:19 ` Jonathan Cameron [this message]
2026-08-01 23:50 ` [PATCH v6 0/4] iio: flow: Sensirion SLF3S liquid flow sensor 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=20260802181920.3cc8a259@jic23-huawei \
--to=jic23@kernel.org \
--cc=455.rodrigo.alencar@gmail.com \
--cc=andy@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dlechner@baylibre.com \
--cc=krzk+dt@kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo.schmitt1@gmail.com \
--cc=maxwell@maxwelld.cc \
--cc=nuno.sa@analog.com \
--cc=robh@kernel.org \
--cc=wafgo01@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