Re: [PATCH v3 2/3] dt-bindings: iio: flow: add Sensirion SLF3S liquid flow sensor

[Jonathan Cameron <jic23@kernel.org>]

On Wed, 3 Jun 2026 16:29:10 +0200
Krzysztof Kozlowski <krzk@kernel.org> wrote:

> On 01/06/2026 16:09, Jonathan Cameron wrote:
> > On Mon, 1 Jun 2026 13:53:23 +0200
> > Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >   
> >> On Sat, May 30, 2026 at 10:54:31PM +0200, Wadim Mueller wrote:  
> >>> Document the bindings for the Sensirion SLF3S family of digital
> >>> liquid-flow sensors on I2C.  The family currently covers the
> >>> SLF3S-0600F, SLF3S-1300F and SLF3S-4000B variants.
> >>>
> >>> The driver auto-detects the variant from the product-information
> >>> register at probe time; the per-variant compatible strings exist
> >>> for documentation and dt_binding_check purposes.    
> >>
> >> Here...
> >>  
> >>> +description:
> >>> +  Family of digital liquid-flow sensors from Sensirion with I2C
> >>> +  interface.  All family members share the same register map; sub-types
> >>> +  differ only in the flow scale factor and the calibrated measurement
> >>> +  range, both of which are detected at probe time via the
> >>> +  product-information register.    
> >>
> >> And here...
> >>  
> >>> +
> >>> +properties:
> >>> +  compatible:
> >>> +    enum:
> >>> +      - sensirion,slf3s-0600f
> >>> +      - sensirion,slf3s-1300f
> >>> +      - sensirion,slf3s-4000b    
> >>
> >> And here something else. Confusing. Didn't you say device variants are
> >> auto-detectable? So you have only one compatible sensirion,slf3s.  
> > 
> > And then future fallback compatibles can never work. 
> > Basically as far as I have ever been able to establish this is why
> > generic compatibles are almost always the wrong way to go.
> > 
> > If we get a future part with an unknown ID and don't have these existing
> > specific compatibles, then we have no way to specify which one it is  
> 
> But why would you have future part with unknown ID?

That's what manufacturers do on a very frequent basis.  They tweak something
that has no affect on the interface or channel scaling etc and release a new part
with a different ID.  Can be something like a part suited to different operating
conditions, or with a different supply tolerance.

> 
> The device is slf3s with variants. All of known variants have an
> interface to detect the actual variant. There is no indication that this
> won't work - why would company remove the ID register?

They won't remove the ID, but they will put other values in it to
indicate new revisions of a part - often entirely backwards compatible
- sometimes with extra features that we don't use until the driver is updated.


> 
> But even if this happens, then it would be change of device interface,
> thus you cannot use generic compatible and you will have a new dedicated
> compatible.

We've had this discussion a number of times for whether an ID register difference
alone makes a device non compatible, and the answer from DT review has always been
a firm no and that it is incorrect to reject an unknown ID if the dt-compatible
is known.  The compromise that people were happy with was an info print if
such a mismatch is detected as it might indicate an incompatible part replacement
and a broken DT.

Probably 80%+ of IIO bindings with fallback compatibles do not have
matching "who am I" register values.  This is incredibly common.

> 
> If the device is actually "slf3s-0600f" (because slf3s is a family),
> then I am fine with using that as the fallback. Specific front
> compatibles are also fine in such case.

Yes, it's a part in the family. Each of the compatibles here has a
separate datasheet:

https://sensirion.com/media/documents/C4F8D965/66F56F53/LQ_DS_SLF3S-0600F_Datasheet.pdf
https://sensirion.com/media/documents/6971528D/63625D22/Sensirion_Datasheet_SLF3S-1300F.pdf
etc

(wonderfully inconsistent file naming ;)

> 
> 
> 
> > compatible with.  Given these are providing scaling info that means we
> > can't realistically support such a future part with a fallback at all.
> > 
> > That would only be possible if there was feature level discovery. A single
> > whoami register with no structure to the value is useless for this.  
> 
> The whoami register defines all the features, no? What would feature
> discovery improve? ID register is simply logical OR of some feature set,
> still uniquely identifying the features set/variant.

Would be lovely if true. Sadly almost never true. They are typically just
the next number in a list of parts released. There is no direct information
on feature set encoded in that value, we have to have a look up table in
the driver to translate to feature set. (Not relevant here but sometimes
manufacturers forget to change the number and we get different feature
sets with the same ID and no discoverability)

If they were an OR of features that would be great.

The thing is a little structured in this case

0x07         Liquid flow sensor
0x  03       Product family (e.g. SLF3x)
0x    03     Subtype (e.g. SLF3S-0600F)
0x      02   Revision number (changes with minor firmware or hardware revisions)

But both the product family and subtype are numbers to feed into look up tables
(maybe revision number as well)

Jonathan


> 
> 
> Best regards,
> Krzysztof