[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

[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

[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

[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 1/4] iio: types: add IIO_VOLUMEFLOW channel type

[sashiko-bot]

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

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260524205112.26638-1-wafgo01@gmail.com?part=1

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The binding defines a generic compatible string `sensirion,slf3s` instead of specific hardware part numbers.
--

commit 5a08fd855b770d7594ec38ac7c89f4642153097b
Author: Wadim Mueller <wadim.mueller@cmblu.de>

dt-bindings: iio: flow: add Sensirion SLF3x liquid flow sensor

This commit adds a device tree binding for the Sensirion SLF3x family of I2C
liquid-flow sensors. It exposes a single generic compatible string and relies
on runtime detection to differentiate between sub-types.

> diff --git a/Documentation/devicetree/bindings/iio/flow/sensirion,slf3s.yaml b/Documentation/devicetree/bindings/iio/flow/sensirion,slf3s.yaml
> new file mode 100644
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/flow/sensirion,slf3s.yaml

[ ... ]

> +properties:
> +  compatible:
> +    enum:
> +      - sensirion,slf3s

[Severity: Low]
Should this define specific hardware part numbers like "sensirion,slf3s-0600f"
and "sensirion,slf3s-4000b" instead of just a generic string?

Standard device tree practice usually requires describing the exact hardware
present on the board rather than relying solely on driver auto-detection
logic. Including specific compatibles, potentially with this generic string as
a fallback, could ensure forward compatibility if future hardware revisions
modify or break the auto-detection mechanism.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260524205112.26638-1-wafgo01@gmail.com?part=2

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] The fractional scale for the SLF3S-4000B variant evaluates to exactly 0.0 in sysfs due to IIO formatting logic, permanently zeroing out flow readings for userspace.
- [Medium] Concurrent initialization of the shared global `slf3x_crc_table` in `probe()` causes a data race.
- [Medium] Continuous measurement mode is not restarted after a system suspend/resume cycle.
--

commit 2a3dbf69e1c64c32d26f6f97455487233c63c7c0
Author: Wadim Mueller <wadim.mueller@cmblu.de>

iio: flow: add Sensirion SLF3x liquid flow sensor driver

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.

> diff --git a/drivers/iio/flow/slf3x.c b/drivers/iio/flow/slf3x.c
> new file mode 100644
> index 0000000000000..e4ee1a04a46d7
> --- /dev/null
> +++ b/drivers/iio/flow/slf3x.c

[ ... ]

> +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 },

[Severity: High]
Will the fractional scale for the SLF3S-4000B variant permanently zero out
flow readings for userspace?

The driver returns IIO_VAL_FRACTIONAL with val = 1 and val2 = 1666680000.
The IIO core formats fractional values for sysfs up to nanounit precision
(9 decimal places) using the calculation (val * 1000000000LL) / val2.

Because the denominator (1,666,680,000) is strictly larger than the 10^9
multiplier, the integer division computes to exactly 0. As a result, the
string emitted to sysfs will be 0.000000000.

Userspace applications rely on this sysfs attribute to convert raw readings
into physical units, meaning any flow rate reading will be multiplied by 0.0,
rendering the sensor's flow channel completely non-functional.

> +};

[ ... ]

> +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);

[Severity: Medium]
Can this concurrent initialization of the shared global slf3x_crc_table cause
a data race?

The driver defines a global static array slf3x_crc_table and dynamically
populates it by calling crc8_populate_msb() unconditionally during
slf3x_probe().

If multiple SLF3x sensors are present and probed concurrently on different I2C
buses, or if a newly plugged sensor is probed while an already-registered
sensor is handling an active read, multiple threads will concurrently modify
or read the global table without synchronization.

This could result in transient -EIO errors or Kernel Concurrency Sanitizer
warnings.

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

[ ... ]

> +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);

[Severity: Medium]
Will continuous measurement mode fail to restart after a system suspend/resume
cycle?

The driver initiates the sensor's continuous measurement mode (0x36 0x08)
exclusively in probe() and assumes the device stays in this mode indefinitely
to fetch samples on demand in read_raw().

However, the driver does not implement power management suspend and resume
callbacks. If the system suspends and the sensor loses power (e.g., via
regulator cutoff), it will wake up in its default idle state.

