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

[Krzysztof Kozlowski <krzk@kernel.org>]

On 14/06/2026 17:10, Jonathan Cameron wrote:
> 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.

This patch has specific fallback and we discuss this now.

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

Why? These devices are fully detectable thus fully compatible.

Best regards,
Krzysztof