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

[Krzysztof Kozlowski]

On 01/06/2026 16:09, Jonathan Cameron wrote:
> On Mon, 1 Jun 2026 13:53:23 +0200
> Krzysztof Kozlowski <krzk@xxxxxxxxxx> 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?

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?

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.

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.



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


Best regards,
Krzysztof