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

From: Jonathan Cameron

Date: Sun Jun 14 2026 - 11:19:28 EST


On Thu, 11 Jun 2026 15:27:00 +0200
Wadim Mueller <wafgo01@xxxxxxxxx> wrote:

> Add a driver for the Sensirion SLF3S family of digital
> liquid-flow sensors on I2C. Currently supported variants are
> SLF3S-0600F, SLF3S-1300F and SLF3S-4000B; they share the same
> register map and differ only in flow-scale factor and calibrated
> measurement range. The variant (and therefore the scale) is
> auto-detected from the product-information register at probe time;
> a sensor reporting an unknown sub-type falls back to the variant
> named in the device tree, as promised by the fallback compatible.
>
> Each measurement frame returns a 16-bit signed flow value, a
> 16-bit signed temperature reading and a status word, each
> protected by a CRC-8 byte. The driver exposes the flow rate as
> IIO_VOLUMEFLOW and the temperature as IIO_TEMP via the standard
> IIO read_raw / read_scale interface.
>
> The volume-flow scale is reported in m^3/s. As the per-LSB scale
> is on the order of 1e-12 m^3/s, it is emitted as a 64-bit
> fixed-point value with femto (1e-15) resolution
> (IIO_VAL_DECIMAL64_FEMTO) so the small SI value keeps full
> precision. This relies on the IIO_VAL_DECIMAL64_FEMTO format type
> added earlier in this series, which extends the IIO_VAL_DECIMAL64
> core formatting introduced by Rodrigo Alencar's ADF41513 series.
>
> The active calibration medium can be switched at runtime between
> the factory-calibrated water and isopropyl-alcohol modes via the
> in_volumeflow_medium sysfs attribute; the sensor starts in water
> mode after probe.
>
> The sensor has no low-power state of its own, so system suspend
> stops the measurement and disables the vdd supply; resume powers
> the sensor back up, waits out the power-up time and restarts the
> measurement with the previously active medium, following the
> scd30/scd4x precedent.
>
> This driver also creates the drivers/iio/flow/ subdirectory and
> the corresponding Kconfig/Makefile glue.
>
> Signed-off-by: Wadim Mueller <wafgo01@xxxxxxxxx>
A few minor things inline.

Thanks,

Jonathan

> diff --git a/drivers/iio/flow/slf3s.c b/drivers/iio/flow/slf3s.c
> new file mode 100644
> index 000000000..ed7b89e8e
> --- /dev/null
> +++ b/drivers/iio/flow/slf3s.c
> @@ -0,0 +1,521 @@

> +/**
> + * struct slf3s_data - per-device state
> + * @client: I2C client this instance is bound to
> + * @vdd: supply regulator, disabled while suspended
> + * @variant: pointer into @slf3s_variants for the detected device
> + * @medium: currently active calibration medium
> + * @lock: serialises the multi-step command/response exchanges
> + * @crc_table: pre-computed CRC-8 lookup table for SLF3S_CRC8_POLY
> + */
> +struct slf3s_data {
> + struct i2c_client *client;
> + struct regulator *vdd;
> + const struct slf3s_variant *variant;
> + enum slf3s_medium medium;
> + struct mutex lock; /* serialises command/response exchanges */

Feel free to ignore checkpatch moaning about lack of comment.
There is a perfectly good one above, duplicating that info here is
pointless!

> + u8 crc_table[CRC8_TABLE_SIZE];
> +};

> +
> +/*
> + * Read the product-info block and pick the matching variant. The
> + * sub-type byte returned by the sensor is the source of truth; a
> + * DT-supplied compatible only seeds an initial guess and is overridden
> + * on mismatch (with an informational message so misconfigured device
> + * trees are easy to spot).
> + *
> + * Bus / CRC failures are real errors and fail probe. An unknown
> + * sub-type byte falls back to the variant named in the device tree /
> + * I2C table: the fallback compatible promises that future family
> + * members work as an SLF3S-1300F, so do not reject them. Without any
> + * match data probe fails since no meaningful scale can be published.
> + */
> +static int slf3s_detect_variant(struct slf3s_data *sf)
> +{
> + struct i2c_client *client = sf->client;
> + u8 buf[SLF3S_PRODUCT_ID_LEN];
> + int ret;
> +
> + ret = slf3s_send_cmd(client, slf3s_cmd_prep_pid);
> + if (ret)
> + return ret;
> +
> + ret = slf3s_send_cmd(client, slf3s_cmd_read_pid);
> + if (ret)
> + return ret;
> +
> + ret = i2c_master_recv(client, buf, sizeof(buf));
> + if (ret < 0)
> + return ret;
> + if (ret != sizeof(buf))
> + return -EIO;
> +
> + for (unsigned int i = 0; i < SLF3S_PRODUCT_ID_LEN; i += 3) {
> + if (!slf3s_crc_valid(sf, &buf[i]))
> + return -EIO;
> + }
> +
> + if (buf[SLF3S_PRODUCT_FAMILY_BYTE] != SLF3S_PRODUCT_FAMILY_ID)
> + dev_info(&client->dev,
> + "unexpected family byte 0x%02x (expected 0x%02x)\n",
> + buf[SLF3S_PRODUCT_FAMILY_BYTE],
> + SLF3S_PRODUCT_FAMILY_ID);
> +
> + for (unsigned int i = 0; i < ARRAY_SIZE(slf3s_variants); i++) {
> + if (buf[SLF3S_PRODUCT_SUBTYPE_BYTE] !=
> + slf3s_variants[i].sub_type)
> + continue;
> +
> + if (sf->variant && sf->variant != &slf3s_variants[i])
> + dev_info(&client->dev,
> + "DT compatible says %s but sensor reports %s; using %s\n",
> + sf->variant->name,
> + slf3s_variants[i].name,
> + slf3s_variants[i].name);

Two params are the same which seems unlikely to be the intent.

> +
> + sf->variant = &slf3s_variants[i];
> +
> + return 0;
> + }
> +
> + if (sf->variant) {
> + dev_warn(&client->dev,
> + "unknown SLF3S sub-type 0x%02x, assuming %s\n",
> + buf[SLF3S_PRODUCT_SUBTYPE_BYTE], sf->variant->name);
> + return 0;
> + }
> +
> + dev_err(&client->dev, "unknown SLF3S sub-type 0x%02x\n",
> + buf[SLF3S_PRODUCT_SUBTYPE_BYTE]);
> +
> + return -ENODEV;
> +}



> +
> +static DEFINE_SIMPLE_DEV_PM_OPS(slf3s_pm_ops, slf3s_suspend, slf3s_resume);
> +
> +static const struct i2c_device_id slf3s_id[] = {
> + { .name = "slf3s-0600f",
> + .driver_data = (kernel_ulong_t)&slf3s_variants[0] },
> + { .name = "slf3s-1300f",
> + .driver_data = (kernel_ulong_t)&slf3s_variants[1] },
> + { .name = "slf3s-4000b",
> + .driver_data = (kernel_ulong_t)&slf3s_variants[2] },
Format as:
{
.name = "slf3s-4000b",
.driver_data = (kernel_ulong_t)&slf3s_variants[ENUM_VAL],
},
> + { }
> +};
> +MODULE_DEVICE_TABLE(i2c, slf3s_id);