Without a resume callback to re-issue the continuous measurement command,
subsequent read operations in read_raw() will return invalid data, silently
breaking the driver after a suspend/resume cycle.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260524205112.26638-1-wafgo01@gmail.com?part=3

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

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

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

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

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. 

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] The MAINTAINERS entry for the 'SENSIRION SLF3S LIQUID FLOW SENSOR DRIVER' broadly claims the entire 'drivers/iio/flow/' directory instead of just its specific driver files.
- [Medium] The `sensirion,medium` property encodes software configuration instead of hardware description.
- [Medium] The `compatible` schema allows the generic fallback string `sensirion,slf3s` to be used by itself.
--

commit 40e1aaa676db52ce37dbf148be41d0cd96f854a7
Author: Wadim Mueller <wafgo01@gmail.com>

dt-bindings: iio: flow: add Sensirion SLF3S liquid flow sensor

This commit documents the device tree bindings for the Sensirion SLF3S family
of digital liquid-flow sensors. It includes the compatible strings, required
properties, and a custom property for selecting the calibration medium. It also
adds the corresponding MAINTAINERS entry for the driver.

> 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 0000000000000..f58cf199ac3a8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/flow/sensirion,slf3s.yaml

[ ... ]

> +properties:
> +  compatible:
> +    oneOf:
> +      - items:
> +          - enum:
> +              - sensirion,slf3s-0600f
> +              - sensirion,slf3s-1300f
> +              - sensirion,slf3s-4000b
> +          - const: sensirion,slf3s
> +      - const: sensirion,slf3s

[Severity: Medium]
Does this schema allow the generic fallback string sensirion,slf3s to be used
by itself?

Device tree best practices generally mandate that nodes include a hardware
specific compatible string to uniquely identify the device, even when a
generic fallback is present. Allowing the generic string alone could prevent
the OS from identifying exact hardware variations or applying variant-specific
quirks.

Should the standalone - const: sensirion,slf3s option be removed?

[ ... ]

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

[Severity: Medium]
Does the sensirion,medium property encode software configuration instead of
hardware description?

Since device tree bindings are meant to strictly describe hardware structure
and integration, usage policies like the target fluid medium might be better
suited for user-space control.

Could this calibration setting be exposed via an IIO sysfs attribute instead
of being hardcoded in the device tree?

[ ... ]

> diff --git a/MAINTAINERS b/MAINTAINERS
> index 6aa3fe2ee1bbf..7eeabe22fcdd5 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS

[ ... ]

> +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/

[Severity: Medium]
Will this broad directory pattern cause get_maintainer.pl to assign
maintainership of all future IIO flow sensors to this driver's authors?

Since F: drivers/iio/flow/ encompasses the entire subsystem-level directory,
it will match any future flow sensors added by other vendors.

Could this be scoped to the specific driver files, such as
F: drivers/iio/flow/slf3s* ?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260527184257.141635-1-wafgo01@gmail.com?part=2

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
> 

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

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

[Wadim Mueller]

On Thu, May 28, 2026 at 11:07:18AM +0200, Krzysztof Kozlowski wrote:
> Do not attach (thread) your patchsets to some other threads (unrelated
> or older versions). [...]

Understood, v3 will be a new thread.

> No need for cc of maintainers here which are output by
> get_maintainers.pl. [...] Anyway, your SoB must be the last.

Ok, will drop the manual Cc block and put SoB last.

> > +      - const: sensirion,slf3s
> 
> That's confusing - why do you have generic compatible allowed to be
> alone?

The driver detects the sub-type anyway, so the generic-only form
does not add anything. Will drop it and keep only the fallback
pair.

> > +  sensirion,medium:
> 
> Sounds like you configure driver probe behavior. Why this is board-level
> static configuration (DT)?

Agreed, that is runtime config and not hardware description. Will
drop the property and expose it as a sysfs RW attribute instead.

> Please make example complete - add all properties.

Will do.

> > +F:drivers/iio/flow/
> 
> Drop, you don't maintain that directory here.

Will drop, only the binding YAML and slf3s.c stay.

Thanks,
Wadim