Re: [PATCH v6 4/4] iio: flow: add Sensirion SLF3S liquid flow sensor driver

Jonathan Cameron <[email protected]> Sun, 2 Aug 2026 18:19:20 +0100
Newsgroups org.kernel.vger.linux-iio,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel
Message-ID <20260802181920.3cc8a259@jic23-huawei>
On Sun, 2 Aug 2026 11:07:27 -0500
David Lechner <[email protected]> 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

>