Re: [RFC PATCH v1 3/4] iio: flow: add Sensirion SLF3x liquid flow sensor driver

[Wadim Mueller]

On Tue, 26 May 2026 17:06:18 +0100
Jonathan Cameron <jic23@xxxxxxxxxx> wrote:

> > > What does the "X" refer to ? Why not "S" ?  
> 
> Absolutely - no wild cards in file names or indeed in variables etc.
> Just pick a part to name after.  Wild cards go wrong far too often!

Done in v2.  Renamed everywhere: slf3x.c -> slf3s.c, SLF3X_* ->
SLF3S_*, CONFIG_SENSIRION_SLF3X -> CONFIG_SENSIRION_SLF3S,
MAINTAINERS and binding titles too.

> > > +			dev_err(&client->dev,
> > > +				"unexpected device family 0x%02x\n",
> > > +				buf[SLF3X_FAMILY_BYTE]);
> > > +			return -ENODEV;  
> 
> Similar to below. This can't be an error or we break fallback
> compatibles in DT. There are historic drivers that do this that
> we haven't fixed up yet - but no new ones please!

Done in v2.  Unexpected family byte and unknown sub-type both
go to dev_dbg() now; the driver keeps the variant the compatible
/ id_table selected.  Only CRC failures and bus errors fail probe.

> Given the need to support fallback compatibles from device tree we don't
> fail at all on mismatches as that prevents use supporting a new fully
> backwards compatible (other than IDs) part in older kernels.
> 
> Whether a dev_info() or dev_dbg() is appropriate for such a case is
> less obvious but definitely dev_err().

Went with dev_dbg() for the unknown-sub-type / fallback path -
silent by default, discoverable when chasing a quirk.

Thanks,
Wadim