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

[Conor Dooley <conor@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 5346 bytes --]

On Fri, Jun 12, 2026 at 07:05:43PM +0100, Jonathan Cameron wrote:
> On Sun, 7 Jun 2026 10:30:07 +0200
> Krzysztof Kozlowski <krzk@kernel.org> wrote:
> 
> > On Fri, Jun 05, 2026 at 01:21:35PM +0100, Jonathan Cameron wrote:
> > > On Thu, 4 Jun 2026 13:22:17 +0200
> > > Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > >   
> > > > On 04/06/2026 11:03, Jonathan Cameron wrote:  
> > > > > 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.    
> > > > 
> > > > and it will have a different, known that time ID. How could be "unknown"?  
> > > 
> > > Known to us, sure, know to old kernel (or other software), not so much.
> > > For this sort of driver the main use of fallback compatibles is to work on
> > > a not yet aware kernel.  
> > 
> > So you mean a case that sometime in the future, someone will write a DTS
> > with sensirion,slf3s fallback for a sensirion,slf3s-WAHTEVER_NEW_MODEL, use
> > old kernel and be surprised it does not work?
> 
> To me that is exactly what a fallback compatible is promising - if we have
> any kernel / driver that supports the part that we are saying is a valid
> fallback then we are saying we support at least the functionality of that
> part (sure there may be extra stuff that doesn't work)
> 
> We had a long discussion a few years back on whether code that did
> 
> 	if (read_reg_whoami() != EXPECTED_ID)
> 		return -ENODEV;
> 
> was correct. Someone (maybe Rob?) strongly argued that we must not
> do that because it effectively made fallbacks pointless as we always
> needed to upgrade the driver. I argued against this (on basis that
> swapping in incompatible parts is annoyingly common) but was eventually
> persuaded.
> 
> If that is not a valid reading of what fallback compatibles mean, is
> there any documentation of the rules I can refer to?
> 
> > 
> > Our goal is not to stop whatever poor code people can ever come up with.
> > 
> > Every future user wanting to the fallback MUST understand what the
> > fallback means.
> 
> This is where we disagree.
> 
> This is not hard to support, it just means not using generic compatibles
> when the device differ (and they are not self describing which these are
> not).

FWIW, I think the no generic compatible approach is reasonable.
The devices might be able to self-identify, but the featureset is not
discoverable, which makes the self-identification much less valuable.
Permitting drop-in replacement parts (or knock off devices from other
manufacturers etc) to use a compatible device as a fallback seems to me
exactly what fallbacks are intended for.

If the driver has to be updated every time a new device is created then
I think a generic compatible has effectively no value.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]