[RFC PATCH v1 0/4] iio: add Sensirion SLF3x liquid flow sensor support

[RFC PATCH v1 0/4] iio: add Sensirion SLF3x liquid flow sensor support

[Wadim Mueller]

From: Wadim Mueller <wadim.mueller@cmblu.de>

Hi all,

this RFC adds support for the Sensirion SLF3x family of liquid-flow
sensors (SLF3S-0600F and SLF3S-4000B).  Before I send it as a normal
patch I'd like to ask three things:

1. Subsystem.  Liquid-flow sensors don't seem to have a home in
   mainline yet.  iio/ feels like the natural place for me, but
   please correct me if hwmon (or somewhere else) is prefered.

2. Channel type.  IIO has no flow channel type so far.  The series
   adds IIO_VOLUMEFLOW with _scale in litres per second per LSB,
   so drivers reporting smaller units only need a fractional scale.
   IIO_MASSFLOW (for gas-flow sensors) was left out on purpose --
   happy to add it in the same series if that's more usefull.

3. Subdirectory.  I put the driver in a new drivers/iio/flow/
   since there is no flow subsytem in iio yet.  If colocating with
   drivers/iio/pressure/ (next to sdp500) is preferred I'll respin.

Patches:

  1/4  iio: types: add IIO_VOLUMEFLOW channel type
  2/4  dt-bindings: iio: flow: add sensirion,slf3s binding
  3/4  iio: flow: add Sensirion SLF3x driver
  4/4  MAINTAINERS: add entry

Tested with a SLF3S-0600F on a TI AM64x platform.

Thanks,
Wadim

Wadim Mueller (4):
  iio: types: add IIO_VOLUMEFLOW channel type
  dt-bindings: iio: flow: add Sensirion SLF3x liquid flow sensor
  iio: flow: add Sensirion SLF3x liquid flow sensor driver
  MAINTAINERS: add entry for Sensirion SLF3x flow sensor driver

 Documentation/ABI/testing/sysfs-bus-iio       |  17 ++
 .../bindings/iio/flow/sensirion,slf3s.yaml    |  49 ++++
 MAINTAINERS                                   |   7 +
 drivers/iio/Kconfig                           |   1 +
 drivers/iio/Makefile                          |   1 +
 drivers/iio/flow/Kconfig                      |  22 ++
 drivers/iio/flow/Makefile                     |   7 +
 drivers/iio/flow/slf3x.c                      | 264 ++++++++++++++++++
 drivers/iio/industrialio-core.c               |   1 +
 include/uapi/linux/iio/types.h                |   1 +
 tools/iio/iio_event_monitor.c                 |   2 +
 11 files changed, 372 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/flow/sensirion,slf3s.yaml
 create mode 100644 drivers/iio/flow/Kconfig
 create mode 100644 drivers/iio/flow/Makefile
 create mode 100644 drivers/iio/flow/slf3x.c


base-commit: 3cd8b194bf3428dfa53120fee47e827a7c495815
-- 
2.52.0

[RFC PATCH v1 1/4] iio: types: add IIO_VOLUMEFLOW channel type

[Wadim Mueller]

From: Wadim Mueller <wadim.mueller@cmblu.de>

Add a new IIO channel type for liquid volumetric flow sensors.  The
unit exposed via the standard _scale attribute is litres per second
(l/s), so drivers reporting smaller native units (e.g. ml/min) only
need to set a fractional scale.

Update iio-core's name table, the iio_event_monitor whitelist and
the sysfs-bus-iio ABI document to match.

Signed-off-by: Wadim Mueller <wadim.mueller@cmblu.de>
---
 Documentation/ABI/testing/sysfs-bus-iio | 17 +++++++++++++++++
 drivers/iio/industrialio-core.c         |  1 +
 include/uapi/linux/iio/types.h          |  1 +
 tools/iio/iio_event_monitor.c           |  2 ++
 4 files changed, 21 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio
index 5f87dcee7..68eb703c1 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -2458,3 +2458,20 @@ Description:
 		seconds, expressed as:
 
 		- a range specified as "[min step max]"
