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

[Jonathan Cameron <jic23@kernel.org>]

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
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.

Note for this type of device I absolutely expect there to be future
parts with different IDs and same ranges as here, the unknown is whether
sensiron will change the interface or not.

Jonathan

> 
> > +
> > +  reg:
> > +    maxItems: 1
> > +
> > +  vdd-supply: true
> > +
> > +required:
> > +  - compatible
> > +  - reg
> > +  - vdd-supply
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > +  - |
> > +    i2c {
> > +        #address-cells = <1>;
> > +        #size-cells = <0>;
> > +
> > +        flow-sensor@8 {
> > +            compatible = "sensirion,slf3s-0600f";
> > +            reg = <0x08>;
> > +            vdd-supply = <&reg_3v3>;
> > +        };
> > +    };
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 06a8c7457..222a03b6d 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -24187,6 +24187,14 @@ S:	Maintained
> >  F:	Documentation/ABI/testing/sysfs-bus-iio-chemical-sgp40
> >  F:	drivers/iio/chemical/sgp40.c
> >  
> > +SENSIRION SLF3S LIQUID FLOW SENSOR DRIVER
> > +M:	Wadim Mueller <wafgo01@gmail.com>
> > +R:	Maxwell Doose <m32285159@gmail.com>
> > +L:	linux-iio@vger.kernel.org
> > +S:	Maintained
> > +F:	Documentation/devicetree/bindings/iio/flow/sensirion,slf3s.yaml
> > +F:	drivers/iio/flow/slf3s.c  
> 
> Basically almost the same comment as before. Drop. There is no such file.
> 
> > +
> >  SENSIRION SPS30 AIR POLLUTION SENSOR DRIVER
> >  M:	Tomasz Duszynski <tduszyns@gmail.com>
> >  S:	Maintained
> > -- 
> > 2.52.0
> >   
>