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

[Jonathan Cameron <jic23@kernel.org>]

On Sat, 13 Jun 2026 09:51:13 +0200
Krzysztof Kozlowski <krzk@kernel.org> wrote:

> On 12/06/2026 19:47, Jonathan Cameron wrote:
> > On Thu, 11 Jun 2026 16:01:12 +0200
> > Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >   
> >> On 11/06/2026 15:27, Wadim Mueller wrote:  
> >>> +
> >>> +static const struct of_device_id slf3s_of_match[] = {
> >>> +	{ .compatible = "sensirion,slf3s-0600f", .data = &slf3s_variants[0] },
> >>> +	{ .compatible = "sensirion,slf3s-1300f", .data = &slf3s_variants[1] },
> >>> +	{ .compatible = "sensirion,slf3s-4000b", .data = &slf3s_variants[2] },    
> >>
> >> You should have only 1300f here and detect the variants. That was my
> >> point when I suggested to use the fallback.
> >>  
> > 
> > I'm lost. How does that work?  They cannot fallback to that part because
> > it relies on in driver detection of the fact that they are incompatible.
> >   
> 
> I am lost too. Then why were they made compatible in the binding?
> 
> Entire discussion was that these are FULLY compatible due to variant
> detection. That was the entire point of discussing more generic
> fallback. Using specific fallback does not change that - it is the same
> concept.
> 
> If devices are not detectable, why were we discussing any compatibility?

They are detectable, but the feature set is not, so to me there is zero valid
in a generic fallback, we have to update the driver every time a new part comes
along. (i.e. I agree with Conor's reply to the previous version thread).
A specific fallback to a completely compatible part would be fine as there
would be sufficient info to not need the ID lookup.

The case in the binding for this version is the worst of all options because
it implies it is valid to fallback to something that gives a false impression
of being specific when it's relying on ID matching to say actually it's something
else.

So definitely not
+  compatible:
+    oneOf:
+      - const: sensirion,slf3s-1300f
+      - items:
+          - enum:
+              - sensirion,slf3s-0600f
+              - sensirion,slf3s-4000b
+          - const: sensirion,slf3s-1300f
+

Falling back to slf3s is better than this, but I'd rather not have a fallback
at all, thus allowing correct fallback to the parts listed here in future.

Jonathan


> 
> Best regards,
> Krzysztof