+
+What:/sys/bus/iio/devices/iio:deviceX/in_volumeflow_raw
+What:/sys/bus/iio/devices/iio:deviceX/in_volumeflowY_raw
+KernelVersion:6.19
+Contact:linux-iio@vger.kernel.org
+Description:
+Raw (unscaled) volumetric flow rate reading from the channel.
+To convert to standard units (litres / second) apply the
+channel's _scale (and _offset, when present).
+
+What:/sys/bus/iio/devices/iio:deviceX/in_volumeflow_scale
+What:/sys/bus/iio/devices/iio:deviceX/in_volumeflowY_scale
+KernelVersion:6.19
+Contact:linux-iio@vger.kernel.org
+Description:
+Scale factor applied to raw volumetric flow readings to obtain
+the value in litres per second (l/s).
diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index 22eefd048..aa34fcd8e 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -98,6 +98,7 @@ static const char * const iio_chan_type_name_spec[] = {
 	[IIO_CHROMATICITY] = "chromaticity",
 	[IIO_ATTENTION] = "attention",
 	[IIO_ALTCURRENT] = "altcurrent",
+	[IIO_VOLUMEFLOW] = "volumeflow",
 };
 
 static const char * const iio_modifier_names[] = {
diff --git a/include/uapi/linux/iio/types.h b/include/uapi/linux/iio/types.h
index 6d269b844..49480f321 100644
--- a/include/uapi/linux/iio/types.h
+++ b/include/uapi/linux/iio/types.h
@@ -53,6 +53,7 @@ enum iio_chan_type {
 	IIO_CHROMATICITY,
 	IIO_ATTENTION,
 	IIO_ALTCURRENT,
+	IIO_VOLUMEFLOW,
 };
 
 enum iio_modifier {
diff --git a/tools/iio/iio_event_monitor.c b/tools/iio/iio_event_monitor.c
index 03ca33869..078004750 100644
--- a/tools/iio/iio_event_monitor.c
+++ b/tools/iio/iio_event_monitor.c
@@ -65,6 +65,7 @@ static const char * const iio_chan_type_name_spec[] = {
 	[IIO_CHROMATICITY] = "chromaticity",
 	[IIO_ATTENTION] = "attention",
 	[IIO_ALTCURRENT] = "altcurrent",
+	[IIO_VOLUMEFLOW] = "volumeflow",
 };
 
 static const char * const iio_ev_type_text[] = {
@@ -193,6 +194,7 @@ static bool event_is_known(struct iio_event_data *event)
 	case IIO_CHROMATICITY:
 	case IIO_ATTENTION:
 	case IIO_ALTCURRENT:
+	case IIO_VOLUMEFLOW:
 		break;
 	default:
 		return false;
-- 
2.52.0

Re: [RFC PATCH v1 1/4] iio: types: add IIO_VOLUMEFLOW channel type

[Guenter Roeck]

On 5/24/26 13:49, Wadim Mueller wrote:
> From: Wadim Mueller <wadim.mueller@cmblu.de>
> 
> Add a new IIO channel type for liquid volumetric flow sensors.  The
> unit exposed via the standard _scale attribute is litres per second
> (l/s), so drivers reporting smaller native units (e.g. ml/min) only
> need to set a fractional scale.
> 

Two questions: Why restricting to liquid (there are also gas flow sensors),
and why litres/second and not per minute which seems to be a more common
unit ?

More on the latter in patch 3.

Thanks,
Guenter

> Update iio-core's name table, the iio_event_monitor whitelist and
> the sysfs-bus-iio ABI document to match.
> 
> Signed-off-by: Wadim Mueller <wadim.mueller@cmblu.de>
> ---
>   Documentation/ABI/testing/sysfs-bus-iio | 17 +++++++++++++++++
>   drivers/iio/industrialio-core.c         |  1 +
>   include/uapi/linux/iio/types.h          |  1 +
>   tools/iio/iio_event_monitor.c           |  2 ++
>   4 files changed, 21 insertions(+)
> 
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio
> index 5f87dcee7..68eb703c1 100644
> --- a/Documentation/ABI/testing/sysfs-bus-iio
> +++ b/Documentation/ABI/testing/sysfs-bus-iio
> @@ -2458,3 +2458,20 @@ Description:
>   		seconds, expressed as:
>   
>   		- a range specified as "[min step max]"
> +
> +What:/sys/bus/iio/devices/iio:deviceX/in_volumeflow_raw
> +What:/sys/bus/iio/devices/iio:deviceX/in_volumeflowY_raw
> +KernelVersion:6.19
> +Contact:linux-iio@vger.kernel.org
> +Description:
> +Raw (unscaled) volumetric flow rate reading from the channel.
> +To convert to standard units (litres / second) apply the
> +channel's _scale (and _offset, when present).
> +
> +What:/sys/bus/iio/devices/iio:deviceX/in_volumeflow_scale
> +What:/sys/bus/iio/devices/iio:deviceX/in_volumeflowY_scale
> +KernelVersion:6.19
> +Contact:linux-iio@vger.kernel.org
> +Description:
> +Scale factor applied to raw volumetric flow readings to obtain
> +the value in litres per second (l/s).
> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> index 22eefd048..aa34fcd8e 100644
> --- a/drivers/iio/industrialio-core.c
> +++ b/drivers/iio/industrialio-core.c
> @@ -98,6 +98,7 @@ static const char * const iio_chan_type_name_spec[] = {
>   	[IIO_CHROMATICITY] = "chromaticity",
>   	[IIO_ATTENTION] = "attention",
>   	[IIO_ALTCURRENT] = "altcurrent",
> +	[IIO_VOLUMEFLOW] = "volumeflow",
>   };
>   
>   static const char * const iio_modifier_names[] = {
> diff --git a/include/uapi/linux/iio/types.h b/include/uapi/linux/iio/types.h
> index 6d269b844..49480f321 100644
> --- a/include/uapi/linux/iio/types.h
> +++ b/include/uapi/linux/iio/types.h
> @@ -53,6 +53,7 @@ enum iio_chan_type {
>   	IIO_CHROMATICITY,
>   	IIO_ATTENTION,
>   	IIO_ALTCURRENT,
> +	IIO_VOLUMEFLOW,
>   };
>   
>   enum iio_modifier {
> diff --git a/tools/iio/iio_event_monitor.c b/tools/iio/iio_event_monitor.c
> index 03ca33869..078004750 100644
> --- a/tools/iio/iio_event_monitor.c
> +++ b/tools/iio/iio_event_monitor.c
> @@ -65,6 +65,7 @@ static const char * const iio_chan_type_name_spec[] = {
>   	[IIO_CHROMATICITY] = "chromaticity",
>   	[IIO_ATTENTION] = "attention",
>   	[IIO_ALTCURRENT] = "altcurrent",
> +	[IIO_VOLUMEFLOW] = "volumeflow",
>   };
>   
>   static const char * const iio_ev_type_text[] = {
> @@ -193,6 +194,7 @@ static bool event_is_known(struct iio_event_data *event)
>   	case IIO_CHROMATICITY:
>   	case IIO_ATTENTION:
>   	case IIO_ALTCURRENT:
> +	case IIO_VOLUMEFLOW:
>   		break;
>   	default:
>   		return false;

Re: [RFC PATCH v1 1/4] iio: types: add IIO_VOLUMEFLOW channel type

[Jonathan Cameron]

On Sun, 24 May 2026 14:39:06 -0700
Guenter Roeck <linux@roeck-us.net> wrote:

> On 5/24/26 13:49, Wadim Mueller wrote:
> > From: Wadim Mueller <wadim.mueller@cmblu.de>
> > 
> > Add a new IIO channel type for liquid volumetric flow sensors.  The
> > unit exposed via the standard _scale attribute is litres per second
> > (l/s), so drivers reporting smaller native units (e.g. ml/min) only
> > need to set a fractional scale.
> >   
> 
> Two questions: Why restricting to liquid (there are also gas flow sensors),
> and why litres/second and not per minute which seems to be a more common
> unit ?

I'd rather we went to the SI units where possible.
With long hindsight it was a mistake not doing this everywhere because
it means people have to constantly check what the units are for a given
channel type.  For almost everything we've added in last 10 ish years
it's been base SI units.

> 
> More on the latter in patch 3.
> 
> Thanks,
> Guenter

Re: [RFC PATCH v1 1/4] iio: types: add IIO_VOLUMEFLOW channel type

[Wadim Mueller]

On Tue, 26 May 2026 16:59:50 +0100
Jonathan Cameron <jic23@kernel.org> wrote:

> > Two questions: Why restricting to liquid (there are also gas flow sensors),
> > and why litres/second and not per minute which seems to be a more common
> > unit ?  
> 
> I'd rather we went to the SI units where possible.

Agreed - SI in v2.  in_volumeflow_raw / _scale stays in l/s
(rescaled SI m^3/s, matching the rest of IIO's "kept-small-for-
userspace" convention).  The ABI doc and a driver comment call
that out.

On the gas-flow question: rather than adding IIO_MASSFLOW now
without a driver, I dropped the "liquid" wording from the channel
type doc.  The SLF3S driver is liquid-only, but the channel type
itself just means "volumetric flow rate" and could describe a gas
sensor reporting actual volume rate just as well.  IIO_MASSFLOW
for standard-volume / mass-equivalent gas flow can come later
when a driver shows up.

Thanks,
Wadim

Re: [RFC PATCH v1 1/4] iio: types: add IIO_VOLUMEFLOW channel type

[Wadim Mueller]

On Sun, 24 May 2026 14:39:06 -0700
Guenter Roeck <linux@roeck-us.net> wrote:

> Two questions: Why restricting to liquid (there are also gas flow sensors),
> and why litres/second and not per minute which seems to be a more common
> unit ?

Both fair points - Jonathan weighed in on the same thread [1],
so summarising for v2:

  1. Liquid vs gas.  Channel type in v2 just says "volumetric
     flow rate" - no "liquid" qualifier.  A liquid-only sensor
     like SLF3S uses it directly, a gas sensor reporting actual
     volumetric flow uses it too.  Standard-volume / density-
     equivalent gas flow is mass flow at heart and will get its
     own IIO_MASSFLOW when a driver needs it, rather than
     overloading IIO_VOLUMEFLOW.

  2. Per second vs per minute.  Going with seconds (l/s, later
     kg/s) because the rest of IIO is SI-based: integration_time,
     sampling_frequency, accel etc. are all per-second.  Drivers
     whose native unit is per-minute fold the 1/60 into _scale,
     same as SLF3S does.

[1] https://lore.kernel.org/all/20260526165950.6ebbf673@jic23-huawei/

Thanks,
Wadim

Re: [RFC PATCH v1 1/4] iio: types: add IIO_VOLUMEFLOW channel type

[Jonathan Cameron]

On Sun, 24 May 2026 22:49:36 +0200
Wadim Mueller <wafgo01@gmail.com> wrote:

> From: Wadim Mueller <wadim.mueller@cmblu.de>
> 
> Add a new IIO channel type for liquid volumetric flow sensors.  The
> unit exposed via the standard _scale attribute is litres per second
> (l/s), so drivers reporting smaller native units (e.g. ml/min) only
> need to set a fractional scale.
> 
> Update iio-core's name table, the iio_event_monitor whitelist and
> the sysfs-bus-iio ABI document to match.
> 
> Signed-off-by: Wadim Mueller <wadim.mueller@cmblu.de>
> ---
>  Documentation/ABI/testing/sysfs-bus-iio | 17 +++++++++++++++++
>  drivers/iio/industrialio-core.c         |  1 +
>  include/uapi/linux/iio/types.h          |  1 +
>  tools/iio/iio_event_monitor.c           |  2 ++
>  4 files changed, 21 insertions(+)
> 
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio
> index 5f87dcee7..68eb703c1 100644
> --- a/Documentation/ABI/testing/sysfs-bus-iio
> +++ b/Documentation/ABI/testing/sysfs-bus-iio
> @@ -2458,3 +2458,20 @@ Description:
>  		seconds, expressed as:
>  
>  		- a range specified as "[min step max]"
> +
> +What:/sys/bus/iio/devices/iio:deviceX/in_volumeflow_raw
> +What:/sys/bus/iio/devices/iio:deviceX/in_volumeflowY_raw
> +KernelVersion:6.19
> +Contact:linux-iio@vger.kernel.org
> +Description:
> +Raw (unscaled) volumetric flow rate reading from the channel.
> +To convert to standard units (litres / second) apply the
> +channel's _scale (and _offset, when present).

Formatting doesn't match rest of file at all.

> +
> +What:/sys/bus/iio/devices/iio:deviceX/in_volumeflow_scale
> +What:/sys/bus/iio/devices/iio:deviceX/in_volumeflowY_scale
> +KernelVersion:6.19
> +Contact:linux-iio@vger.kernel.org
> +Description:
> +Scale factor applied to raw volumetric flow readings to obtain
> +the value in litres per second (l/s).
I'd just add this to the big block of existing _scale.
The units etc are all covered in _raw so we don't need to really say more than
this exists.
 
> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> index 22eefd048..aa34fcd8e 100644
> --- a/drivers/iio/industrialio-core.c
> +++ b/drivers/iio/industrialio-core.c
> @@ -98,6 +98,7 @@ static const char * const iio_chan_type_name_spec[] = {
>  	[IIO_CHROMATICITY] = "chromaticity",
>  	[IIO_ATTENTION] = "attention",
>  	[IIO_ALTCURRENT] = "altcurrent",
> +	[IIO_VOLUMEFLOW] = "volumeflow",
>  };
>  
>  static const char * const iio_modifier_names[] = {
> diff --git a/include/uapi/linux/iio/types.h b/include/uapi/linux/iio/types.h
> index 6d269b844..49480f321 100644
> --- a/include/uapi/linux/iio/types.h
> +++ b/include/uapi/linux/iio/types.h
> @@ -53,6 +53,7 @@ enum iio_chan_type {
>  	IIO_CHROMATICITY,
>  	IIO_ATTENTION,
>  	IIO_ALTCURRENT,
> +	IIO_VOLUMEFLOW,
>  };
>  
>  enum iio_modifier {
> diff --git a/tools/iio/iio_event_monitor.c b/tools/iio/iio_event_monitor.c
> index 03ca33869..078004750 100644
> --- a/tools/iio/iio_event_monitor.c
> +++ b/tools/iio/iio_event_monitor.c
> @@ -65,6 +65,7 @@ static const char * const iio_chan_type_name_spec[] = {
>  	[IIO_CHROMATICITY] = "chromaticity",
>  	[IIO_ATTENTION] = "attention",
>  	[IIO_ALTCURRENT] = "altcurrent",
> +	[IIO_VOLUMEFLOW] = "volumeflow",
>  };
>  
>  static const char * const iio_ev_type_text[] = {
> @@ -193,6 +194,7 @@ static bool event_is_known(struct iio_event_data *event)
>  	case IIO_CHROMATICITY:
>  	case IIO_ATTENTION:
>  	case IIO_ALTCURRENT:
> +	case IIO_VOLUMEFLOW:
>  		break;
>  	default:
>  		return false;

Re: [RFC PATCH v1 1/4] iio: types: add IIO_VOLUMEFLOW channel type

[Wadim Mueller]

On Tue, 26 May 2026 17:13:50 +0100
Jonathan Cameron <jic23@kernel.org> wrote:

> > +What:/sys/bus/iio/devices/iio:deviceX/in_volumeflow_raw
> > +What:/sys/bus/iio/devices/iio:deviceX/in_volumeflowY_raw
> > +KernelVersion:6.19
> > +Contact:linux-iio@vger.kernel.org
> > +Description:
> > +Raw (unscaled) volumetric flow rate reading from the channel.
> > +To convert to standard units (litres / second) apply the
> > +channel's _scale (and _offset, when present).  
> 
> Formatting doesn't match rest of file at all.

Done in v2.  The whitespace got lost when pasting from a wrapped
editor - v2 uses tabs and the same indent as the surrounding
blocks.

> > +What:/sys/bus/iio/devices/iio:deviceX/in_volumeflow_scale
> > +What:/sys/bus/iio/devices/iio:deviceX/in_volumeflowY_scale
> > +KernelVersion:6.19
> > +Contact:linux-iio@vger.kernel.org
> > +Description:
> > +Scale factor applied to raw volumetric flow readings to obtain
> > +the value in litres per second (l/s).  
> I'd just add this to the big block of existing _scale.
> The units etc are all covered in _raw so we don't need to really say more than
> this exists.

Done in v2.  The separate _scale stanza is gone; the shared
_scale block at the top of the file now has one extra line:

  IIO_VOLUMEFLOW    litres per second

The _raw block stays for the per-channel-type description and
points at the shared _scale section for the units.

Thanks,
Wadim

[RFC PATCH v1 2/4] dt-bindings: iio: flow: add Sensirion SLF3x liquid flow sensor

[Wadim Mueller]

From: Wadim Mueller <wadim.mueller@cmblu.de>

Add a DT binding for the Sensirion SLF3x family of I2C liquid-flow
sensors.  A single 'sensirion,slf3s' compatible is exposed because
the sub-types share the same register map and are detected at
runtime via the product-information register.

Signed-off-by: Wadim Mueller <wadim.mueller@cmblu.de>
---
 .../bindings/iio/flow/sensirion,slf3s.yaml    | 49 +++++++++++++++++++
 1 file changed, 49 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/flow/sensirion,slf3s.yaml

diff --git a/Documentation/devicetree/bindings/iio/flow/sensirion,slf3s.yaml b/Documentation/devicetree/bindings/iio/flow/sensirion,slf3s.yaml
new file mode 100644
index 000000000..5ef62435f
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/flow/sensirion,slf3s.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/flow/sensirion,slf3s.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sensirion SLF3x liquid flow sensor
+
+maintainers:
+  - Wadim Mueller <wadim.mueller@cmblu.de>
+
+description: |
+  Family of digital liquid-flow sensors from Sensirion with I2C interface.
+  The same register map is shared by all family members; sub-types differ
+  only in the flow scale factor exposed by the device and are detected at
+  probe time via the product-information register.
+
+  Supported sub-types:
+    - SLF3S-0600F (calibrated range ±2 ml/min)
+    - SLF3S-4000B (calibrated range ±80 ml/min)
+
+properties:
+  compatible:
+    enum:
+      - sensirion,slf3s
+
+  reg:
+    maxItems: 1
+
+  vdd-supply: true
+
+required:
+  - compatible
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+    i2c {
+      #address-cells = <1>;
+      #size-cells = <0>;
+
+      flow-sensor@8 {
+        compatible = "sensirion,slf3s";
+        reg = <0x08>;
+        vdd-supply = <&reg_3v3>;
+      };
+    };
-- 
2.52.0

Re: [RFC PATCH v1 2/4] dt-bindings: iio: flow: add Sensirion SLF3x liquid flow sensor

[Jonathan Cameron]

On Sun, 24 May 2026 22:49:37 +0200
Wadim Mueller <wafgo01@gmail.com> wrote:

> From: Wadim Mueller <wadim.mueller@cmblu.de>
> 
> Add a DT binding for the Sensirion SLF3x family of I2C liquid-flow
> sensors.  A single 'sensirion,slf3s' compatible is exposed because
> the sub-types share the same register map and are detected at
> runtime via the product-information register.
> 
> Signed-off-by: Wadim Mueller <wadim.mueller@cmblu.de>
Hi Wadim.

A few things inline.

Thanks,

Jonathan

> ---
>  .../bindings/iio/flow/sensirion,slf3s.yaml    | 49 +++++++++++++++++++
>  1 file changed, 49 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iio/flow/sensirion,slf3s.yaml
> 
> diff --git a/Documentation/devicetree/bindings/iio/flow/sensirion,slf3s.yaml b/Documentation/devicetree/bindings/iio/flow/sensirion,slf3s.yaml
> new file mode 100644
> index 000000000..5ef62435f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/flow/sensirion,slf3s.yaml
> @@ -0,0 +1,49 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iio/flow/sensirion,slf3s.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Sensirion SLF3x liquid flow sensor
> +
> +maintainers:
> +  - Wadim Mueller <wadim.mueller@cmblu.de>
> +
> +description: |
> +  Family of digital liquid-flow sensors from Sensirion with I2C interface.
> +  The same register map is shared by all family members; sub-types differ
> +  only in the flow scale factor exposed by the device and are detected at
> +  probe time via the product-information register.

Because that doesn't work for fallback compatibles, we often give devices
their own compatibles anyway. Fine to also detect in driver but if we get
something that falls back to an SLF3S-0600F I don't think there is any reason
to think the subtype will match, so we have to trust DT to have given us
all the necessary info.

> +
> +  Supported sub-types:
> +    - SLF3S-0600F (calibrated range ±2 ml/min)
> +    - SLF3S-4000B (calibrated range ±80 ml/min)
> +
> +properties:
> +  compatible:
> +    enum:
> +      - sensirion,slf3s

If you don't expect to add  more sensors this in near future would be fine
as a const rather than an enum.

> +
> +  reg:
> +    maxItems: 1

There seems to be an irq. Given bindings should be complete that should
be here even if the driver doesn't use it.

> +
> +  vdd-supply: true
> +
> +required:
> +  - compatible
> +  - reg

vdd-supply presumably needed for device to function so should be here.
From dt-binding point of view we don't care about the kernel providing
stub regulators etc.  The supply documentation should reflect what must
actually be supplied.

> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    i2c {
> +      #address-cells = <1>;
> +      #size-cells = <0>;
> +
> +      flow-sensor@8 {
> +        compatible = "sensirion,slf3s";
> +        reg = <0x08>;
> +        vdd-supply = <&reg_3v3>;
> +      };
> +    };

Re: [RFC PATCH v1 2/4] dt-bindings: iio: flow: add Sensirion SLF3x liquid flow sensor

[Wadim Mueller]

On Tue, 26 May 2026 17:19:30 +0100
Jonathan Cameron <jic23@kernel.org> wrote:

> > +description: |
> > +  Family of digital liquid-flow sensors from Sensirion with I2C interface.
> > +  The same register map is shared by all family members; sub-types differ
> > +  only in the flow scale factor exposed by the device and are detected at
> > +  probe time via the product-information register.  
> 
> Because that doesn't work for fallback compatibles, we often give devices
> their own compatibles anyway. Fine to also detect in driver but if we get
> something that falls back to an SLF3S-0600F I don't think there is any reason
> to think the subtype will match, so we have to trust DT to have given us
> all the necessary info.

Done in v2.  Per-variant compatibles (sensirion,slf3s-0600f,
sensirion,slf3s-1300f, sensirion,slf3s-4000b) plus a generic
"sensirion,slf3s" fallback.  The driver picks the variant from
compatible / id_table .data and uses the product-info sub-type
only as a sanity hint - unknown sub-type on a recognised
compatible is dev_dbg() now, which makes the fallback story
work for future SLF3S parts.

> > +properties:
> > +  compatible:
> > +    enum:
> > +      - sensirion,slf3s  
> 
> If you don't expect to add  more sensors this in near future would be fine
> as a const rather than an enum.

The enum stays (per-variant + fallback now), expressed as
`oneOf:` of `const:` and a list.

> > +  reg:
> > +    maxItems: 1  
> 
> There seems to be an irq. Given bindings should be complete that should
> be here even if the driver doesn't use it.

Done in v2.  Optional `interrupts:` (maxItems: 1) - active-low
data-ready signal.  Driver doesn't use it yet, but the binding
now matches the hardware.

> > +required:
> > +  - compatible
> > +  - reg  
> 
> vdd-supply presumably needed for device to function so should be here.
> From dt-binding point of view we don't care about the kernel providing
> stub regulators etc.  The supply documentation should reflect what must
> actually be supplied.

Done in v2.  vdd-supply is in `required:`, paired with
devm_regulator_get_enable() (no _optional) on the driver side.

Thanks,
Wadim

[RFC PATCH v1 3/4] iio: flow: add Sensirion SLF3x liquid flow sensor driver

[Wadim Mueller]

From: Wadim Mueller <wadim.mueller@cmblu.de>

Add an IIO driver for the Sensirion SLF3S family of digital
liquid-flow sensors.  The supported sub-types (SLF3S-0600F,
SLF3S-4000B) share the same register map and command set and are
distinguished only by the flow scale; the variant is detected at
probe time from the product-information register.

The driver exposes two IIO channels:
  - in_volumeflow_raw / in_volumeflow_scale (litres per second)
  - in_temp_raw       / in_temp_scale       (milli-degC)

Continuous measurement mode is started in probe and stopped via
devm-action; read_raw() fetches the most recent sample on demand.

Signed-off-by: Wadim Mueller <wadim.mueller@cmblu.de>
---
 drivers/iio/Kconfig       |   1 +
 drivers/iio/Makefile      |   1 +
 drivers/iio/flow/Kconfig  |  22 ++++
 drivers/iio/flow/Makefile |   7 +
 drivers/iio/flow/slf3x.c  | 264 ++++++++++++++++++++++++++++++++++++++
 5 files changed, 295 insertions(+)
 create mode 100644 drivers/iio/flow/Kconfig
 create mode 100644 drivers/iio/flow/Makefile
 create mode 100644 drivers/iio/flow/slf3x.c

diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
index 661127aed..652557a5b 100644
--- a/drivers/iio/Kconfig
+++ b/drivers/iio/Kconfig
@@ -92,6 +92,7 @@ source "drivers/iio/common/Kconfig"
 source "drivers/iio/dac/Kconfig"
 source "drivers/iio/dummy/Kconfig"
 source "drivers/iio/filter/Kconfig"
+source "drivers/iio/flow/Kconfig"
 source "drivers/iio/frequency/Kconfig"
 source "drivers/iio/gyro/Kconfig"
 source "drivers/iio/health/Kconfig"
diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
index cb80ef837..f03a4100c 100644
--- a/drivers/iio/Makefile
+++ b/drivers/iio/Makefile
@@ -29,6 +29,7 @@ obj-y += dac/
 obj-y += dummy/
 obj-y += gyro/
 obj-y += filter/
+obj-y += flow/
 obj-y += frequency/
 obj-y += health/
 obj-y += humidity/
diff --git a/drivers/iio/flow/Kconfig b/drivers/iio/flow/Kconfig
new file mode 100644
index 000000000..355857a6b
--- /dev/null
+++ b/drivers/iio/flow/Kconfig
@@ -0,0 +1,22 @@
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# Liquid / gas flow sensor drivers
+#
+# When adding new entries keep the list in alphabetical order
+
+menu "Flow sensors"
+
+config SENSIRION_SLF3X
+	tristate "Sensirion SLF3x liquid flow sensor"
+	depends on I2C
+	select CRC8
+	help
+	  Say yes here to build support for the Sensirion SLF3S family of
+	  digital liquid-flow sensors (SLF3S-0600F, SLF3S-4000B, ...).
+	  The driver reports the volumetric flow rate and the embedded
+	  temperature reading via the standard IIO interface.
+
+	  To compile this driver as a module, choose M here: the module
+	  will be called slf3x.
+
+endmenu
diff --git a/drivers/iio/flow/Makefile b/drivers/iio/flow/Makefile
new file mode 100644
index 000000000..9eb9bdde0
--- /dev/null
+++ b/drivers/iio/flow/Makefile
@@ -0,0 +1,7 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# Makefile for industrial I/O flow sensor drivers
+#
+
+# When adding new entries keep the list in alphabetical order
+obj-$(CONFIG_SENSIRION_SLF3X) += slf3x.o
diff --git a/drivers/iio/flow/slf3x.c b/drivers/iio/flow/slf3x.c
new file mode 100644
index 000000000..e4ee1a04a
--- /dev/null
+++ b/drivers/iio/flow/slf3x.c
@@ -0,0 +1,264 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Sensirion SLF3x liquid flow sensor driver.
+ *
+ * Copyright (C) 2026 CMBlu Energy
+ * Author: Wadim Mueller <wadim.mueller@cmblu.de>
+ */
+
+#include <linux/crc8.h>
+#include <linux/delay.h>
+#include <linux/i2c.h>
+#include <linux/iio/iio.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/regulator/consumer.h>
+
+#include <linux/unaligned.h>
+
+#define SLF3X_CRC8_POLY		0x31
+#define SLF3X_CRC8_INIT		0xff
+
+#define SLF3X_PRODUCT_ID_LEN	18
+#define SLF3X_FAMILY_BYTE	1
+#define SLF3X_SUBTYPE_BYTE	3
+
+#define SLF3X_FAMILY_ID		0x03
+
+#define SLF3X_MEAS_LEN		9
+#define SLF3X_MEAS_DELAY_US	12000
+
+/* Temperature LSB is 1/200 °C; IIO_TEMP scale is in mC/LSB => 5. */
+#define SLF3X_TEMP_SCALE	5
+
+static const u8 slf3x_cmd_prep_pid[]	= { 0x36, 0x7c };
+static const u8 slf3x_cmd_read_pid[]	= { 0xe1, 0x02 };
+static const u8 slf3x_cmd_start_water[]	= { 0x36, 0x08 };
+static const u8 slf3x_cmd_stop[]	= { 0x3f, 0xf9 };
+
+DECLARE_CRC8_TABLE(slf3x_crc_table);
+
+struct slf3x_variant {
+	u8 sub_type;
+	const char *name;
+	/*
+	 * Flow scale exposed via IIO_CHAN_INFO_SCALE in litres per second
+	 * per LSB, encoded as IIO_VAL_FRACTIONAL (num / den).  The encoding
+	 * comes from the Sensirion datasheet's "scale factor" (ticks per
+	 * ml/min) combined with the 1 ml/min = 1/60000 l/s conversion.
+	 */
+	int scale_num;
+	int scale_den;
+};
+
+static const struct slf3x_variant slf3x_variants[] = {
+	{ .sub_type = 0x03, .name = "slf3s-0600f",
+	  .scale_num = 1, .scale_den = 6000000 },
+	{ .sub_type = 0x05, .name = "slf3s-4000b",
+	  .scale_num = 1, .scale_den = 1666680000 },
+};
+
+struct slf3x_data {
+	struct i2c_client *client;
+	const struct slf3x_variant *variant;
+};
+
+static int slf3x_verify_crc(const u8 *block)
+{
+	return crc8(slf3x_crc_table, block, 2, SLF3X_CRC8_INIT) == block[2] ?
+		       0 :
+		       -EIO;
+}
+
+static int slf3x_write_cmd(struct i2c_client *client, const u8 *cmd)
+{
+	int ret = i2c_master_send(client, cmd, 2);
+
+	if (ret == 2)
+		return 0;
+	return ret < 0 ? ret : -EIO;
+}
+
+static int slf3x_read_product_info(struct slf3x_data *sf)
+{
+	struct i2c_client *client = sf->client;
+	u8 buf[SLF3X_PRODUCT_ID_LEN];
+	int ret, i;
+
+	ret = slf3x_write_cmd(client, slf3x_cmd_prep_pid);
+	if (ret)
+		return ret;
+
+	ret = slf3x_write_cmd(client, slf3x_cmd_read_pid);
+	if (ret)
+		return ret;
+
+	ret = i2c_master_recv(client, buf, sizeof(buf));
+	if (ret != sizeof(buf))
+		return ret < 0 ? ret : -EIO;
+
+	for (i = 0; i < SLF3X_PRODUCT_ID_LEN; i += 3) {
+		if (slf3x_verify_crc(&buf[i])) {
+			dev_err(&client->dev,
+				"product-info CRC mismatch at byte %d\n", i);
+			return -EIO;
+		}
+	}
+
+	if (buf[SLF3X_FAMILY_BYTE] != SLF3X_FAMILY_ID) {
+		dev_err(&client->dev,
+			"unexpected device family 0x%02x\n",
+			buf[SLF3X_FAMILY_BYTE]);
+		return -ENODEV;
+	}
+
+	for (i = 0; i < ARRAY_SIZE(slf3x_variants); i++) {
+		if (buf[SLF3X_SUBTYPE_BYTE] == slf3x_variants[i].sub_type) {
+			sf->variant = &slf3x_variants[i];
+			return 0;
+		}
+	}
+
+	dev_err(&client->dev, "unsupported SLF3x sub-type 0x%02x\n",
+		buf[SLF3X_SUBTYPE_BYTE]);
+	return -ENODEV;
+}
+
+static int slf3x_read_sample(struct slf3x_data *sf, s16 *flow, s16 *temp)
+{
+	u8 buf[SLF3X_MEAS_LEN];
+	int ret, i;
+
+	ret = i2c_master_recv(sf->client, buf, sizeof(buf));
+	if (ret != sizeof(buf))
+		return ret < 0 ? ret : -EIO;
+
+	for (i = 0; i < SLF3X_MEAS_LEN; i += 3) {
+		if (slf3x_verify_crc(&buf[i]))
+			return -EIO;
+	}
+
+	*flow = (s16)get_unaligned_be16(&buf[0]);
+	*temp = (s16)get_unaligned_be16(&buf[3]);
+	return 0;
+}
+
+static const struct iio_chan_spec slf3x_channels[] = {
+	{
+		.type = IIO_VOLUMEFLOW,
+		.info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
+				      BIT(IIO_CHAN_INFO_SCALE),
+	},
+	{
+		.type = IIO_TEMP,
+		.info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
+				      BIT(IIO_CHAN_INFO_SCALE),
+	},
+};
+
+static int slf3x_read_raw(struct iio_dev *indio_dev,
+			  struct iio_chan_spec const *chan, int *val,
+			  int *val2, long mask)
+{
+	struct slf3x_data *sf = iio_priv(indio_dev);
+	s16 flow, temp;
+	int ret;
+
+	switch (mask) {
+	case IIO_CHAN_INFO_RAW:
+		ret = slf3x_read_sample(sf, &flow, &temp);
+		if (ret)
+			return ret;
+		*val = (chan->type == IIO_VOLUMEFLOW) ? flow : temp;
+		return IIO_VAL_INT;
+	case IIO_CHAN_INFO_SCALE:
+		if (chan->type == IIO_VOLUMEFLOW) {
+			*val = sf->variant->scale_num;
+			*val2 = sf->variant->scale_den;
+			return IIO_VAL_FRACTIONAL;
+		}
+		*val = SLF3X_TEMP_SCALE;
+		return IIO_VAL_INT;
+	default:
+		return -EINVAL;
+	}
+}
+
+static const struct iio_info slf3x_info = {
+	.read_raw = slf3x_read_raw,
+};
+
+static void slf3x_stop_meas(void *data)
+{
+	struct slf3x_data *sf = data;
+
+	slf3x_write_cmd(sf->client, slf3x_cmd_stop);
+}
+
+static int slf3x_probe(struct i2c_client *client)
+{
+	struct device *dev = &client->dev;
+	struct iio_dev *indio_dev;
+	struct slf3x_data *sf;
+	int ret;
+
+	ret = devm_regulator_get_enable_optional(dev, "vdd");
+	if (ret < 0 && ret != -ENODEV)
+		return dev_err_probe(dev, ret, "failed to enable vdd\n");
+
+	indio_dev = devm_iio_device_alloc(dev, sizeof(*sf));
+	if (!indio_dev)
+		return -ENOMEM;
+
+	sf = iio_priv(indio_dev);
+	sf->client = client;
+	crc8_populate_msb(slf3x_crc_table, SLF3X_CRC8_POLY);
+
+	ret = slf3x_read_product_info(sf);
+	if (ret)
+		return dev_err_probe(dev, ret, "product info read failed\n");
+
+	ret = slf3x_write_cmd(client, slf3x_cmd_start_water);
+	if (ret)
+		return dev_err_probe(dev, ret, "start measurement failed\n");
+
+	usleep_range(SLF3X_MEAS_DELAY_US, SLF3X_MEAS_DELAY_US + 1000);
+
+	ret = devm_add_action_or_reset(dev, slf3x_stop_meas, sf);
+	if (ret)
+		return ret;
+
+	indio_dev->name = sf->variant->name;
+	indio_dev->channels = slf3x_channels;
+	indio_dev->num_channels = ARRAY_SIZE(slf3x_channels);
+	indio_dev->info = &slf3x_info;
+	indio_dev->modes = INDIO_DIRECT_MODE;
+
+	return devm_iio_device_register(dev, indio_dev);
+}
+
+static const struct i2c_device_id slf3x_id[] = {
+	{ "slf3s" },
+	{ }
+};
+MODULE_DEVICE_TABLE(i2c, slf3x_id);
+
+static const struct of_device_id slf3x_of_match[] = {
+	{ .compatible = "sensirion,slf3s" },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, slf3x_of_match);
+
+static struct i2c_driver slf3x_driver = {
+	.driver = {
+		.name = "slf3x",
+		.of_match_table = slf3x_of_match,
+	},
+	.probe = slf3x_probe,
+	.id_table = slf3x_id,
+};
+module_i2c_driver(slf3x_driver);
+
+MODULE_AUTHOR("Wadim Mueller <wadim.mueller@cmblu.de>");
+MODULE_DESCRIPTION("Sensirion SLF3x liquid flow sensor driver");
+MODULE_LICENSE("GPL");
-- 
2.52.0

Re: [RFC PATCH v1 3/4] iio: flow: add Sensirion SLF3x liquid flow sensor driver

[Guenter Roeck]

On 5/24/26 13:49, Wadim Mueller wrote:
> From: Wadim Mueller <wadim.mueller@cmblu.de>
> 
> Add an IIO driver for the Sensirion SLF3S family of digital
> liquid-flow sensors.  The supported sub-types (SLF3S-0600F,
> SLF3S-4000B) share the same register map and command set and are
> distinguished only by the flow scale; the variant is detected at
> probe time from the product-information register.
> 
Sice you are at it, it might make sense to also support SLF3S-1300F.


> The driver exposes two IIO channels:
>    - in_volumeflow_raw / in_volumeflow_scale (litres per second)
>    - in_temp_raw       / in_temp_scale       (milli-degC)
> 
> Continuous measurement mode is started in probe and stopped via
> devm-action; read_raw() fetches the most recent sample on demand.
> 
> Signed-off-by: Wadim Mueller <wadim.mueller@cmblu.de>
> ---
>   drivers/iio/Kconfig       |   1 +
>   drivers/iio/Makefile      |   1 +
>   drivers/iio/flow/Kconfig  |  22 ++++
>   drivers/iio/flow/Makefile |   7 +
>   drivers/iio/flow/slf3x.c  | 264 ++++++++++++++++++++++++++++++++++++++

What does the "X" refer to ? Why not "S" ?

>   5 files changed, 295 insertions(+)
>   create mode 100644 drivers/iio/flow/Kconfig
>   create mode 100644 drivers/iio/flow/Makefile
>   create mode 100644 drivers/iio/flow/slf3x.c
> 
> diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
> index 661127aed..652557a5b 100644
> --- a/drivers/iio/Kconfig
> +++ b/drivers/iio/Kconfig
> @@ -92,6 +92,7 @@ source "drivers/iio/common/Kconfig"
>   source "drivers/iio/dac/Kconfig"
>   source "drivers/iio/dummy/Kconfig"
>   source "drivers/iio/filter/Kconfig"
> +source "drivers/iio/flow/Kconfig"
>   source "drivers/iio/frequency/Kconfig"
>   source "drivers/iio/gyro/Kconfig"
>   source "drivers/iio/health/Kconfig"
> diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
> index cb80ef837..f03a4100c 100644
> --- a/drivers/iio/Makefile
> +++ b/drivers/iio/Makefile
> @@ -29,6 +29,7 @@ obj-y += dac/
>   obj-y += dummy/
>   obj-y += gyro/
>   obj-y += filter/
> +obj-y += flow/
>   obj-y += frequency/
>   obj-y += health/
>   obj-y += humidity/
> diff --git a/drivers/iio/flow/Kconfig b/drivers/iio/flow/Kconfig
> new file mode 100644
> index 000000000..355857a6b
> --- /dev/null
> +++ b/drivers/iio/flow/Kconfig
> @@ -0,0 +1,22 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +#
> +# Liquid / gas flow sensor drivers
> +#
> +# When adding new entries keep the list in alphabetical order
> +
> +menu "Flow sensors"
> +
> +config SENSIRION_SLF3X
> +	tristate "Sensirion SLF3x liquid flow sensor"
> +	depends on I2C
> +	select CRC8
> +	help
> +	  Say yes here to build support for the Sensirion SLF3S family of
> +	  digital liquid-flow sensors (SLF3S-0600F, SLF3S-4000B, ...).
> +	  The driver reports the volumetric flow rate and the embedded
> +	  temperature reading via the standard IIO interface.
> +
> +	  To compile this driver as a module, choose M here: the module
> +	  will be called slf3x.
> +
> +endmenu
> diff --git a/drivers/iio/flow/Makefile b/drivers/iio/flow/Makefile
> new file mode 100644
> index 000000000..9eb9bdde0
> --- /dev/null
> +++ b/drivers/iio/flow/Makefile
> @@ -0,0 +1,7 @@
> +# SPDX-License-Identifier: GPL-2.0
> +#
> +# Makefile for industrial I/O flow sensor drivers
> +#
> +
> +# When adding new entries keep the list in alphabetical order
> +obj-$(CONFIG_SENSIRION_SLF3X) += slf3x.o
> diff --git a/drivers/iio/flow/slf3x.c b/drivers/iio/flow/slf3x.c
> new file mode 100644
> index 000000000..e4ee1a04a
> --- /dev/null
> +++ b/drivers/iio/flow/slf3x.c
> @@ -0,0 +1,264 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Sensirion SLF3x liquid flow sensor driver.
> + *
> + * Copyright (C) 2026 CMBlu Energy
> + * Author: Wadim Mueller <wadim.mueller@cmblu.de>
> + */
> +
> +#include <linux/crc8.h>
> +#include <linux/delay.h>
> +#include <linux/i2c.h>
> +#include <linux/iio/iio.h>
> +#include <linux/mod_devicetable.h>
> +#include <linux/module.h>
> +#include <linux/regulator/consumer.h>
> +
> +#include <linux/unaligned.h>
> +
> +#define SLF3X_CRC8_POLY		0x31
> +#define SLF3X_CRC8_INIT		0xff
> +
> +#define SLF3X_PRODUCT_ID_LEN	18
> +#define SLF3X_FAMILY_BYTE	1
> +#define SLF3X_SUBTYPE_BYTE	3
> +
> +#define SLF3X_FAMILY_ID		0x03
> +
> +#define SLF3X_MEAS_LEN		9
> +#define SLF3X_MEAS_DELAY_US	12000
> +
> +/* Temperature LSB is 1/200 °C; IIO_TEMP scale is in mC/LSB => 5. */
> +#define SLF3X_TEMP_SCALE	5
> +
> +static const u8 slf3x_cmd_prep_pid[]	= { 0x36, 0x7c };
> +static const u8 slf3x_cmd_read_pid[]	= { 0xe1, 0x02 };
> +static const u8 slf3x_cmd_start_water[]	= { 0x36, 0x08 };

I looked at LQ_DS_SLF3S-1300F, LQ_DS_SLF3S-0600F, and LQ_DS_SLF3S-4000B.
They all also support Isopropyl alcohol (IPA) measurements.

Would it make sense to also provide support for other liquid types
besides water ? That could be a sysfs attribute and/or a devicetree
property.

> +static const u8 slf3x_cmd_stop[]	= { 0x3f, 0xf9 };
> +
> +DECLARE_CRC8_TABLE(slf3x_crc_table);
> +
> +struct slf3x_variant {
> +	u8 sub_type;
> +	const char *name;
> +	/*
> +	 * Flow scale exposed via IIO_CHAN_INFO_SCALE in litres per second
> +	 * per LSB, encoded as IIO_VAL_FRACTIONAL (num / den).  The encoding
> +	 * comes from the Sensirion datasheet's "scale factor" (ticks per
> +	 * ml/min) combined with the 1 ml/min = 1/60000 l/s conversion.
> +	 */

Not my call to make, but at least the Sensirion sensors all talk about
flow rate per minute, not per second. A Google search suggests that
flow rate is normally measured per minute or even per hour, and that
per-second measurements are typically only used for large-scale engineering,
rivers, dams, and rapid industrial chemical dosing. Taking SLF3S-0600F
as example, it measures up to ±2000 µl/min (!). Even Sensirion's gas
sensors use per-minute flow rates.

Any special reason to use a per-second rate ?

> +	int scale_num;
> +	int scale_den;
> +};
> +
> +static const struct slf3x_variant slf3x_variants[] = {
> +	{ .sub_type = 0x03, .name = "slf3s-0600f",
> +	  .scale_num = 1, .scale_den = 6000000 },
> +	{ .sub_type = 0x05, .name = "slf3s-4000b",
> +	  .scale_num = 1, .scale_den = 1666680000 },
> +};
> +
> +struct slf3x_data {
> +	struct i2c_client *client;
> +	const struct slf3x_variant *variant;
> +};
> +
> +static int slf3x_verify_crc(const u8 *block)
> +{
> +	return crc8(slf3x_crc_table, block, 2, SLF3X_CRC8_INIT) == block[2] ?
> +		       0 :
> +		       -EIO;

This returns -EIO on error ...

> +}
> +
> +static int slf3x_write_cmd(struct i2c_client *client, const u8 *cmd)
> +{
> +	int ret = i2c_master_send(client, cmd, 2);
> +
> +	if (ret == 2)
> +		return 0;
> +	return ret < 0 ? ret : -EIO;
> +}
> +
> +static int slf3x_read_product_info(struct slf3x_data *sf)
> +{
> +	struct i2c_client *client = sf->client;
> +	u8 buf[SLF3X_PRODUCT_ID_LEN];
> +	int ret, i;
> +
> +	ret = slf3x_write_cmd(client, slf3x_cmd_prep_pid);
> +	if (ret)
> +		return ret;
> +
> +	ret = slf3x_write_cmd(client, slf3x_cmd_read_pid);
> +	if (ret)
> +		return ret;
> +
> +	ret = i2c_master_recv(client, buf, sizeof(buf));
> +	if (ret != sizeof(buf))
> +		return ret < 0 ? ret : -EIO;
> +
> +	for (i = 0; i < SLF3X_PRODUCT_ID_LEN; i += 3) {
> +		if (slf3x_verify_crc(&buf[i])) {

... which is then ignored here and replaced by -EIO.

Why not just have it return a boolean ?

> +			dev_err(&client->dev,
> +				"product-info CRC mismatch at byte %d\n", i);
> +			return -EIO;
> +		}
> +	}
> +
> +	if (buf[SLF3X_FAMILY_BYTE] != SLF3X_FAMILY_ID) {
> +		dev_err(&client->dev,
> +			"unexpected device family 0x%02x\n",
> +			buf[SLF3X_FAMILY_BYTE]);
> +		return -ENODEV;
> +	}
> +
> +	for (i = 0; i < ARRAY_SIZE(slf3x_variants); i++) {
> +		if (buf[SLF3X_SUBTYPE_BYTE] == slf3x_variants[i].sub_type) {
> +			sf->variant = &slf3x_variants[i];
> +			return 0;
> +		}
> +	}
> +
> +	dev_err(&client->dev, "unsupported SLF3x sub-type 0x%02x\n",
> +		buf[SLF3X_SUBTYPE_BYTE]);

Not my call to make, but the driver is way too noisy for my liking.

> +	return -ENODEV;
> +}
> +
> +static int slf3x_read_sample(struct slf3x_data *sf, s16 *flow, s16 *temp)
> +{
> +	u8 buf[SLF3X_MEAS_LEN];
> +	int ret, i;
> +
> +	ret = i2c_master_recv(sf->client, buf, sizeof(buf));
> +	if (ret != sizeof(buf))
> +		return ret < 0 ? ret : -EIO;
> +
> +	for (i = 0; i < SLF3X_MEAS_LEN; i += 3) {
> +		if (slf3x_verify_crc(&buf[i]))
> +			return -EIO;
> +	}
> +
> +	*flow = (s16)get_unaligned_be16(&buf[0]);
> +	*temp = (s16)get_unaligned_be16(&buf[3]);
> +	return 0;
> +}
> +
> +static const struct iio_chan_spec slf3x_channels[] = {
> +	{
> +		.type = IIO_VOLUMEFLOW,
> +		.info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
> +				      BIT(IIO_CHAN_INFO_SCALE),
> +	},
> +	{
> +		.type = IIO_TEMP,
> +		.info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
> +				      BIT(IIO_CHAN_INFO_SCALE),
> +	},
> +};
> +
> +static int slf3x_read_raw(struct iio_dev *indio_dev,
> +			  struct iio_chan_spec const *chan, int *val,
> +			  int *val2, long mask)
> +{
> +	struct slf3x_data *sf = iio_priv(indio_dev);
> +	s16 flow, temp;
> +	int ret;
> +
> +	switch (mask) {
> +	case IIO_CHAN_INFO_RAW:
> +		ret = slf3x_read_sample(sf, &flow, &temp);
> +		if (ret)
> +			return ret;
> +		*val = (chan->type == IIO_VOLUMEFLOW) ? flow : temp;
> +		return IIO_VAL_INT;
> +	case IIO_CHAN_INFO_SCALE:
> +		if (chan->type == IIO_VOLUMEFLOW) {
> +			*val = sf->variant->scale_num;
> +			*val2 = sf->variant->scale_den;
> +			return IIO_VAL_FRACTIONAL;
> +		}
> +		*val = SLF3X_TEMP_SCALE;
> +		return IIO_VAL_INT;
> +	default:
> +		return -EINVAL;
> +	}
> +}
> +
> +static const struct iio_info slf3x_info = {
> +	.read_raw = slf3x_read_raw,
> +};
> +
> +static void slf3x_stop_meas(void *data)
> +{
> +	struct slf3x_data *sf = data;
> +
> +	slf3x_write_cmd(sf->client, slf3x_cmd_stop);
> +}
> +
> +static int slf3x_probe(struct i2c_client *client)
> +{
> +	struct device *dev = &client->dev;
> +	struct iio_dev *indio_dev;
> +	struct slf3x_data *sf;
> +	int ret;
> +
> +	ret = devm_regulator_get_enable_optional(dev, "vdd");
> +	if (ret < 0 && ret != -ENODEV)
> +		return dev_err_probe(dev, ret, "failed to enable vdd\n");
> +
> +	indio_dev = devm_iio_device_alloc(dev, sizeof(*sf));
> +	if (!indio_dev)
> +		return -ENOMEM;
> +
> +	sf = iio_priv(indio_dev);
> +	sf->client = client;
> +	crc8_populate_msb(slf3x_crc_table, SLF3X_CRC8_POLY);
> +
> +	ret = slf3x_read_product_info(sf);
> +	if (ret)
> +		return dev_err_probe(dev, ret, "product info read failed\n");
> +
> +	ret = slf3x_write_cmd(client, slf3x_cmd_start_water);
> +	if (ret)
> +		return dev_err_probe(dev, ret, "start measurement failed\n");
> +
> +	usleep_range(SLF3X_MEAS_DELAY_US, SLF3X_MEAS_DELAY_US + 1000);
> +
> +	ret = devm_add_action_or_reset(dev, slf3x_stop_meas, sf);
> +	if (ret)
> +		return ret;
> +
> +	indio_dev->name = sf->variant->name;
> +	indio_dev->channels = slf3x_channels;
> +	indio_dev->num_channels = ARRAY_SIZE(slf3x_channels);
> +	indio_dev->info = &slf3x_info;
> +	indio_dev->modes = INDIO_DIRECT_MODE;
> +
> +	return devm_iio_device_register(dev, indio_dev);
> +}
> +
> +static const struct i2c_device_id slf3x_id[] = {
> +	{ "slf3s" },
> +	{ }
> +};
> +MODULE_DEVICE_TABLE(i2c, slf3x_id);
> +
> +static const struct of_device_id slf3x_of_match[] = {
> +	{ .compatible = "sensirion,slf3s" },
> +	{ }
> +};
> +MODULE_DEVICE_TABLE(of, slf3x_of_match);
> +
> +static struct i2c_driver slf3x_driver = {
> +	.driver = {
> +		.name = "slf3x",
> +		.of_match_table = slf3x_of_match,
> +	},
> +	.probe = slf3x_probe,
> +	.id_table = slf3x_id,
> +};
> +module_i2c_driver(slf3x_driver);
> +
> +MODULE_AUTHOR("Wadim Mueller <wadim.mueller@cmblu.de>");
> +MODULE_DESCRIPTION("Sensirion SLF3x liquid flow sensor driver");
> +MODULE_LICENSE("GPL");

Re: [RFC PATCH v1 3/4] iio: flow: add Sensirion SLF3x liquid flow sensor driver

[Jonathan Cameron]

On Sun, 24 May 2026 14:40:51 -0700
Guenter Roeck <linux@roeck-us.net> wrote:

> On 5/24/26 13:49, Wadim Mueller wrote:
> > From: Wadim Mueller <wadim.mueller@cmblu.de>
> > 
> > Add an IIO driver for the Sensirion SLF3S family of digital
> > liquid-flow sensors.  The supported sub-types (SLF3S-0600F,
> > SLF3S-4000B) share the same register map and command set and are
> > distinguished only by the flow scale; the variant is detected at
> > probe time from the product-information register.
> >   
> Sice you are at it, it might make sense to also support SLF3S-1300F.
> 
> 
> > The driver exposes two IIO channels:
> >    - in_volumeflow_raw / in_volumeflow_scale (litres per second)
> >    - in_temp_raw       / in_temp_scale       (milli-degC)
> > 
> > Continuous measurement mode is started in probe and stopped via
> > devm-action; read_raw() fetches the most recent sample on demand.
> > 
> > Signed-off-by: Wadim Mueller <wadim.mueller@cmblu.de>
> > ---
> >   drivers/iio/Kconfig       |   1 +
> >   drivers/iio/Makefile      |   1 +
> >   drivers/iio/flow/Kconfig  |  22 ++++
> >   drivers/iio/flow/Makefile |   7 +
> >   drivers/iio/flow/slf3x.c  | 264 ++++++++++++++++++++++++++++++++++++++  
> 
> What does the "X" refer to ? Why not "S" ?

Absolutely - no wild cards in file names or indeed in variables etc.
Just pick a part to name after.  Wild cards go wrong far too often!

A couple more follow ups below to some of what Guenter noted

> > +static const u8 slf3x_cmd_stop[]	= { 0x3f, 0xf9 };
> > +
> > +DECLARE_CRC8_TABLE(slf3x_crc_table);
> > +
> > +struct slf3x_variant {
> > +	u8 sub_type;
> > +	const char *name;
> > +	/*
> > +	 * Flow scale exposed via IIO_CHAN_INFO_SCALE in litres per second
> > +	 * per LSB, encoded as IIO_VAL_FRACTIONAL (num / den).  The encoding
> > +	 * comes from the Sensirion datasheet's "scale factor" (ticks per
> > +	 * ml/min) combined with the 1 ml/min = 1/60000 l/s conversion.
> > +	 */  
> 
> Not my call to make, but at least the Sensirion sensors all talk about
> flow rate per minute, not per second. A Google search suggests that
> flow rate is normally measured per minute or even per hour, and that
> per-second measurements are typically only used for large-scale engineering,
> rivers, dams, and rapid industrial chemical dosing. Taking SLF3S-0600F
> as example, it measures up to ±2000 µl/min (!). Even Sensirion's gas
> sensors use per-minute flow rates.
> 
> Any special reason to use a per-second rate ?

As I just replied to the cover letter - things in IIO that have relationship
to time (delays, integration times etc) are in seconds. 
Would be very confusing to mix and match. In general for new channel types
we stick to SI units without multipliers.

> 
> > +	int scale_num;
> > +	int scale_den;
> > +};

> > +			dev_err(&client->dev,
> > +				"product-info CRC mismatch at byte %d\n", i);
> > +			return -EIO;
> > +		}
> > +	}
> > +
> > +	if (buf[SLF3X_FAMILY_BYTE] != SLF3X_FAMILY_ID) {
> > +		dev_err(&client->dev,
> > +			"unexpected device family 0x%02x\n",
> > +			buf[SLF3X_FAMILY_BYTE]);
> > +		return -ENODEV;

Similar to below. This can't be an error or we break fallback
compatibles in DT. There are historic drivers that do this that
we haven't fixed up yet - but no new ones please!

> > +	}
> > +
> > +	for (i = 0; i < ARRAY_SIZE(slf3x_variants); i++) {
> > +		if (buf[SLF3X_SUBTYPE_BYTE] == slf3x_variants[i].sub_type) {
> > +			sf->variant = &slf3x_variants[i];
> > +			return 0;
> > +		}
> > +	}
> > +
> > +	dev_err(&client->dev, "unsupported SLF3x sub-type 0x%02x\n",
> > +		buf[SLF3X_SUBTYPE_BYTE]);  
> 
> Not my call to make, but the driver is way too noisy for my liking.
> 
Given the need to support fallback compatibles from device tree we don't
fail at all on mismatches as that prevents use supporting a new fully
backwards compatible (other than IDs) part in older kernels.

Whether a dev_info() or dev_dbg() is appropriate for such a case is
less obvious but definitely dev_err().

> > +	return -ENODEV;
and it's not an error to read an unexpected ID.
> > +}

Re: [RFC PATCH v1 3/4] iio: flow: add Sensirion SLF3x liquid flow sensor driver

[Wadim Mueller]

On Tue, 26 May 2026 17:06:18 +0100
Jonathan Cameron <jic23@kernel.org> wrote:

> > > What does the "X" refer to ? Why not "S" ?  
> 
> Absolutely - no wild cards in file names or indeed in variables etc.
> Just pick a part to name after.  Wild cards go wrong far too often!

Done in v2.  Renamed everywhere: slf3x.c -> slf3s.c, SLF3X_* ->
SLF3S_*, CONFIG_SENSIRION_SLF3X -> CONFIG_SENSIRION_SLF3S,
MAINTAINERS and binding titles too.

> > > +			dev_err(&client->dev,
> > > +				"unexpected device family 0x%02x\n",
> > > +				buf[SLF3X_FAMILY_BYTE]);
> > > +			return -ENODEV;  
> 
> Similar to below. This can't be an error or we break fallback
> compatibles in DT. There are historic drivers that do this that
> we haven't fixed up yet - but no new ones please!

Done in v2.  Unexpected family byte and unknown sub-type both
go to dev_dbg() now; the driver keeps the variant the compatible
/ id_table selected.  Only CRC failures and bus errors fail probe.

> Given the need to support fallback compatibles from device tree we don't
> fail at all on mismatches as that prevents use supporting a new fully
> backwards compatible (other than IDs) part in older kernels.
> 
> Whether a dev_info() or dev_dbg() is appropriate for such a case is
> less obvious but definitely dev_err().

Went with dev_dbg() for the unknown-sub-type / fallback path -
silent by default, discoverable when chasing a quirk.

Thanks,
Wadim

Re: [RFC PATCH v1 3/4] iio: flow: add Sensirion SLF3x liquid flow sensor driver

[Wadim Mueller]

On Sun, 24 May 2026 14:40:51 -0700
Guenter Roeck <linux@roeck-us.net> wrote:

> Sice you are at it, it might make sense to also support SLF3S-1300F.

Done in v2.  scale_den = 30 000 000 (500 (ml/min)^-1, Table 15 of
the LQ_DS_SLF3S-1300F datasheet) and sub_type byte 0x02 (Table 13,
product number 0x07030202).  Re-checked 0600F (0x07030302 -> 0x03)
and 4000B (0x07030501 -> 0x05) while I was at it, so all three
entries now match the published product numbers.

> > +	{ "sensirion,slf3s-0600f", "slf3s-0600f", ... }
> > drivers/iio/flow/slf3x.c
> What does the "X" refer to ? Why not "S" ?

Done in v2.  Renamed everywhere - slf3x.c -> slf3s.c, SLF3X_* ->
SLF3S_*, Kconfig symbol and MAINTAINERS title too.

> > +static const u8 slf3x_cmd_start_water[]	= { 0x36, 0x08 };  
> 
> I looked at LQ_DS_SLF3S-1300F, LQ_DS_SLF3S-0600F, and LQ_DS_SLF3S-4000B.
> They all also support Isopropyl alcohol (IPA) measurements.
> 
> Would it make sense to also provide support for other liquid types
> besides water ? That could be a sysfs attribute and/or a devicetree
> property.

Picked up in v2.  All three variants are factory-calibrated for
H2O and IPA; the scale factor and temperature interpretation are
identical, only the start command differs (0x3608 vs 0x3615).
v2 adds a "sensirion,medium" DT property (enum "water" / "ipa",
default water) that selects the start command at probe time, and
the binding (patch 2/3) documents it.  Kept this as a probe-time
choice instead of a sysfs attribute since switching mid-run needs
a stop anyway per the datasheet.

> > +static int slf3x_verify_crc(const u8 *block)
> > +{
> > +	return crc8(slf3x_crc_table, block, 2, SLF3X_CRC8_INIT) == block[2] ?
> > +		       0 :
> > +		       -EIO;  
> This returns -EIO on error ...
> > +
> > +	for (i = 0; i < SLF3X_PRODUCT_ID_LEN; i += 3) {
> > +		if (slf3x_verify_crc(&buf[i])) {  
> ... which is then ignored here and replaced by -EIO.
> 
> Why not just have it return a boolean ?

Done in v2.  slf3s_crc_valid() returns bool now; the call sites
translate false into -EIO themselves.

> > +	dev_err(&client->dev, "unsupported SLF3x sub-type 0x%02x\n",
> > +		buf[SLF3X_SUBTYPE_BYTE]);  
> 
> Not my call to make, but the driver is way too noisy for my liking.

Toned down in v2:

  - Unknown sub-type / unexpected family byte -> dev_dbg() and
    keep going (also covers Jonathan's fallback-compatibles point).
  - CRC mismatches -> dev_err_probe() in probe / dev_err() in
    read_raw, one line per failure instead of per-byte spam.

Thanks,
Wadim

Re: [RFC PATCH v1 3/4] iio: flow: add Sensirion SLF3x liquid flow sensor driver

[Jonathan Cameron]

On Sun, 24 May 2026 22:49:38 +0200
Wadim Mueller <wafgo01@gmail.com> wrote:

> From: Wadim Mueller <wadim.mueller@cmblu.de>
> 
> Add an IIO driver for the Sensirion SLF3S family of digital
> liquid-flow sensors.  The supported sub-types (SLF3S-0600F,
> SLF3S-4000B) share the same register map and command set and are
> distinguished only by the flow scale; the variant is detected at
> probe time from the product-information register.
> 
> The driver exposes two IIO channels:
>   - in_volumeflow_raw / in_volumeflow_scale (litres per second)
>   - in_temp_raw       / in_temp_scale       (milli-degC)
> 
> Continuous measurement mode is started in probe and stopped via
> devm-action; read_raw() fetches the most recent sample on demand.
> 
> Signed-off-by: Wadim Mueller <wadim.mueller@cmblu.de>
Hi Wadim

Hopefully I haven't overlapped too much with the review Guenter did.

Various comments inline

Thanks,

Jonathan

> diff --git a/drivers/iio/flow/Kconfig b/drivers/iio/flow/Kconfig
> new file mode 100644
> index 000000000..355857a6b
> --- /dev/null
> +++ b/drivers/iio/flow/Kconfig
> @@ -0,0 +1,22 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +#
> +# Liquid / gas flow sensor drivers
> +#
> +# When adding new entries keep the list in alphabetical order
> +
> +menu "Flow sensors"
> +
> +config SENSIRION_SLF3X
> +	tristate "Sensirion SLF3x liquid flow sensor"
> +	depends on I2C
> +	select CRC8
> +	help
> +	  Say yes here to build support for the Sensirion SLF3S family of
> +	  digital liquid-flow sensors (SLF3S-0600F, SLF3S-4000B, ...).

We try to have full listings of supported parts in the help text as it
gets searched by folk looking for a driver. To minimize the churn consider
a bulleted list with one per line.

> +	  The driver reports the volumetric flow rate and the embedded
> +	  temperature reading via the standard IIO interface.
> +
> +	  To compile this driver as a module, choose M here: the module
> +	  will be called slf3x.
> +
> +endmenu

> diff --git a/drivers/iio/flow/slf3x.c b/drivers/iio/flow/slf3x.c
> new file mode 100644
> index 000000000..e4ee1a04a
> --- /dev/null
> +++ b/drivers/iio/flow/slf3x.c
> @@ -0,0 +1,264 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Sensirion SLF3x liquid flow sensor driver.
> + *
> + * Copyright (C) 2026 CMBlu Energy
> + * Author: Wadim Mueller <wadim.mueller@cmblu.de>
> + */
> +
> +#include <linux/crc8.h>
> +#include <linux/delay.h>
> +#include <linux/i2c.h>
> +#include <linux/iio/iio.h>
> +#include <linux/mod_devicetable.h>
> +#include <linux/module.h>
> +#include <linux/regulator/consumer.h>
> +
> +#include <linux/unaligned.h>
The gap before this header and others in other drivers is an historical oddity as it used
to be in asm and the blanket rename didn't tidy up the white space.
No need to separate it.


> +DECLARE_CRC8_TABLE(slf3x_crc_table);
> +
> +struct slf3x_variant {
> +	u8 sub_type;
> +	const char *name;
> +	/*
> +	 * Flow scale exposed via IIO_CHAN_INFO_SCALE in litres per second
> +	 * per LSB, encoded as IIO_VAL_FRACTIONAL (num / den).  The encoding
> +	 * comes from the Sensirion datasheet's "scale factor" (ticks per
> +	 * ml/min) combined with the 1 ml/min = 1/60000 l/s conversion.
> +	 */
> +	int scale_num;
> +	int scale_den;
> +};
> +
> +static const struct slf3x_variant slf3x_variants[] = {
> +	{ .sub_type = 0x03, .name = "slf3s-0600f",
> +	  .scale_num = 1, .scale_den = 6000000 },
> +	{ .sub_type = 0x05, .name = "slf3s-4000b",
> +	  .scale_num = 1, .scale_den = 1666680000 },

Maybe format this as one per line.  These structure tend to grow as
more features are added to a driver so it will perhaps result in less
churn in the long run!
	{
		.sub_type = 0x05,
		.name = "slf3s-4000b",
		.scale_num = 1,
		.scale_den = 1666680000,
	},
> +};
...

> +static int slf3x_write_cmd(struct i2c_client *client, const u8 *cmd)

Might be good to use
const u8 cmd[at_least 2])
to let the compiler know the constraints.

> +{
> +	int ret = i2c_master_send(client, cmd, 2);
> +
> +	if (ret == 2)
> +		return 0;
> +	return ret < 0 ? ret : -EIO;
> +}
> +
> +static int slf3x_read_product_info(struct slf3x_data *sf)
> +{
> +	struct i2c_client *client = sf->client;
> +	u8 buf[SLF3X_PRODUCT_ID_LEN];
> +	int ret, i;
> +
> +	ret = slf3x_write_cmd(client, slf3x_cmd_prep_pid);
> +	if (ret)
> +		return ret;
> +
> +	ret = slf3x_write_cmd(client, slf3x_cmd_read_pid);
> +	if (ret)
> +		return ret;
> +
> +	ret = i2c_master_recv(client, buf, sizeof(buf));
> +	if (ret != sizeof(buf))
> +		return ret < 0 ? ret : -EIO;
> +
> +	for (i = 0; i < SLF3X_PRODUCT_ID_LEN; i += 3) {
> +		if (slf3x_verify_crc(&buf[i])) {
> +			dev_err(&client->dev,
> +				"product-info CRC mismatch at byte %d\n", i);
> +			return -EIO;
For all returns in stuff only called from probe() use dev_err_probe().

> +		}

> +
> +static int slf3x_read_sample(struct slf3x_data *sf, s16 *flow, s16 *temp)
> +{
> +	u8 buf[SLF3X_MEAS_LEN];
> +	int ret, i;
> +
> +	ret = i2c_master_recv(sf->client, buf, sizeof(buf));
> +	if (ret != sizeof(buf))
> +		return ret < 0 ? ret : -EIO;
> +
> +	for (i = 0; i < SLF3X_MEAS_LEN; i += 3) {
Fine to do
	for (unsigned int i = 0; i < ..

> +		if (slf3x_verify_crc(&buf[i]))
> +			return -EIO;
> +	}
> +
> +	*flow = (s16)get_unaligned_be16(&buf[0]);

Prefer to make this a little more self documenting as

	*flow = sign_extend32(get_unaligned_be16(&buf[0]), 15);
 
> +	*temp = (s16)get_unaligned_be16(&buf[3]);
> +	return 0;
> +}
> +
> +static const struct iio_chan_spec slf3x_channels[] = {
> +	{
> +		.type = IIO_VOLUMEFLOW,
> +		.info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
> +				      BIT(IIO_CHAN_INFO_SCALE),
> +	},
> +	{
> +		.type = IIO_TEMP,
> +		.info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
> +				      BIT(IIO_CHAN_INFO_SCALE),
> +	},
> +};
> +


> +
> +static void slf3x_stop_meas(void *data)
> +{
> +	struct slf3x_data *sf = data;
> +
> +	slf3x_write_cmd(sf->client, slf3x_cmd_stop);
> +}
> +
> +static int slf3x_probe(struct i2c_client *client)
> +{
> +	struct device *dev = &client->dev;
> +	struct iio_dev *indio_dev;
> +	struct slf3x_data *sf;
> +	int ret;
> +
> +	ret = devm_regulator_get_enable_optional(dev, "vdd");

No need to turn this on until we are somewhere nearer ready to chat
to the device.  Normally we do it just before first access.
I'd move it down a little. It's also not optional unless
there is some other way of powering the device.
Just let the regulator framework provide a stub regulator if it's not
in the firmware description.

> +	if (ret < 0 && ret != -ENODEV)
> +		return dev_err_probe(dev, ret, "failed to enable vdd\n");
> +
> +	indio_dev = devm_iio_device_alloc(dev, sizeof(*sf));
> +	if (!indio_dev)
> +		return -ENOMEM;
> +
> +	sf = iio_priv(indio_dev);
> +	sf->client = client;
> +	crc8_populate_msb(slf3x_crc_table, SLF3X_CRC8_POLY);
> +
> +	ret = slf3x_read_product_info(sf);
> +	if (ret)
> +		return dev_err_probe(dev, ret, "product info read failed\n");
As in the other review thread, this shouldn't be an error a we want
those fallback compatibles to work in future.

> +
> +	ret = slf3x_write_cmd(client, slf3x_cmd_start_water);
> +	if (ret)
> +		return dev_err_probe(dev, ret, "start measurement failed\n");
> +
> +	usleep_range(SLF3X_MEAS_DELAY_US, SLF3X_MEAS_DELAY_US + 1000);

fsleep() for fuzzy sleeps like this - it applies a standard amount of 'slack' time
and means we don't need to reason about whether that is a good value or not.


> +
> +	ret = devm_add_action_or_reset(dev, slf3x_stop_meas, sf);
> +	if (ret)
> +		return ret;

> +
> +	return devm_iio_device_register(dev, indio_dev);
> +}
> +
> +static const struct i2c_device_id slf3x_id[] = {
> +	{ "slf3s" },

Please use a named initializer here like you do for the of_device_id.
Uwe is working on making sure all drivers do this and I just took a patch
that updated most of the IIO ones to do so.


> +	{ }
> +};
> +MODULE_DEVICE_TABLE(i2c, slf3x_id);

Re: [RFC PATCH v1 3/4] iio: flow: add Sensirion SLF3x liquid flow sensor driver

[Wadim Mueller]

On Tue, 26 May 2026 17:35:31 +0100
Jonathan Cameron <jic23@kernel.org> wrote:

> Hopefully I haven't overlapped too much with the review Guenter did.

No overlap problem - replying to all the inline points below.

> > +	  Say yes here to build support for the Sensirion SLF3S family of
> > +	  digital liquid-flow sensors (SLF3S-0600F, SLF3S-4000B, ...).  
> 
> We try to have full listings of supported parts in the help text as it
> gets searched by folk looking for a driver. To minimize the churn consider
> a bulleted list with one per line.

Done in v2 - bulleted list with all currently supported parts
(SLF3S-0600F, SLF3S-1300F, SLF3S-4000B).

> > +#include <linux/unaligned.h>  
> The gap before this header and others in other drivers is an historical oddity ...
> No need to separate it.

Done in v2.

> > +static const struct slf3x_variant slf3x_variants[] = {
> > +	{ .sub_type = 0x03, .name = "slf3s-0600f",
> > +	  .scale_num = 1, .scale_den = 6000000 },
> > +	{ .sub_type = 0x05, .name = "slf3s-4000b",
> > +	  .scale_num = 1, .scale_den = 1666680000 },  
> 
> Maybe format this as one per line.

Done in v2.  One variant entry per line; the list grew by
SLF3S-1300F as Guenter asked.

> > +static int slf3x_write_cmd(struct i2c_client *client, const u8 *cmd)  
> 
> Might be good to use
> const u8 cmd[at_least 2])
> to let the compiler know the constraints.

Done in v2 - declared as `const u8 cmd[static 2]`.

> > +	for (i = 0; i < SLF3X_PRODUCT_ID_LEN; i += 3) {
> > +		if (slf3x_verify_crc(&buf[i])) {
> > +			dev_err(&client->dev,
> > +				"product-info CRC mismatch at byte %d\n", i);
> > +			return -EIO;  
> For all returns in stuff only called from probe() use dev_err_probe().

Done in v2.  All probe-path log+return pairs use dev_err_probe()
now; the remaining dev_err() calls are in the runtime read_raw
path.

> > +	for (i = 0; i < SLF3X_MEAS_LEN; i += 3) {  
> Fine to do
> 	for (unsigned int i = 0; i < ..

Done in v2.

> > +	*flow = (s16)get_unaligned_be16(&buf[0]);  
> 
> Prefer to make this a little more self documenting as
> 
> 	*flow = sign_extend32(get_unaligned_be16(&buf[0]), 15);

Done in v2 for both flow and temp.

> > +	ret = devm_regulator_get_enable_optional(dev, "vdd");  
> 
> No need to turn this on until we are somewhere nearer ready to chat
> to the device.  Normally we do it just before first access.
> I'd move it down a little. It's also not optional unless
> there is some other way of powering the device.
> Just let the regulator framework provide a stub regulator if it's not
> in the firmware description.

Done in v2.  Switched to devm_regulator_get_enable() and moved it
down so it runs just before the first I2C access (the product-info
read).

> > +	ret = slf3x_read_product_info(sf);
> > +	if (ret)
> > +		return dev_err_probe(dev, ret, "product info read failed\n");  
> As in the other review thread, this shouldn't be an error a we want
> those fallback compatibles to work in future.

Done in v2.  Unknown sub-type is dev_dbg() now and falls back to
the variant from the DT compatible (or the of_device_id .data for
the generic fallback).  CRC/family mismatches stay real errors.

> > +	usleep_range(SLF3X_MEAS_DELAY_US, SLF3X_MEAS_DELAY_US + 1000);  
> 
> fsleep() for fuzzy sleeps like this - it applies a standard amount of 'slack' time
> and means we don't need to reason about whether that is a good value or not.

Done in v2.

> > +static const struct i2c_device_id slf3x_id[] = {
> > +	{ "slf3s" },  
> 
> Please use a named initializer here like you do for the of_device_id.
> Uwe is working on making sure all drivers do this and I just took a patch
> that updated most of the IIO ones to do so.

Done in v2 - `{ .name = "slf3s-0600f" }` etc.  The i2c id table
mirrors the of_device_id list, with .driver_data pointing at the
matching slf3s_variant.

Thanks,
Wadim

Re: [RFC PATCH v1 3/4] iio: flow: add Sensirion SLF3x liquid flow sensor driver

[Jonathan Cameron]

On Sun, 24 May 2026 22:49:38 +0200
Wadim Mueller <wafgo01@gmail.com> wrote:

> From: Wadim Mueller <wadim.mueller@cmblu.de>
> 
> Add an IIO driver for the Sensirion SLF3S family of digital
> liquid-flow sensors.  The supported sub-types (SLF3S-0600F,
> SLF3S-4000B) share the same register map and command set and are
> distinguished only by the flow scale; the variant is detected at
> probe time from the product-information register.
> 
> The driver exposes two IIO channels:
>   - in_volumeflow_raw / in_volumeflow_scale (litres per second)
>   - in_temp_raw       / in_temp_scale       (milli-degC)
> 
> Continuous measurement mode is started in probe and stopped via
> devm-action; read_raw() fetches the most recent sample on demand.
> 
> Signed-off-by: Wadim Mueller <wadim.mueller@cmblu.de>
Also see:
https://sashiko.dev/#/patchset/20260524205112.26638-1-wafgo01%40gmail.com
It may well not be correct in all cases, but it often is!

The value of _scale seems like a plausible issue to me.
We have discussed expanding the range further than 9 decimal places
in the past. Seems like this might be the time we need to do it.
There is some work under review at the moment to allow more complex
fixed point handling but not sure it applies usefully here.

I also missed the crc table is global. Easy solution is take a copy.

Suspend / resume one is a value add for the future.

Jonathan

Re: [RFC PATCH v1 3/4] iio: flow: add Sensirion SLF3x liquid flow sensor driver

[Wadim Mueller]

On Tue, 26 May 2026 17:42:29 +0100
Jonathan Cameron <jic23@kernel.org> wrote:

> Also see:
> https://sashiko.dev/#/patchset/20260524205112.26638-1-wafgo01%40gmail.com
> It may well not be correct in all cases, but it often is!

Thanks for the pointer - went through the Sashiko output and
folded the actionable items in (bool returns, unsigned ints in
loops, fallback-compatible cleanup etc.); the rest is in v2.

> The value of _scale seems like a plausible issue to me.
> We have discussed expanding the range further than 9 decimal places
> in the past. Seems like this might be the time we need to do it.
> There is some work under review at the moment to allow more complex
> fixed point handling but not sure it applies usefully here.

Going back to the datasheets, v1 had the SLF3S-0600F and -4000B
scale_den values wrong; the SLF3S-1300F entry I added was just
carried over from 0600F as a placeholder.  v2 now uses the
published scale factors (Table 16 for 0600F, Table 15 for 1300F
and 4000B):

  SLF3S-0600F:  10 (ul/min)^-1   ->  1 /   600 000 000 (l/s)/LSB
  SLF3S-1300F: 500 (ml/min)^-1   ->  1 /    30 000 000 (l/s)/LSB
  SLF3S-4000B:  32 (ml/min)^-1   ->  1 /     1 920 000 (l/s)/LSB

So the SLF3S-4000B scale_den drops from ~1.67e9 to 1.92e6 and the
INT_MAX concern is gone.  Happy to follow up on top if the
extended fixed-point work lands in a useful form.

> I also missed the crc table is global. Easy solution is take a copy.

Done in v2 - the table lives now in struct slf3s_data and
crc8_populate_msb() runs per-instance in probe().

> Suspend / resume one is a value add for the future.

Acknowledged, parked for now.  Easy to add as soon as there is a
user for it.

Thanks,
Wadim

[RFC PATCH v1 4/4] MAINTAINERS: add entry for Sensirion SLF3x flow sensor driver

[Wadim Mueller]

From: Wadim Mueller <wadim.mueller@cmblu.de>

Signed-off-by: Wadim Mueller <wadim.mueller@cmblu.de>
---
 MAINTAINERS | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 06a8c7457..5cafa8c8f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -24187,6 +24187,13 @@ S:	Maintained
 F:	Documentation/ABI/testing/sysfs-bus-iio-chemical-sgp40
 F:	drivers/iio/chemical/sgp40.c
 
+SENSIRION SLF3X LIQUID FLOW SENSOR DRIVER
+M:	Wadim Mueller <wadim.mueller@cmblu.de>
+L:	linux-iio@vger.kernel.org
+S:	Maintained
+F:	Documentation/devicetree/bindings/iio/flow/sensirion,slf3s.yaml
+F:	drivers/iio/flow/slf3x.c
+
 SENSIRION SPS30 AIR POLLUTION SENSOR DRIVER
 M:	Tomasz Duszynski <tduszyns@gmail.com>
 S:	Maintained
-- 
2.52.0

Re: [RFC PATCH v1 4/4] MAINTAINERS: add entry for Sensirion SLF3x flow sensor driver

[Jonathan Cameron]

On Sun, 24 May 2026 22:49:39 +0200
Wadim Mueller <wafgo01@gmail.com> wrote:

> From: Wadim Mueller <wadim.mueller@cmblu.de>
> 
> Signed-off-by: Wadim Mueller <wadim.mueller@cmblu.de>
> ---
>  MAINTAINERS | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 06a8c7457..5cafa8c8f 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -24187,6 +24187,13 @@ S:	Maintained
>  F:	Documentation/ABI/testing/sysfs-bus-iio-chemical-sgp40
>  F:	drivers/iio/chemical/sgp40.c
>  
> +SENSIRION SLF3X LIQUID FLOW SENSOR DRIVER
> +M:	Wadim Mueller <wadim.mueller@cmblu.de>
> +L:	linux-iio@vger.kernel.org
> +S:	Maintained
> +F:	Documentation/devicetree/bindings/iio/flow/sensirion,slf3s.yaml
> +F:	drivers/iio/flow/slf3x.c
No need for separate patch.  Bring it in with the dt entry in the binding
patch then add the .c file in the following one.

thanks,

Jonathan

> +
>  SENSIRION SPS30 AIR POLLUTION SENSOR DRIVER
>  M:	Tomasz Duszynski <tduszyns@gmail.com>
>  S:	Maintained

Re: [RFC PATCH v1 4/4] MAINTAINERS: add entry for Sensirion SLF3x flow sensor driver

[Wadim Mueller]

On Tue, 26 May 2026 17:36:16 +0100
Jonathan Cameron <jic23@kernel.org> wrote:

> > +SENSIRION SLF3X LIQUID FLOW SENSOR DRIVER
> > +M:	Wadim Mueller <wafgo01@gmail.com>
> > +L:	linux-iio@vger.kernel.org
> > +S:	Maintained
> > +F:	Documentation/devicetree/bindings/iio/flow/sensirion,slf3s.yaml
> > +F:	drivers/iio/flow/slf3x.c  
> No need for separate patch.  Bring it in with the dt entry in the binding
> patch then add the .c file in the following one.

Done in v2.  MAINTAINERS hunk is in the driver patch (3/3); F:
line points at drivers/iio/flow/slf3s.c.  Series is 3 patches
now (types, dt-binding, driver+MAINTAINERS).

Thanks,
Wadim

Re: [RFC PATCH v1 4/4] MAINTAINERS: add entry for Sensirion SLF3x flow sensor driver

[Maxwell Doose]

Hi Wadim,

On Wed, May 27, 2026 at 9:37 AM Wadim Mueller <wafgo01@gmail.com> wrote:
>
> On Tue, 26 May 2026 17:36:16 +0100
> Jonathan Cameron <jic23@kernel.org> wrote:
>
> > > +SENSIRION SLF3X LIQUID FLOW SENSOR DRIVER
> > > +M: Wadim Mueller <wafgo01@gmail.com>
> > > +L: linux-iio@vger.kernel.org
> > > +S: Maintained
> > > +F: Documentation/devicetree/bindings/iio/flow/sensirion,slf3s.yaml
> > > +F: drivers/iio/flow/slf3x.c
> > No need for separate patch.  Bring it in with the dt entry in the binding
> > patch then add the .c file in the following one.
>
> Done in v2.  MAINTAINERS hunk is in the driver patch (3/3); F:
> line points at drivers/iio/flow/slf3s.c.  Series is 3 patches
> now (types, dt-binding, driver+MAINTAINERS).
>

I was taking a look at the data sheet for this device and thought it
was rather interesting. I'd be willing to help review patches for this
driver if you'd like :)

best regards,
max

Re: [RFC PATCH v1 4/4] MAINTAINERS: add entry for Sensirion SLF3x flow sensor driver

[Wadim Mueller]

On 2026-05-27 09:42, Maxwell Doose wrote:
> Hi Wadim,
> 
> On Wed, May 27, 2026 at 9:37 AM Wadim Mueller <wafgo01@gmail.com> wrote:
> >
> > On Tue, 26 May 2026 17:36:16 +0100
> > Jonathan Cameron <jic23@kernel.org> wrote:
> >
> > > > +SENSIRION SLF3X LIQUID FLOW SENSOR DRIVER
> > > > +M: Wadim Mueller <wafgo01@gmail.com>
> > > > +L: linux-iio@vger.kernel.org
> > > > +S: Maintained
> > > > +F: Documentation/devicetree/bindings/iio/flow/sensirion,slf3s.yaml
> > > > +F: drivers/iio/flow/slf3x.c
> > > No need for separate patch.  Bring it in with the dt entry in the binding
> > > patch then add the .c file in the following one.
> >
> > Done in v2.  MAINTAINERS hunk is in the driver patch (3/3); F:
> > line points at drivers/iio/flow/slf3s.c.  Series is 3 patches
> > now (types, dt-binding, driver+MAINTAINERS).
> >
> 
> I was taking a look at the data sheet for this device and thought it
> was rather interesting. I'd be willing to help review patches for this
> driver if you'd like :)
> 
> best regards,
> max

Hi Max, sure every reviewer is much appreciated. v2 will include you in
CC and an R: entry. 

Re: [RFC PATCH v1 0/4] iio: add Sensirion SLF3x liquid flow sensor support

[Jonathan Cameron]

On Sun, 24 May 2026 22:49:35 +0200
Wadim Mueller <wafgo01@gmail.com> wrote:

> From: Wadim Mueller <wadim.mueller@cmblu.de>
> 
> Hi all,
> 
> this RFC adds support for the Sensirion SLF3x family of liquid-flow
> sensors (SLF3S-0600F and SLF3S-4000B).  Before I send it as a normal
> patch I'd like to ask three things:
> 
> 1. Subsystem.  Liquid-flow sensors don't seem to have a home in
>    mainline yet.  iio/ feels like the natural place for me, but
>    please correct me if hwmon (or somewhere else) is prefered.

I'm fine with this type of sensor in IIO, but open to hear from others!

> 
> 2. Channel type.  IIO has no flow channel type so far.  The series
>    adds IIO_VOLUMEFLOW with _scale in litres per second per LSB,
>    so drivers reporting smaller units only need a fractional scale.
>    IIO_MASSFLOW (for gas-flow sensors) was left out on purpose --
>    happy to add it in the same series if that's more usefull.

Would be good to have a little more detail on difference etc to have
that discussion.  Superficially I'm assuming this is a compressible vs
non compressible thing?

> 
> 3. Subdirectory.  I put the driver in a new drivers/iio/flow/
>    since there is no flow subsytem in iio yet.  If colocating with
>    drivers/iio/pressure/ (next to sdp500) is preferred I'll respin.

This is easy to change later if we make a wrong decision. For now I think
iio/flow is fine.

Thanks

Jonathan


> 
> Patches:
> 
>   1/4  iio: types: add IIO_VOLUMEFLOW channel type
>   2/4  dt-bindings: iio: flow: add sensirion,slf3s binding
>   3/4  iio: flow: add Sensirion SLF3x driver
>   4/4  MAINTAINERS: add entry
> 
> Tested with a SLF3S-0600F on a TI AM64x platform.
> 
> Thanks,
> Wadim
> 
> Wadim Mueller (4):
>   iio: types: add IIO_VOLUMEFLOW channel type
>   dt-bindings: iio: flow: add Sensirion SLF3x liquid flow sensor
>   iio: flow: add Sensirion SLF3x liquid flow sensor driver
>   MAINTAINERS: add entry for Sensirion SLF3x flow sensor driver
> 
>  Documentation/ABI/testing/sysfs-bus-iio       |  17 ++
>  .../bindings/iio/flow/sensirion,slf3s.yaml    |  49 ++++
>  MAINTAINERS                                   |   7 +
>  drivers/iio/Kconfig                           |   1 +
>  drivers/iio/Makefile                          |   1 +
>  drivers/iio/flow/Kconfig                      |  22 ++
>  drivers/iio/flow/Makefile                     |   7 +
>  drivers/iio/flow/slf3x.c                      | 264 ++++++++++++++++++
>  drivers/iio/industrialio-core.c               |   1 +
>  include/uapi/linux/iio/types.h                |   1 +
>  tools/iio/iio_event_monitor.c                 |   2 +
>  11 files changed, 372 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iio/flow/sensirion,slf3s.yaml
>  create mode 100644 drivers/iio/flow/Kconfig
>  create mode 100644 drivers/iio/flow/Makefile
>  create mode 100644 drivers/iio/flow/slf3x.c
> 
> 
> base-commit: 3cd8b194bf3428dfa53120fee47e827a7c495815

Re: [RFC PATCH v1 0/4] iio: add Sensirion SLF3x liquid flow sensor support

[Wadim Mueller]

On Tue, 26 May 2026 17:12:14 +0100
Jonathan Cameron <jic23@kernel.org> wrote:

> > 1. Subsystem.  Liquid-flow sensors don't seem to have a home in
> >    mainline yet.  iio/ feels like the natural place for me, but
> >    please correct me if hwmon (or somewhere else) is prefered.  
> 
> I'm fine with this type of sensor in IIO, but open to hear from others!

Thanks - keeping it in iio/ for v2.

> > 2. Channel type.  IIO has no flow channel type so far.  The series
> >    adds IIO_VOLUMEFLOW with _scale in litres per second per LSB,
> >    so drivers reporting smaller units only need a fractional scale.
> >    IIO_MASSFLOW (for gas-flow sensors) was left out on purpose --
> >    happy to add it in the same series if that's more usefull.  
> 
> Would be good to have a little more detail on difference etc to have
> that discussion.  Superficially I'm assuming this is a compressible vs
> non compressible thing?

Right - that was the distinction I had in mind:

  - IIO_VOLUMEFLOW: volumetric rate (m^3/s in SI, exposed as l/s),
    well-defined for an incompressible fluid where the volume at the
    sensor equals the volume delivered.  This matches all "liquid
    flow" sensors I'm aware of (and the SLF3S family in particular).

  - IIO_MASSFLOW: mass rate (kg/s), the natural unit for gases because
    the volumetric rate depends on temperature and pressure.  Most
    "gas flow" parts on the market (Sensirion SFM3xxx, SFC, MFC
    devices) actually report a "standard volume flow" (e.g. slm at
    0 degC and 1013 mbar) which is just a fixed-density restatement
    of mass flow.

I left IIO_MASSFLOW out of this series because I don't have a driver
needing it right now, but if you'd prefer I add it as a stub here
(name + ABI entry) so the two siblings land together, I can fold that
in for v2 -- happy either way.

> > 3. Subdirectory.  I put the driver in a new drivers/iio/flow/
> >    since there is no flow subsytem in iio yet.  If colocating with
> >    drivers/iio/pressure/ (next to sdp500) is preferred I'll respin.  
> 
> This is easy to change later if we make a wrong decision. For now I think
> iio/flow is fine.

Sticking with drivers/iio/flow/ for v2.

Thanks!

v2 is up, addressing the inline review feedback from you and Guenter.
Dropping the RFC tag since the three high-level questions are
answered.

Wadim

Re: [RFC PATCH v1 0/4] iio: add Sensirion SLF3x liquid flow sensor support

[Jonathan Cameron]

On Wed, 27 May 2026 16:34:58 +0200
Wadim Mueller <wafgo01@gmail.com> wrote:

> On Tue, 26 May 2026 17:12:14 +0100
> Jonathan Cameron <jic23@kernel.org> wrote:
> 
> > > 1. Subsystem.  Liquid-flow sensors don't seem to have a home in
> > >    mainline yet.  iio/ feels like the natural place for me, but
> > >    please correct me if hwmon (or somewhere else) is prefered.    
> > 
> > I'm fine with this type of sensor in IIO, but open to hear from others!  
> 
> Thanks - keeping it in iio/ for v2.
> 
> > > 2. Channel type.  IIO has no flow channel type so far.  The series
> > >    adds IIO_VOLUMEFLOW with _scale in litres per second per LSB,
> > >    so drivers reporting smaller units only need a fractional scale.
> > >    IIO_MASSFLOW (for gas-flow sensors) was left out on purpose --
> > >    happy to add it in the same series if that's more usefull.    
> > 
> > Would be good to have a little more detail on difference etc to have
> > that discussion.  Superficially I'm assuming this is a compressible vs
> > non compressible thing?  
> 
> Right - that was the distinction I had in mind:
> 
>   - IIO_VOLUMEFLOW: volumetric rate (m^3/s in SI, exposed as l/s),
>     well-defined for an incompressible fluid where the volume at the
>     sensor equals the volume delivered.  This matches all "liquid
>     flow" sensors I'm aware of (and the SLF3S family in particular).
> 
>   - IIO_MASSFLOW: mass rate (kg/s), the natural unit for gases because
>     the volumetric rate depends on temperature and pressure.  Most
>     "gas flow" parts on the market (Sensirion SFM3xxx, SFC, MFC
>     devices) actually report a "standard volume flow" (e.g. slm at
>     0 degC and 1013 mbar) which is just a fixed-density restatement
>     of mass flow.
Makes sense.
> 
> I left IIO_MASSFLOW out of this series because I don't have a driver
> needing it right now, but if you'd prefer I add it as a stub here
> (name + ABI entry) so the two siblings land together, I can fold that
> in for v2 -- happy either way.
> 

Nope. Good to discuss what it would look like in this over letter, but
the actual introduction needs to wait for a driver that uses it.

> > > 3. Subdirectory.  I put the driver in a new drivers/iio/flow/
> > >    since there is no flow subsytem in iio yet.  If colocating with
> > >    drivers/iio/pressure/ (next to sdp500) is preferred I'll respin.    
> > 
> > This is easy to change later if we make a wrong decision. For now I think
> > iio/flow is fine.  
> 
> Sticking with drivers/iio/flow/ for v2.
> 
> Thanks!
> 
> v2 is up, addressing the inline review feedback from you and Guenter.
> Dropping the RFC tag since the three high-level questions are
> answered.
> 
> Wadim

[PATCH v2 0/3] iio: flow: Sensirion SLF3S liquid flow sensor

[Wadim Mueller]

Hi all,

v2 addresses the inline review feedback from Jonathan and Guenter on v1
(see https://lore.kernel.org/linux-iio/20260524205112.26638-1-wafgo01@gmail.com/).
Per-patch replies have been sent in the v1 thread.

The series is dropped from RFC: subsystem placement (iio/flow/),
channel type (IIO_VOLUMEFLOW) and the new subdirectory have all been
ACKed in v1.

Changes since v1:

  * rename driver/binding from slf3x to slf3s (Jonathan -- the
    marketing family name is SLF3S)
  * fold MAINTAINERS entry into the dt-binding patch instead of a
    separate 4/4 patch (Jonathan)
  * add SLF3S-1300F support (Guenter)
  * dt-binding: split the single "sensirion,slf3s" compatible into
    per-variant compatibles (-0600F, -1300F, -4000B) with a generic
    fallback (Jonathan)
  * dt-binding: add optional interrupts property (Guenter -- bindings
    describe the hardware, not the current driver)
  * driver: seed the variant from DT via i2c_get_match_data() instead
    of probing the sensor first (Jonathan)
  * driver: detect_variant() now trusts the DT-supplied variant and
    only emits dev_dbg() on a sub_type/family mismatch (Jonathan)
  * driver: per-instance crc8_populate_msb() rather than a global
    crc table (Jonathan)
  * driver: declare cmd as const u8 [static 2] in slf3s_send_cmd()
    (Jonathan)
  * driver: switch to fsleep() and sign_extend32() helpers (Jonathan)
  * driver: use named initialisers for slf3s_variants[] entries
    (Jonathan)
  * driver: unsigned int loop counters (Jonathan)
  * Kconfig: tab-indented bulleted list of supported parts (Jonathan)
  * ABI sysfs doc: _scale entry folded into the shared block,
    _raw block kept with its own KernelVersion (Guenter)
  * re-checked all scale factors against the SLF3S datasheets
    (Table 16 for -0600F, Table 15 for -1300F and -4000B)

Patches:

  1/3  iio: types: add IIO_VOLUMEFLOW channel type
  2/3  dt-bindings: iio: flow: add sensirion,slf3s binding
  3/3  iio: flow: add Sensirion SLF3S liquid flow sensor driver

Tested with an SLF3S-0600F on a TI AM64x platform; W=1 build clean,
checkpatch --strict clean, dt_binding_check clean.

Thanks,
Wadim

Wadim Mueller (3):
  iio: types: add IIO_VOLUMEFLOW channel type
  dt-bindings: iio: flow: add Sensirion SLF3S liquid flow sensor
  iio: flow: add Sensirion SLF3S liquid flow sensor driver

 Documentation/ABI/testing/sysfs-bus-iio       |  11 +
 .../bindings/iio/flow/sensirion,slf3s.yaml    |  68 ++++
 MAINTAINERS                                   |   8 +
 drivers/iio/Kconfig                           |   1 +
 drivers/iio/Makefile                          |   1 +
 drivers/iio/flow/Kconfig                      |  27 ++
 drivers/iio/flow/Makefile                     |   7 +
 drivers/iio/flow/slf3s.c                      | 345 ++++++++++++++++++
 drivers/iio/industrialio-core.c               |   1 +
 include/uapi/linux/iio/types.h                |   1 +
 tools/iio/iio_event_monitor.c                 |   2 +
 11 files changed, 472 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/flow/sensirion,slf3s.yaml
 create mode 100644 drivers/iio/flow/Kconfig
 create mode 100644 drivers/iio/flow/Makefile
 create mode 100644 drivers/iio/flow/slf3s.c

-- 
2.52.0

[PATCH v2 1/3] iio: types: add IIO_VOLUMEFLOW channel type

[Wadim Mueller]

Add a new IIO channel type for liquid volumetric flow sensors.  The
unit exposed via the standard _scale attribute is litres per second
(l/s), so drivers reporting smaller native units (e.g. ml/min) only
need to set a fractional scale.

Update iio-core's name table, the iio_event_monitor whitelist and
the sysfs-bus-iio ABI document to match.  The new _scale attribute is
folded into the existing shared _scale block; only the per-type _raw
needs a fresh entry.

Signed-off-by: Wadim Mueller <wafgo01@gmail.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Jean Delvare <jdelvare@suse.com>
Cc: Andreas Klinger <ak@it-klinger.de>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: linux-hwmon@vger.kernel.org
Cc: Maxwell Doose <m32285159@gmail.com>
---
 Documentation/ABI/testing/sysfs-bus-iio | 11 +++++++++++
 drivers/iio/industrialio-core.c         |  1 +
 include/uapi/linux/iio/types.h          |  1 +
 tools/iio/iio_event_monitor.c           |  2 ++
 4 files changed, 15 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio
index 5f87dcee7..2188557cb 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -507,6 +507,8 @@ What:		/sys/bus/iio/devices/iio:deviceX/in_intensity_red_scale
 What:		/sys/bus/iio/devices/iio:deviceX/in_intensity_green_scale
 What:		/sys/bus/iio/devices/iio:deviceX/in_intensity_blue_scale
 What:		/sys/bus/iio/devices/iio:deviceX/in_concentration_co2_scale
+What:		/sys/bus/iio/devices/iio:deviceX/in_volumeflow_scale
+What:		/sys/bus/iio/devices/iio:deviceX/in_volumeflowY_scale
 KernelVersion:	2.6.35
 Contact:	linux-iio@vger.kernel.org
 Description:
@@ -2458,3 +2460,12 @@ Description:
 		seconds, expressed as:
 
 		- a range specified as "[min step max]"
+
+What:		/sys/bus/iio/devices/iio:deviceX/in_volumeflow_raw
+What:		/sys/bus/iio/devices/iio:deviceX/in_volumeflowY_raw
+KernelVersion:	6.19
+Contact:	linux-iio@vger.kernel.org
+Description:
+		Raw (unscaled) volumetric flow rate reading from the channel.
+		To convert to standard units (litres per second) apply the
+		channel's _scale (and _offset, when present).
diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index 22eefd048..aa34fcd8e 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -98,6 +98,7 @@ static const char * const iio_chan_type_name_spec[] = {
 	[IIO_CHROMATICITY] = "chromaticity",
 	[IIO_ATTENTION] = "attention",
 	[IIO_ALTCURRENT] = "altcurrent",
+	[IIO_VOLUMEFLOW] = "volumeflow",
 };
 
 static const char * const iio_modifier_names[] = {
diff --git a/include/uapi/linux/iio/types.h b/include/uapi/linux/iio/types.h
index 6d269b844..49480f321 100644
--- a/include/uapi/linux/iio/types.h
+++ b/include/uapi/linux/iio/types.h
@@ -53,6 +53,7 @@ enum iio_chan_type {
 	IIO_CHROMATICITY,
 	IIO_ATTENTION,
 	IIO_ALTCURRENT,
+	IIO_VOLUMEFLOW,
 };
 
 enum iio_modifier {
diff --git a/tools/iio/iio_event_monitor.c b/tools/iio/iio_event_monitor.c
index 03ca33869..078004750 100644
--- a/tools/iio/iio_event_monitor.c
+++ b/tools/iio/iio_event_monitor.c
@@ -65,6 +65,7 @@ static const char * const iio_chan_type_name_spec[] = {
 	[IIO_CHROMATICITY] = "chromaticity",
 	[IIO_ATTENTION] = "attention",
 	[IIO_ALTCURRENT] = "altcurrent",
+	[IIO_VOLUMEFLOW] = "volumeflow",
 };
 
 static const char * const iio_ev_type_text[] = {
@@ -193,6 +194,7 @@ static bool event_is_known(struct iio_event_data *event)
 	case IIO_CHROMATICITY:
 	case IIO_ATTENTION:
 	case IIO_ALTCURRENT:
+	case IIO_VOLUMEFLOW:
 		break;
 	default:
 		return false;
-- 
2.52.0

Re: [PATCH v2 1/3] iio: types: add IIO_VOLUMEFLOW channel type

[Jonathan Cameron]

On Wed, 27 May 2026 20:42:52 +0200
Wadim Mueller <wafgo01@gmail.com> wrote:

> Add a new IIO channel type for liquid volumetric flow sensors.  The
> unit exposed via the standard _scale attribute is litres per second
> (l/s), so drivers reporting smaller native units (e.g. ml/min) only
> need to set a fractional scale.

Hi Wadim

You (I think) raised a useful point in v1. Given the SI units thing should
we actually be doing m^3/sec? for this new type? That would be more
inline with existing units including distance.

There is a slight inconsistency for Ph which is log_10(ions per litre)

I'd like more opinions on this as I've made some less than idea decisions
on units in the past!

One other thing inline.


Jonathan


> 
> Update iio-core's name table, the iio_event_monitor whitelist and
> the sysfs-bus-iio ABI document to match.  The new _scale attribute is
> folded into the existing shared _scale block; only the per-type _raw
> needs a fresh entry.
> 
> Signed-off-by: Wadim Mueller <wafgo01@gmail.com>
> Cc: Guenter Roeck <linux@roeck-us.net>
> Cc: Jean Delvare <jdelvare@suse.com>
> Cc: Andreas Klinger <ak@it-klinger.de>
> Cc: Lars-Peter Clausen <lars@metafoo.de>
> Cc: linux-hwmon@vger.kernel.org
> Cc: Maxwell Doose <m32285159@gmail.com>
> ---
>  Documentation/ABI/testing/sysfs-bus-iio | 11 +++++++++++
>  drivers/iio/industrialio-core.c         |  1 +
>  include/uapi/linux/iio/types.h          |  1 +
>  tools/iio/iio_event_monitor.c           |  2 ++
>  4 files changed, 15 insertions(+)
> 
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio
> index 5f87dcee7..2188557cb 100644
> --- a/Documentation/ABI/testing/sysfs-bus-iio
> +++ b/Documentation/ABI/testing/sysfs-bus-iio
> @@ -507,6 +507,8 @@ What:		/sys/bus/iio/devices/iio:deviceX/in_intensity_red_scale
>  What:		/sys/bus/iio/devices/iio:deviceX/in_intensity_green_scale
>  What:		/sys/bus/iio/devices/iio:deviceX/in_intensity_blue_scale
>  What:		/sys/bus/iio/devices/iio:deviceX/in_concentration_co2_scale
> +What:		/sys/bus/iio/devices/iio:deviceX/in_volumeflow_scale
> +What:		/sys/bus/iio/devices/iio:deviceX/in_volumeflowY_scale

I'm going to assume this driver only uses one of these.  Generally we only introduce
stuff on first use, so drop the one you aren't using.

>  KernelVersion:	2.6.35
>  Contact:	linux-iio@vger.kernel.org
>  Description:
> @@ -2458,3 +2460,12 @@ Description:
>  		seconds, expressed as:
>  
>  		- a range specified as "[min step max]"
> +
> +What:		/sys/bus/iio/devices/iio:deviceX/in_volumeflow_raw
> +What:		/sys/bus/iio/devices/iio:deviceX/in_volumeflowY_raw
> +KernelVersion:	6.19
> +Contact:	linux-iio@vger.kernel.org
> +Description:
> +		Raw (unscaled) volumetric flow rate reading from the channel.
> +		To convert to standard units (litres per second) apply the
> +		channel's _scale (and _offset, when present).
> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> index 22eefd048..aa34fcd8e 100644
> --- a/drivers/iio/industrialio-core.c
> +++ b/drivers/iio/industrialio-core.c
> @@ -98,6 +98,7 @@ static const char * const iio_chan_type_name_spec[] = {
>  	[IIO_CHROMATICITY] = "chromaticity",
>  	[IIO_ATTENTION] = "attention",
>  	[IIO_ALTCURRENT] = "altcurrent",
> +	[IIO_VOLUMEFLOW] = "volumeflow",
>  };
>  
>  static const char * const iio_modifier_names[] = {
> diff --git a/include/uapi/linux/iio/types.h b/include/uapi/linux/iio/types.h
> index 6d269b844..49480f321 100644
> --- a/include/uapi/linux/iio/types.h
> +++ b/include/uapi/linux/iio/types.h
> @@ -53,6 +53,7 @@ enum iio_chan_type {
>  	IIO_CHROMATICITY,
>  	IIO_ATTENTION,
>  	IIO_ALTCURRENT,
> +	IIO_VOLUMEFLOW,
>  };
>  
>  enum iio_modifier {
> diff --git a/tools/iio/iio_event_monitor.c b/tools/iio/iio_event_monitor.c
> index 03ca33869..078004750 100644
> --- a/tools/iio/iio_event_monitor.c
> +++ b/tools/iio/iio_event_monitor.c
> @@ -65,6 +65,7 @@ static const char * const iio_chan_type_name_spec[] = {
>  	[IIO_CHROMATICITY] = "chromaticity",
>  	[IIO_ATTENTION] = "attention",
>  	[IIO_ALTCURRENT] = "altcurrent",
> +	[IIO_VOLUMEFLOW] = "volumeflow",
>  };
>  
>  static const char * const iio_ev_type_text[] = {
> @@ -193,6 +194,7 @@ static bool event_is_known(struct iio_event_data *event)
>  	case IIO_CHROMATICITY:
>  	case IIO_ATTENTION:
>  	case IIO_ALTCURRENT:
> +	case IIO_VOLUMEFLOW:
>  		break;
>  	default:
>  		return false;

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

[Wadim Mueller]

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.

Variants share the same register map and differ only in the flow
scale factor and calibrated measurement range, both of which are
auto-detected at probe time via the product-information register.
Per-variant compatible strings are accepted for documentation and
future-proofing; new variants will fall back on the generic
"sensirion,slf3s" compatible without a driver update.

The data-ready interrupt is optional; without it the driver falls
back to polled I2C reads.

A sensirion,medium property is added so that the driver can start
the sensor with either the H2O or the IPA factory calibration
(default H2O).

Signed-off-by: Wadim Mueller <wafgo01@gmail.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Jean Delvare <jdelvare@suse.com>
Cc: Andreas Klinger <ak@it-klinger.de>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: linux-hwmon@vger.kernel.org
Cc: Maxwell Doose <m32285159@gmail.com>
---
 .../bindings/iio/flow/sensirion,slf3s.yaml    | 68 +++++++++++++++++++
 MAINTAINERS                                   |  8 +++
 2 files changed, 76 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/flow/sensirion,slf3s.yaml

diff --git a/Documentation/devicetree/bindings/iio/flow/sensirion,slf3s.yaml b/Documentation/devicetree/bindings/iio/flow/sensirion,slf3s.yaml
new file mode 100644
index 000000000..f58cf199a
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/flow/sensirion,slf3s.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/flow/sensirion,slf3s.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sensirion SLF3S liquid flow sensor
+
+maintainers:
+  - Wadim Mueller <wafgo01@gmail.com>
+
+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.
+
+properties:
+  compatible:
+    oneOf:
+      - items:
+          - enum:
+              - sensirion,slf3s-0600f
+              - sensirion,slf3s-1300f
+              - sensirion,slf3s-4000b
+          - const: sensirion,slf3s
+      - const: sensirion,slf3s
+
+  reg:
+    maxItems: 1
+
+  interrupts:
+    maxItems: 1
+    description:
+      Optional data-ready interrupt line.  If omitted the driver falls
+      back to polled I2C reads.
+
+  vdd-supply: true
+
+  sensirion,medium:
+    $ref: /schemas/types.yaml#/definitions/string
+    enum: [ water, ipa ]
+    default: water
+    description:
+      Calibration medium the sensor is configured for at probe time.
+      SLF3S sensors are factory-calibrated for both water and
+      isopropyl alcohol (IPA); this property selects which calibration
+      to activate.  Defaults to water when omitted.
+
+required:
+  - compatible
+  - reg
+  - vdd-supply
+
+additionalProperties: false
+
+examples:
+  - |
+    i2c {
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        flow-sensor@8 {
+            compatible = "sensirion,slf3s-0600f", "sensirion,slf3s";
+            reg = <0x08>;
+            vdd-supply = <&reg_3v3>;
+        };
+    };
diff --git a/MAINTAINERS b/MAINTAINERS
index 06a8c7457..096ef2fe7 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/
+
 SENSIRION SPS30 AIR POLLUTION SENSOR DRIVER
 M:	Tomasz Duszynski <tduszyns@gmail.com>
 S:	Maintained
-- 
2.52.0

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

[Krzysztof Kozlowski]

On Wed, May 27, 2026 at 08:42:53PM +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.
> 
> Variants share the same register map and differ only in the flow
> scale factor and calibrated measurement range, both of which are
> auto-detected at probe time via the product-information register.
> Per-variant compatible strings are accepted for documentation and
> future-proofing; new variants will fall back on the generic
> "sensirion,slf3s" compatible without a driver update.
> 
> The data-ready interrupt is optional; without it the driver falls
> back to polled I2C reads.
> 
> A sensirion,medium property is added so that the driver can start
> the sensor with either the H2O or the IPA factory calibration
> (default H2O).

Do not attach (thread) your patchsets to some other threads (unrelated
or older versions). This buries them deep in the mailbox and might
interfere with applying entire sets. See also:
https://elixir.bootlin.com/linux/v6.16-rc2/source/Documentation/process/submitting-patches.rst#L830

> 
> Signed-off-by: Wadim Mueller <wafgo01@gmail.com>
> Cc: Guenter Roeck <linux@roeck-us.net>
> Cc: Jean Delvare <jdelvare@suse.com>
> Cc: Andreas Klinger <ak@it-klinger.de>
> Cc: Lars-Peter Clausen <lars@metafoo.de>
> Cc: linux-hwmon@vger.kernel.org

No need for cc of maintainers here which are output by
get_maintainers.pl. get_maintainers.pl provides that basically.

Anyway, your SoB must be the last.

> Cc: Maxwell Doose <m32285159@gmail.com>

...

> +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.
> +
> +properties:
> +  compatible:
> +    oneOf:
> +      - items:
> +          - enum:
> +              - sensirion,slf3s-0600f
> +              - sensirion,slf3s-1300f
> +              - sensirion,slf3s-4000b
> +          - const: sensirion,slf3s
> +      - const: sensirion,slf3s

That's confusing - why do you have generic compatible allowed to be
alone?

> +
> +  reg:
> +    maxItems: 1
> +
> +  interrupts:
> +    maxItems: 1
> +    description:
> +      Optional data-ready interrupt line.  If omitted the driver falls
> +      back to polled I2C reads.
> +
> +  vdd-supply: true
> +
> +  sensirion,medium:
> +    $ref: /schemas/types.yaml#/definitions/string
> +    enum: [ water, ipa ]
> +    default: water
> +    description:
> +      Calibration medium the sensor is configured for at probe time.
> +      SLF3S sensors are factory-calibrated for both water and
> +      isopropyl alcohol (IPA); this property selects which calibration
> +      to activate.  Defaults to water when omitted.

Sounds like you configure driver probe behavior. Why this is board-level
static configuration (DT)?

> +
> +required:
> +  - compatible
> +  - reg
> +  - vdd-supply
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    i2c {
> +        #address-cells = <1>;
> +        #size-cells = <0>;
> +
> +        flow-sensor@8 {
> +            compatible = "sensirion,slf3s-0600f", "sensirion,slf3s";
> +            reg = <0x08>;
> +            vdd-supply = <&reg_3v3>;

Please make example complete - add all properties.

> +        };
> +    };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 06a8c7457..096ef2fe7 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/

Drop, you don't maintain that directory here.

> +
>  SENSIRION SPS30 AIR POLLUTION SENSOR DRIVER
>  M:	Tomasz Duszynski <tduszyns@gmail.com>
>  S:	Maintained
> -- 
> 2.52.0
> 

[PATCH v2 3/3] iio: flow: add Sensirion SLF3S liquid flow sensor driver

[Wadim Mueller]

Add a driver for the Sensirion SLF3S family of digital liquid-flow
sensors (SLF3S-0600F, SLF3S-1300F and SLF3S-4000B).  The sensors
communicate over I2C and return a 16-bit signed flow value, a 16-bit
signed temperature reading and a status word - each protected by a
CRC-8 byte - in every measurement frame.

The driver exposes:

  in_volumeflow_raw     - signed raw counts
  in_volumeflow_scale   - litres per second per LSB (per variant)
  in_temp_raw           - signed raw counts
  in_temp_scale         - millidegrees Celsius per LSB

The variant is auto-detected from the product-info word read at
probe time.  All three SLF3S devices are factory-calibrated for both
water and isopropyl alcohol; the calibration medium is selected via
the sensirion,medium device property and defaults to water.

Scale factors are taken from the respective datasheets (Table 16
for SLF3S-0600F, Table 15 for SLF3S-1300F and SLF3S-4000B):

  SLF3S-0600F:  10 (ul/min)^-1  -> 1/600 000 000 (l/s)/LSB
  SLF3S-1300F: 500 (ml/min)^-1  -> 1/30 000 000  (l/s)/LSB
  SLF3S-4000B:  32 (ml/min)^-1  -> 1/1 920 000   (l/s)/LSB

Signed-off-by: Wadim Mueller <wafgo01@gmail.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Jean Delvare <jdelvare@suse.com>
Cc: Andreas Klinger <ak@it-klinger.de>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: linux-hwmon@vger.kernel.org
Cc: Maxwell Doose <m32285159@gmail.com>
---
 drivers/iio/Kconfig       |   1 +
 drivers/iio/Makefile      |   1 +
 drivers/iio/flow/Kconfig  |  27 +++
 drivers/iio/flow/Makefile |   7 +
 drivers/iio/flow/slf3s.c  | 345 ++++++++++++++++++++++++++++++++++++++
 5 files changed, 381 insertions(+)
 create mode 100644 drivers/iio/flow/Kconfig
 create mode 100644 drivers/iio/flow/Makefile
 create mode 100644 drivers/iio/flow/slf3s.c

diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
index 661127aed..652557a5b 100644
--- a/drivers/iio/Kconfig
+++ b/drivers/iio/Kconfig
@@ -92,6 +92,7 @@ source "drivers/iio/common/Kconfig"
 source "drivers/iio/dac/Kconfig"
 source "drivers/iio/dummy/Kconfig"
 source "drivers/iio/filter/Kconfig"
+source "drivers/iio/flow/Kconfig"
 source "drivers/iio/frequency/Kconfig"
 source "drivers/iio/gyro/Kconfig"
 source "drivers/iio/health/Kconfig"
diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
index cb80ef837..f03a4100c 100644
--- a/drivers/iio/Makefile
+++ b/drivers/iio/Makefile
@@ -29,6 +29,7 @@ obj-y += dac/
 obj-y += dummy/
 obj-y += gyro/
 obj-y += filter/
+obj-y += flow/
 obj-y += frequency/
 obj-y += health/
 obj-y += humidity/
diff --git a/drivers/iio/flow/Kconfig b/drivers/iio/flow/Kconfig
new file mode 100644
index 000000000..1eee131ea
--- /dev/null
+++ b/drivers/iio/flow/Kconfig
@@ -0,0 +1,27 @@
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# Liquid / gas flow sensor drivers
+#
+# When adding new entries keep the list in alphabetical order
+
+menu "Flow sensors"
+
+config SENSIRION_SLF3S
+	tristate "Sensirion SLF3S liquid flow sensor"
+	depends on I2C
+	select CRC8
+	help
+	  Say yes here to build support for the Sensirion SLF3S family
+	  of digital liquid-flow sensors:
+
+	    - SLF3S-0600F
+	    - SLF3S-1300F
+	    - SLF3S-4000B
+
+	  The driver reports the volumetric flow rate and the embedded
+	  temperature reading via the standard IIO interface.
+
+	  To compile this driver as a module, choose M here: the module
+	  will be called slf3s.
+
+endmenu
diff --git a/drivers/iio/flow/Makefile b/drivers/iio/flow/Makefile
new file mode 100644
index 000000000..3cf4ab95c
--- /dev/null
+++ b/drivers/iio/flow/Makefile
@@ -0,0 +1,7 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# Makefile for industrial I/O flow sensor drivers
+#
+
+# When adding new entries keep the list in alphabetical order
+obj-$(CONFIG_SENSIRION_SLF3S) += slf3s.o
diff --git a/drivers/iio/flow/slf3s.c b/drivers/iio/flow/slf3s.c
new file mode 100644
index 000000000..f971a2dc2
--- /dev/null
+++ b/drivers/iio/flow/slf3s.c
@@ -0,0 +1,345 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Sensirion SLF3S liquid flow sensor driver.
+ *
+ * Supports the SLF3S-0600F, SLF3S-1300F and SLF3S-4000B liquid-flow
+ * sensors over I2C.  Each measurement frame returns a 16-bit signed
+ * flow value, a 16-bit signed temperature value and a status word,
+ * each protected by a CRC-8 byte.
+ *
+ * Datasheet: https://sensirion.com/products/catalog/SLF3S-0600F/
+ *
+ * Copyright (C) 2026 CMBlu Energy GmbH
+ * Author: Wadim Mueller <wafgo01@gmail.com>
+ */
+
+#include <linux/bitops.h>
+#include <linux/crc8.h>
+#include <linux/delay.h>
+#include <linux/i2c.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/property.h>
+#include <linux/regulator/consumer.h>
+#include <linux/unaligned.h>
+
+#include <linux/iio/iio.h>
+
+#define SLF3S_CRC8_POLY			0x31
+#define SLF3S_CRC8_INIT			0xff
+
+#define SLF3S_PRODUCT_ID_LEN		18
+#define SLF3S_PRODUCT_FAMILY_BYTE	1
+#define SLF3S_PRODUCT_SUBTYPE_BYTE	3
+#define SLF3S_PRODUCT_FAMILY_ID		0x03
+
+#define SLF3S_MEAS_LEN			9
+#define SLF3S_MEAS_START_DELAY_US	12000
+
+/*
+ * Temperature LSB equals 1/200 degC.  IIO_TEMP uses milli-degrees,
+ * therefore the scale exposed to userspace is 1000 / 200 = 5.
+ */
+#define SLF3S_TEMP_SCALE_MILLIC		5
+
+static const u8 slf3s_cmd_prep_pid[]	= { 0x36, 0x7c };
+static const u8 slf3s_cmd_read_pid[]	= { 0xe1, 0x02 };
+static const u8 slf3s_cmd_start_water[]	= { 0x36, 0x08 };
+static const u8 slf3s_cmd_start_ipa[]	= { 0x36, 0x15 };
+static const u8 slf3s_cmd_stop_meas[]	= { 0x3f, 0xf9 };
+
+/**
+ * struct slf3s_variant - per-variant calibration constants
+ * @sub_type:	product-info sub-type byte returned by the sensor
+ * @name:	name reported via @iio_dev.name
+ * @scale_num:	flow scale numerator (l/s per LSB)
+ * @scale_den:	flow scale denominator (l/s per LSB)
+ */
+struct slf3s_variant {
+	u8 sub_type;
+	const char *name;
+	int scale_num;
+	int scale_den;
+};
+
+static const struct slf3s_variant slf3s_variants[] = {
+	[0] = {
+		.sub_type	= 0x03,
+		.name		= "slf3s-0600f",
+		.scale_num	= 1,
+		.scale_den	= 600000000,
+	},
+	[1] = {
+		.sub_type	= 0x02,
+		.name		= "slf3s-1300f",
+		.scale_num	= 1,
+		.scale_den	= 30000000,
+	},
+	[2] = {
+		.sub_type	= 0x05,
+		.name		= "slf3s-4000b",
+		.scale_num	= 1,
+		.scale_den	= 1920000,
+	},
+};
+
+/**
+ * struct slf3s_data - per-device state
+ * @client:	I2C client this instance is bound to
+ * @variant:	pointer into @slf3s_variants for the detected device
+ * @crc_table:	pre-computed CRC-8 lookup table for SLF3S_CRC8_POLY
+ */
+struct slf3s_data {
+	struct i2c_client *client;
+	const struct slf3s_variant *variant;
+	u8 crc_table[CRC8_TABLE_SIZE];
+};
+
+static bool slf3s_crc_valid(const struct slf3s_data *sf, const u8 *block)
+{
+	return crc8(sf->crc_table, block, 2, SLF3S_CRC8_INIT) == block[2];
+}
+
+static int slf3s_send_cmd(struct i2c_client *client, const u8 cmd[static 2])
+{
+	int ret = i2c_master_send(client, cmd, 2);
+
+	if (ret == 2)
+		return 0;
+	return ret < 0 ? ret : -EIO;
+}
+
+/*
+ * Read the product-info block and update @sf->variant.  The kernel
+ * trusts the DT compatible (or i2c id_table .data) above all else; the
+ * sub-type byte is a sanity hint.  This means:
+ *
+ *   - bus / CRC failures are real errors and must fail probe;
+ *   - if the caller already picked a variant (specific compatible), the
+ *     PID is logged for diagnostics but mismatches do not fail probe;
+ *   - if the caller has no variant (generic "sensirion,slf3s" fallback),
+ *     the sub-type byte is used to pick one; unknown sub-type fails.
+ */
+static int slf3s_detect_variant(struct slf3s_data *sf)
+{
+	struct i2c_client *client = sf->client;
+	u8 buf[SLF3S_PRODUCT_ID_LEN];
+	int ret;
+
+	ret = slf3s_send_cmd(client, slf3s_cmd_prep_pid);
+	if (ret)
+		return ret;
+
+	ret = slf3s_send_cmd(client, slf3s_cmd_read_pid);
+	if (ret)
+		return ret;
+
+	ret = i2c_master_recv(client, buf, sizeof(buf));
+	if (ret < 0)
+		return ret;
+	if (ret != sizeof(buf))
+		return -EIO;
+
+	for (unsigned int i = 0; i < SLF3S_PRODUCT_ID_LEN; i += 3) {
+		if (!slf3s_crc_valid(sf, &buf[i]))
+			return -EIO;
+	}
+
+	if (buf[SLF3S_PRODUCT_FAMILY_BYTE] != SLF3S_PRODUCT_FAMILY_ID)
+		dev_dbg(&client->dev,
+			"unexpected family byte 0x%02x (expected 0x%02x)\n",
+			buf[SLF3S_PRODUCT_FAMILY_BYTE],
+			SLF3S_PRODUCT_FAMILY_ID);
+
+	for (unsigned int i = 0; i < ARRAY_SIZE(slf3s_variants); i++) {
+		if (buf[SLF3S_PRODUCT_SUBTYPE_BYTE] !=
+		    slf3s_variants[i].sub_type)
+			continue;
+
+		if (sf->variant && sf->variant != &slf3s_variants[i])
+			dev_dbg(&client->dev,
+				"DT compatible says %s but sub-type 0x%02x suggests %s\n",
+				sf->variant->name,
+				buf[SLF3S_PRODUCT_SUBTYPE_BYTE],
+				slf3s_variants[i].name);
+		else if (!sf->variant)
+			sf->variant = &slf3s_variants[i];
+		return 0;
+	}
+
+	if (sf->variant) {
+		dev_dbg(&client->dev,
+			"unknown SLF3S sub-type 0x%02x, trusting DT compatible %s\n",
+			buf[SLF3S_PRODUCT_SUBTYPE_BYTE], sf->variant->name);
+		return 0;
+	}
+
+	dev_dbg(&client->dev, "unknown SLF3S sub-type 0x%02x\n",
+		buf[SLF3S_PRODUCT_SUBTYPE_BYTE]);
+	return -ENODEV;
+}
+
+static int slf3s_read_sample(struct slf3s_data *sf, int *flow, int *temp)
+{
+	u8 buf[SLF3S_MEAS_LEN];
+	int ret;
+
+	ret = i2c_master_recv(sf->client, buf, sizeof(buf));
+	if (ret < 0)
+		return ret;
+	if (ret != sizeof(buf))
+		return -EIO;
+
+	for (unsigned int i = 0; i < SLF3S_MEAS_LEN; i += 3) {
+		if (!slf3s_crc_valid(sf, &buf[i]))
+			return -EIO;
+	}
+
+	*flow = sign_extend32(get_unaligned_be16(&buf[0]), 15);
+	*temp = sign_extend32(get_unaligned_be16(&buf[3]), 15);
+	return 0;
+}
+
+static const struct iio_chan_spec slf3s_channels[] = {
+	{
+		.type = IIO_VOLUMEFLOW,
+		.info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
+				      BIT(IIO_CHAN_INFO_SCALE),
+	},
+	{
+		.type = IIO_TEMP,
+		.info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
+				      BIT(IIO_CHAN_INFO_SCALE),
+	},
+};
+
+static int slf3s_read_raw(struct iio_dev *indio_dev,
+			  struct iio_chan_spec const *chan, int *val,
+			  int *val2, long mask)
+{
+	struct slf3s_data *sf = iio_priv(indio_dev);
+	int flow, temp, ret;
+
+	switch (mask) {
+	case IIO_CHAN_INFO_RAW:
+		if (!iio_device_claim_direct(indio_dev))
+			return -EBUSY;
+
+		ret = slf3s_read_sample(sf, &flow, &temp);
+		iio_device_release_direct(indio_dev);
+		if (ret)
+			return ret;
+
+		*val = (chan->type == IIO_VOLUMEFLOW) ? flow : temp;
+		return IIO_VAL_INT;
+	case IIO_CHAN_INFO_SCALE:
+		if (chan->type == IIO_VOLUMEFLOW) {
+			*val = sf->variant->scale_num;
+			*val2 = sf->variant->scale_den;
+			return IIO_VAL_FRACTIONAL;
+		}
+		*val = SLF3S_TEMP_SCALE_MILLIC;
+		return IIO_VAL_INT;
+	default:
+		return -EINVAL;
+	}
+}
+
+static const struct iio_info slf3s_info = {
+	.read_raw = slf3s_read_raw,
+};
+
+static void slf3s_stop_meas(void *data)
+{
+	struct slf3s_data *sf = data;
+
+	slf3s_send_cmd(sf->client, slf3s_cmd_stop_meas);
+}
+
+static int slf3s_probe(struct i2c_client *client)
+{
+	struct device *dev = &client->dev;
+	struct iio_dev *indio_dev;
+	struct slf3s_data *sf;
+	const u8 *start_cmd = slf3s_cmd_start_water;
+	const char *medium;
+	int ret;
+
+	indio_dev = devm_iio_device_alloc(dev, sizeof(*sf));
+	if (!indio_dev)
+		return -ENOMEM;
+
+	sf = iio_priv(indio_dev);
+	sf->client = client;
+	sf->variant = i2c_get_match_data(client);
+	crc8_populate_msb(sf->crc_table, SLF3S_CRC8_POLY);
+
+	ret = devm_regulator_get_enable(dev, "vdd");
+	if (ret)
+		return dev_err_probe(dev, ret, "failed to enable vdd supply\n");
+
+	ret = slf3s_detect_variant(sf);
+	if (ret)
+		return dev_err_probe(dev, ret, "product info read failed\n");
+
+	ret = device_property_read_string(dev, "sensirion,medium", &medium);
+	if (!ret) {
+		if (!strcmp(medium, "ipa"))
+			start_cmd = slf3s_cmd_start_ipa;
+		else if (strcmp(medium, "water"))
+			return dev_err_probe(dev, -EINVAL,
+					     "unknown sensirion,medium '%s'\n",
+					     medium);
+	}
+
+	ret = slf3s_send_cmd(client, start_cmd);
+	if (ret)
+		return dev_err_probe(dev, ret,
+				     "failed to start measurement\n");
+
+	fsleep(SLF3S_MEAS_START_DELAY_US);
+
+	ret = devm_add_action_or_reset(dev, slf3s_stop_meas, sf);
+	if (ret)
+		return ret;
+
+	indio_dev->name = sf->variant->name;
+	indio_dev->channels = slf3s_channels;
+	indio_dev->num_channels = ARRAY_SIZE(slf3s_channels);
+	indio_dev->info = &slf3s_info;
+	indio_dev->modes = INDIO_DIRECT_MODE;
+
+	return devm_iio_device_register(dev, indio_dev);
+}
+
+static const struct i2c_device_id slf3s_id[] = {
+	{ .name = "slf3s-0600f", .driver_data = (kernel_ulong_t)&slf3s_variants[0] },
+	{ .name = "slf3s-1300f", .driver_data = (kernel_ulong_t)&slf3s_variants[1] },
+	{ .name = "slf3s-4000b", .driver_data = (kernel_ulong_t)&slf3s_variants[2] },
+	{ .name = "slf3s" },
+	{ }
+};
+MODULE_DEVICE_TABLE(i2c, slf3s_id);
+
+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] },
+	{ .compatible = "sensirion,slf3s" },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, slf3s_of_match);
+
+static struct i2c_driver slf3s_driver = {
+	.driver = {
+		.name		= "slf3s",
+		.of_match_table	= slf3s_of_match,
+	},
+	.probe		= slf3s_probe,
+	.id_table	= slf3s_id,
+};
+module_i2c_driver(slf3s_driver);
+
+MODULE_AUTHOR("Wadim Mueller <wafgo01@gmail.com>");
+MODULE_DESCRIPTION("Sensirion SLF3S liquid flow sensor driver");
+MODULE_LICENSE("GPL");
-- 
2.52.0

Re: [PATCH v2 3/3] iio: flow: add Sensirion SLF3S liquid flow sensor driver

[Jonathan Cameron]

On Wed, 27 May 2026 20:42:54 +0200
Wadim Mueller <wafgo01@gmail.com> wrote:

> Add a driver for the Sensirion SLF3S family of digital liquid-flow
> sensors (SLF3S-0600F, SLF3S-1300F and SLF3S-4000B).  The sensors
> communicate over I2C and return a 16-bit signed flow value, a 16-bit
> signed temperature reading and a status word - each protected by a
> CRC-8 byte - in every measurement frame.
> 
> The driver exposes:
> 
>   in_volumeflow_raw     - signed raw counts
>   in_volumeflow_scale   - litres per second per LSB (per variant)
>   in_temp_raw           - signed raw counts
>   in_temp_scale         - millidegrees Celsius per LSB
> 
> The variant is auto-detected from the product-info word read at
> probe time.  All three SLF3S devices are factory-calibrated for both
> water and isopropyl alcohol; the calibration medium is selected via
> the sensirion,medium device property and defaults to water.
> 
> Scale factors are taken from the respective datasheets (Table 16
> for SLF3S-0600F, Table 15 for SLF3S-1300F and SLF3S-4000B):
> 
>   SLF3S-0600F:  10 (ul/min)^-1  -> 1/600 000 000 (l/s)/LSB
>   SLF3S-1300F: 500 (ml/min)^-1  -> 1/30 000 000  (l/s)/LSB
>   SLF3S-4000B:  32 (ml/min)^-1  -> 1/1 920 000   (l/s)/LSB
> 
> Signed-off-by: Wadim Mueller <wafgo01@gmail.com>
> Cc: Guenter Roeck <linux@roeck-us.net>
> Cc: Jean Delvare <jdelvare@suse.com>
> Cc: Andreas Klinger <ak@it-klinger.de>
> Cc: Lars-Peter Clausen <lars@metafoo.de>
> Cc: linux-hwmon@vger.kernel.org
> Cc: Maxwell Doose <m32285159@gmail.com>

A few fairly minor things inline. Also check out sashiko's review
https://sashiko.dev/#/patchset/20260527184257.141635-1-wafgo01%40gmail.com
(Note the DMA buffers stuff is wrong for I2C so ignore that)

> diff --git a/drivers/iio/flow/slf3s.c b/drivers/iio/flow/slf3s.c
> new file mode 100644
> index 000000000..f971a2dc2
> --- /dev/null
> +++ b/drivers/iio/flow/slf3s.c
> @@ -0,0 +1,345 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Sensirion SLF3S liquid flow sensor driver.
> + *
> + * Supports the SLF3S-0600F, SLF3S-1300F and SLF3S-4000B liquid-flow
> + * sensors over I2C.  Each measurement frame returns a 16-bit signed
> + * flow value, a 16-bit signed temperature value and a status word,
> + * each protected by a CRC-8 byte.
> + *
> + * Datasheet: https://sensirion.com/products/catalog/SLF3S-0600F/
> + *
> + * Copyright (C) 2026 CMBlu Energy GmbH
> + * Author: Wadim Mueller <wafgo01@gmail.com>
> + */
> +
> +#include <linux/bitops.h>
> +#include <linux/crc8.h>
> +#include <linux/delay.h>

Check these.  I'd expect dev_printk.h for instance.
Follow IWYU (approximately) for includes.

> +#include <linux/i2c.h>
> +#include <linux/mod_devicetable.h>
> +#include <linux/module.h>
> +#include <linux/property.h>
> +#include <linux/regulator/consumer.h>
> +#include <linux/unaligned.h>
> +
> +#include <linux/iio/iio.h>
> +
> +#define SLF3S_CRC8_POLY			0x31
> +#define SLF3S_CRC8_INIT			0xff
> +
> +#define SLF3S_PRODUCT_ID_LEN		18
> +#define SLF3S_PRODUCT_FAMILY_BYTE	1
> +#define SLF3S_PRODUCT_SUBTYPE_BYTE	3
> +#define SLF3S_PRODUCT_FAMILY_ID		0x03
> +
> +#define SLF3S_MEAS_LEN			9

I don't think this constant being a define is that useful. I'd push
the value down to where you set how big the buffer is then use ARRAY_SIZE()
for the loop

> +#define SLF3S_MEAS_START_DELAY_US	12000
> +
> +/*
> + * Temperature LSB equals 1/200 degC.  IIO_TEMP uses milli-degrees,
> + * therefore the scale exposed to userspace is 1000 / 200 = 5.
> + */
> +#define SLF3S_TEMP_SCALE_MILLIC		5

I'd put this value inline with the comment. It's only used in one
place and that is where people will look for information on scale.


> +
> +static const struct slf3s_variant slf3s_variants[] = {
> +	[0] = {
> +		.sub_type	= 0x03,
> +		.name		= "slf3s-0600f",
> +		.scale_num	= 1,
> +		.scale_den	= 600000000,

Probably more readable with 600 * MICRO 

> +	},
> +	[1] = {
> +		.sub_type	= 0x02,
> +		.name		= "slf3s-1300f",
> +		.scale_num	= 1,
> +		.scale_den	= 30000000,

30 * MICRO

> +	},
> +	[2] = {
> +		.sub_type	= 0x05,
> +		.name		= "slf3s-4000b",
> +		.scale_num	= 1,
> +		.scale_den	= 1920000,

1920 * MILLI or leave this one as is. 4 zeros are easy to count ;)

> +	},
> +};
> +
> +/**
> + * struct slf3s_data - per-device state
> + * @client:	I2C client this instance is bound to
> + * @variant:	pointer into @slf3s_variants for the detected device
> + * @crc_table:	pre-computed CRC-8 lookup table for SLF3S_CRC8_POLY
> + */
> +struct slf3s_data {
> +	struct i2c_client *client;
> +	const struct slf3s_variant *variant;
> +	u8 crc_table[CRC8_TABLE_SIZE];
> +};
> +
> +static bool slf3s_crc_valid(const struct slf3s_data *sf, const u8 *block)

I'd be consistent and have const u8 block[at_least 3]
the make it clear how big that is expected to be.

> +{
> +	return crc8(sf->crc_table, block, 2, SLF3S_CRC8_INIT) == block[2];
> +}
> +
> +static int slf3s_send_cmd(struct i2c_client *client, const u8 cmd[static 2])

Use at_least, not static for kernel code as it makes it much more obvious what
is going on.

Note the sashiko report on this memory potentially being used for DMA is wrong.
The i2c subsystem only does that if you opt in.

> +{
> +	int ret = i2c_master_send(client, cmd, 2);
> +
> +	if (ret == 2)
> +		return 0;
> +	return ret < 0 ? ret : -EIO;
> +}
> +
> +/*
> + * Read the product-info block and update @sf->variant.  The kernel

wrap at 80 chars. This is a bit short in places.

> + * trusts the DT compatible (or i2c id_table .data) above all else; the
> + * sub-type byte is a sanity hint.  This means:
> + *
> + *   - bus / CRC failures are real errors and must fail probe;
> + *   - if the caller already picked a variant (specific compatible), the
> + *     PID is logged for diagnostics but mismatches do not fail probe;
> + *   - if the caller has no variant (generic "sensirion,slf3s" fallback),
> + *     the sub-type byte is used to pick one; unknown sub-type fails.
This is interesting approach, but lets discuss it in the dt-binding  thread.

> + */
> +static int slf3s_detect_variant(struct slf3s_data *sf)
> +{
> +	struct i2c_client *client = sf->client;
> +	u8 buf[SLF3S_PRODUCT_ID_LEN];
> +	int ret;
> +
> +	ret = slf3s_send_cmd(client, slf3s_cmd_prep_pid);
> +	if (ret)
> +		return ret;
> +
> +	ret = slf3s_send_cmd(client, slf3s_cmd_read_pid);
> +	if (ret)
> +		return ret;
> +
> +	ret = i2c_master_recv(client, buf, sizeof(buf));
> +	if (ret < 0)
> +		return ret;
> +	if (ret != sizeof(buf))
> +		return -EIO;
> +
> +	for (unsigned int i = 0; i < SLF3S_PRODUCT_ID_LEN; i += 3) {
> +		if (!slf3s_crc_valid(sf, &buf[i]))
> +			return -EIO;
> +	}
> +
> +	if (buf[SLF3S_PRODUCT_FAMILY_BYTE] != SLF3S_PRODUCT_FAMILY_ID)
> +		dev_dbg(&client->dev,
> +			"unexpected family byte 0x%02x (expected 0x%02x)\n",
> +			buf[SLF3S_PRODUCT_FAMILY_BYTE],
> +			SLF3S_PRODUCT_FAMILY_ID);
> +
> +	for (unsigned int i = 0; i < ARRAY_SIZE(slf3s_variants); i++) {
> +		if (buf[SLF3S_PRODUCT_SUBTYPE_BYTE] !=
> +		    slf3s_variants[i].sub_type)
I'd go slightly long and have that one line.
		if (buf[SLF3S_PRODUCT_SUBTYPE_BYTE] != slf3s_variants[i].sub_type)
We are a bit flexible on the 80 chars where it helps readabilty.


> +			continue;
> +
> +		if (sf->variant && sf->variant != &slf3s_variants[i])
> +			dev_dbg(&client->dev,
> +				"DT compatible says %s but sub-type 0x%02x suggests %s\n",
> +				sf->variant->name,
> +				buf[SLF3S_PRODUCT_SUBTYPE_BYTE],
> +				slf3s_variants[i].name);
> +		else if (!sf->variant)

If this happens I'd go with the detection over the dt provided. And dev_info
for the mismatch as we want people to know wrong sensor is described.

> +			sf->variant = &slf3s_variants[i];
> +		return 0;
> +	}
> +
> +	if (sf->variant) {
> +		dev_dbg(&client->dev,
> +			"unknown SLF3S sub-type 0x%02x, trusting DT compatible %s\n",
> +			buf[SLF3S_PRODUCT_SUBTYPE_BYTE], sf->variant->name);
> +		return 0;
> +	}
> +
> +	dev_dbg(&client->dev, "unknown SLF3S sub-type 0x%02x\n",
> +		buf[SLF3S_PRODUCT_SUBTYPE_BYTE]);
As below. I'd have a blank line here

> +	return -ENODEV;
> +}
> +
> +static int slf3s_read_sample(struct slf3s_data *sf, int *flow, int *temp)
> +{
> +	u8 buf[SLF3S_MEAS_LEN];
> +	int ret;
> +
> +	ret = i2c_master_recv(sf->client, buf, sizeof(buf));
> +	if (ret < 0)
> +		return ret;
> +	if (ret != sizeof(buf))
> +		return -EIO;
> +
> +	for (unsigned int i = 0; i < SLF3S_MEAS_LEN; i += 3) {
> +		if (!slf3s_crc_valid(sf, &buf[i]))
> +			return -EIO;
> +	}
> +
> +	*flow = sign_extend32(get_unaligned_be16(&buf[0]), 15);
> +	*temp = sign_extend32(get_unaligned_be16(&buf[3]), 15);

Trivial but good to have a blank line before simple return statements like
this. Just makes the code a tiny bit more readable.

> +	return 0;
> +}

> +
> +static int slf3s_read_raw(struct iio_dev *indio_dev,
> +			  struct iio_chan_spec const *chan, int *val,
> +			  int *val2, long mask)
> +{
> +	struct slf3s_data *sf = iio_priv(indio_dev);
> +	int flow, temp, ret;
> +
> +	switch (mask) {
> +	case IIO_CHAN_INFO_RAW:
> +		if (!iio_device_claim_direct(indio_dev))
> +			return -EBUSY;
> +
> +		ret = slf3s_read_sample(sf, &flow, &temp);
> +		iio_device_release_direct(indio_dev);
> +		if (ret)
> +			return ret;
> +
> +		*val = (chan->type == IIO_VOLUMEFLOW) ? flow : temp;
> +		return IIO_VAL_INT;
> +	case IIO_CHAN_INFO_SCALE:
> +		if (chan->type == IIO_VOLUMEFLOW) {
> +			*val = sf->variant->scale_num;
> +			*val2 = sf->variant->scale_den;

Sashiko (probably correctly) identifies that the formatting that the IIO core
does for an IIO_VAL_FRACTIONAL only goes to 9 decimal places.  That means
in some cases the scale is truncated to 1 digit losing much of its usefulness.
https://sashiko.dev/#/patchset/20260527184257.141635-1-wafgo01%40gmail.com

As such we need to increase the number of digits or maybe switch to using
https://lore.kernel.org/all/20260524-adf41513-iio-driver-v14-6-06824d9c15f4@analog.com/

Which defines IIO_VAL_DECIMAL64_PICO

+CC Rodrigo


> +			return IIO_VAL_FRACTIONAL;
> +		}
> +		*val = SLF3S_TEMP_SCALE_MILLIC;
> +		return IIO_VAL_INT;
> +	default:
> +		return -EINVAL;
> +	}
> +}

> +
> +static int slf3s_probe(struct i2c_client *client)
> +{
> +	struct device *dev = &client->dev;
> +	struct iio_dev *indio_dev;
> +	struct slf3s_data *sf;
> +	const u8 *start_cmd = slf3s_cmd_start_water;
> +	const char *medium;
> +	int ret;
> +
> +	indio_dev = devm_iio_device_alloc(dev, sizeof(*sf));
> +	if (!indio_dev)
> +		return -ENOMEM;
> +
> +	sf = iio_priv(indio_dev);
> +	sf->client = client;
> +	sf->variant = i2c_get_match_data(client);
> +	crc8_populate_msb(sf->crc_table, SLF3S_CRC8_POLY);
> +
> +	ret = devm_regulator_get_enable(dev, "vdd");
> +	if (ret)
> +		return dev_err_probe(dev, ret, "failed to enable vdd supply\n");

More than likely we need some level of sleep here for the device to wake up.
Is there anything in the datasheet?

> +
> +	ret = slf3s_detect_variant(sf);
> +	if (ret)
> +		return dev_err_probe(dev, ret, "product info read failed\n");

> +
> +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] },
> +	{ .compatible = "sensirion,slf3s" },

This came up in the dt review, so I'll assume you'll address it there. How useful
is the generic compatible?

> +	{ }
> +};
> +MODULE_DEVICE_TABLE(of, slf3s_of_match);
> +
> +static struct i2c_driver slf3s_driver = {
> +	.driver = {
> +		.name		= "slf3s",
> +		.of_match_table	= slf3s_of_match,
> +	},
> +	.probe		= slf3s_probe,
> +	.id_table	= slf3s_id,
> +};
> +module_i2c_driver(slf3s_driver);
> +
> +MODULE_AUTHOR("Wadim Mueller <wafgo01@gmail.com>");
> +MODULE_DESCRIPTION("Sensirion SLF3S liquid flow sensor driver");
> +MODULE_LICENSE("GPL");

Re: [PATCH v2 3/3] iio: flow: add Sensirion SLF3S liquid flow sensor driver

[Rodrigo Alencar]

On 26/05/28 12:22PM, Jonathan Cameron wrote:
> On Wed, 27 May 2026 20:42:54 +0200
> Wadim Mueller <wafgo01@gmail.com> wrote:
> 
> > Add a driver for the Sensirion SLF3S family of digital liquid-flow
> > sensors (SLF3S-0600F, SLF3S-1300F and SLF3S-4000B).  The sensors
> > communicate over I2C and return a 16-bit signed flow value, a 16-bit
> > signed temperature reading and a status word - each protected by a
> > CRC-8 byte - in every measurement frame.
> > 
> > The driver exposes:
> > 
> >   in_volumeflow_raw     - signed raw counts
> >   in_volumeflow_scale   - litres per second per LSB (per variant)
> >   in_temp_raw           - signed raw counts
> >   in_temp_scale         - millidegrees Celsius per LSB
> > 
> > The variant is auto-detected from the product-info word read at
> > probe time.  All three SLF3S devices are factory-calibrated for both
> > water and isopropyl alcohol; the calibration medium is selected via
> > the sensirion,medium device property and defaults to water.
> > 
> > Scale factors are taken from the respective datasheets (Table 16
> > for SLF3S-0600F, Table 15 for SLF3S-1300F and SLF3S-4000B):
> > 
> >   SLF3S-0600F:  10 (ul/min)^-1  -> 1/600 000 000 (l/s)/LSB
> >   SLF3S-1300F: 500 (ml/min)^-1  -> 1/30 000 000  (l/s)/LSB
> >   SLF3S-4000B:  32 (ml/min)^-1  -> 1/1 920 000   (l/s)/LSB

...

> > +static int slf3s_read_raw(struct iio_dev *indio_dev,
> > +			  struct iio_chan_spec const *chan, int *val,
> > +			  int *val2, long mask)
> > +{
> > +	struct slf3s_data *sf = iio_priv(indio_dev);
> > +	int flow, temp, ret;
> > +
> > +	switch (mask) {
> > +	case IIO_CHAN_INFO_RAW:
> > +		if (!iio_device_claim_direct(indio_dev))
> > +			return -EBUSY;
> > +
> > +		ret = slf3s_read_sample(sf, &flow, &temp);
> > +		iio_device_release_direct(indio_dev);
> > +		if (ret)
> > +			return ret;
> > +
> > +		*val = (chan->type == IIO_VOLUMEFLOW) ? flow : temp;
> > +		return IIO_VAL_INT;
> > +	case IIO_CHAN_INFO_SCALE:
> > +		if (chan->type == IIO_VOLUMEFLOW) {
> > +			*val = sf->variant->scale_num;
> > +			*val2 = sf->variant->scale_den;
> 
> Sashiko (probably correctly) identifies that the formatting that the IIO core
> does for an IIO_VAL_FRACTIONAL only goes to 9 decimal places.  That means
> in some cases the scale is truncated to 1 digit losing much of its usefulness.
> https://sashiko.dev/#/patchset/20260527184257.141635-1-wafgo01%40gmail.com
> 
> As such we need to increase the number of digits or maybe switch to using
> https://lore.kernel.org/all/20260524-adf41513-iio-driver-v14-6-06824d9c15f4@analog.com/
> 
> Which defines IIO_VAL_DECIMAL64_PICO

yes, pico would be enough, but IIO_VAL_DECIMAL64_FEMTO could also be defined if needed. 
There will be a v15, then let me know if any changes are needed.

-- 
Kind regards,

Rodrigo Alencar

Re: [PATCH v2 0/3] iio: flow: Sensirion SLF3S liquid flow sensor

[Jonathan Cameron]

On Wed, 27 May 2026 20:42:51 +0200
Wadim Mueller <wafgo01@gmail.com> wrote:

> Hi all,
> 
> v2 addresses the inline review feedback from Jonathan and Guenter on v1
> (see https://lore.kernel.org/linux-iio/20260524205112.26638-1-wafgo01@gmail.com/).
> Per-patch replies have been sent in the v1 thread.

Hi Wadim

Please don't send a v2 in reply to the v1 thread. That's a good
way to reduce the number of folk who read it plus end up with a complex
email thread. New thread for each version.

I only noticed this because I was looking at patchwork.

Thanks,

Jonathan