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
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
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
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
On Thu, 28 May 2026 11:14:14 +0100 Jonathan Cameron <jic23@kernel.org> wrote: > 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. sorry, will not do that anymore. v3 will be a fresh thread. Thanks, Wadim
Add a new IIO channel type for liquid volumetric flow sensors. The
unit exposed via the standard _scale attribute is litres per second
(l/s), so drivers reporting smaller native units (e.g. ml/min) only
need to set a fractional scale.
Update iio-core's name table, the iio_event_monitor whitelist and
the sysfs-bus-iio ABI document to match. The new _scale attribute is
folded into the existing shared _scale block; only the per-type _raw
needs a fresh entry.
Signed-off-by: Wadim Mueller <wafgo01@gmail.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Jean Delvare <jdelvare@suse.com>
Cc: Andreas Klinger <ak@it-klinger.de>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: linux-hwmon@vger.kernel.org
Cc: Maxwell Doose <m32285159@gmail.com>
---
Documentation/ABI/testing/sysfs-bus-iio | 11 +++++++++++
drivers/iio/industrialio-core.c | 1 +
include/uapi/linux/iio/types.h | 1 +
tools/iio/iio_event_monitor.c | 2 ++
4 files changed, 15 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio
index 5f87dcee7..2188557cb 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -507,6 +507,8 @@ What: /sys/bus/iio/devices/iio:deviceX/in_intensity_red_scale
What: /sys/bus/iio/devices/iio:deviceX/in_intensity_green_scale
What: /sys/bus/iio/devices/iio:deviceX/in_intensity_blue_scale
What: /sys/bus/iio/devices/iio:deviceX/in_concentration_co2_scale
+What: /sys/bus/iio/devices/iio:deviceX/in_volumeflow_scale
+What: /sys/bus/iio/devices/iio:deviceX/in_volumeflowY_scale
KernelVersion: 2.6.35
Contact: linux-iio@vger.kernel.org
Description:
@@ -2458,3 +2460,12 @@ Description:
seconds, expressed as:
- a range specified as "[min step max]"
+
+What: /sys/bus/iio/devices/iio:deviceX/in_volumeflow_raw
+What: /sys/bus/iio/devices/iio:deviceX/in_volumeflowY_raw
+KernelVersion: 6.19
+Contact: linux-iio@vger.kernel.org
+Description:
+ Raw (unscaled) volumetric flow rate reading from the channel.
+ To convert to standard units (litres per second) apply the
+ channel's _scale (and _offset, when present).
diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index 22eefd048..aa34fcd8e 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -98,6 +98,7 @@ static const char * const iio_chan_type_name_spec[] = {
[IIO_CHROMATICITY] = "chromaticity",
[IIO_ATTENTION] = "attention",
[IIO_ALTCURRENT] = "altcurrent",
+ [IIO_VOLUMEFLOW] = "volumeflow",
};
static const char * const iio_modifier_names[] = {
diff --git a/include/uapi/linux/iio/types.h b/include/uapi/linux/iio/types.h
index 6d269b844..49480f321 100644
--- a/include/uapi/linux/iio/types.h
+++ b/include/uapi/linux/iio/types.h
@@ -53,6 +53,7 @@ enum iio_chan_type {
IIO_CHROMATICITY,
IIO_ATTENTION,
IIO_ALTCURRENT,
+ IIO_VOLUMEFLOW,
};
enum iio_modifier {
diff --git a/tools/iio/iio_event_monitor.c b/tools/iio/iio_event_monitor.c
index 03ca33869..078004750 100644
--- a/tools/iio/iio_event_monitor.c
+++ b/tools/iio/iio_event_monitor.c
@@ -65,6 +65,7 @@ static const char * const iio_chan_type_name_spec[] = {
[IIO_CHROMATICITY] = "chromaticity",
[IIO_ATTENTION] = "attention",
[IIO_ALTCURRENT] = "altcurrent",
+ [IIO_VOLUMEFLOW] = "volumeflow",
};
static const char * const iio_ev_type_text[] = {
@@ -193,6 +194,7 @@ static bool event_is_known(struct iio_event_data *event)
case IIO_CHROMATICITY:
case IIO_ATTENTION:
case IIO_ALTCURRENT:
+ case IIO_VOLUMEFLOW:
break;
default:
return false;
--
2.52.0On Wed, 27 May 2026 20:42:52 +0200
Wadim Mueller <wafgo01@gmail.com> wrote:
> Add a new IIO channel type for liquid volumetric flow sensors. The
> unit exposed via the standard _scale attribute is litres per second
> (l/s), so drivers reporting smaller native units (e.g. ml/min) only
> need to set a fractional scale.
Hi Wadim
You (I think) raised a useful point in v1. Given the SI units thing should
we actually be doing m^3/sec? for this new type? That would be more
inline with existing units including distance.
There is a slight inconsistency for Ph which is log_10(ions per litre)
I'd like more opinions on this as I've made some less than idea decisions
on units in the past!
One other thing inline.
Jonathan
>
> Update iio-core's name table, the iio_event_monitor whitelist and
> the sysfs-bus-iio ABI document to match. The new _scale attribute is
> folded into the existing shared _scale block; only the per-type _raw
> needs a fresh entry.
>
> Signed-off-by: Wadim Mueller <wafgo01@gmail.com>
> Cc: Guenter Roeck <linux@roeck-us.net>
> Cc: Jean Delvare <jdelvare@suse.com>
> Cc: Andreas Klinger <ak@it-klinger.de>
> Cc: Lars-Peter Clausen <lars@metafoo.de>
> Cc: linux-hwmon@vger.kernel.org
> Cc: Maxwell Doose <m32285159@gmail.com>
> ---
> Documentation/ABI/testing/sysfs-bus-iio | 11 +++++++++++
> drivers/iio/industrialio-core.c | 1 +
> include/uapi/linux/iio/types.h | 1 +
> tools/iio/iio_event_monitor.c | 2 ++
> 4 files changed, 15 insertions(+)
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio
> index 5f87dcee7..2188557cb 100644
> --- a/Documentation/ABI/testing/sysfs-bus-iio
> +++ b/Documentation/ABI/testing/sysfs-bus-iio
> @@ -507,6 +507,8 @@ What: /sys/bus/iio/devices/iio:deviceX/in_intensity_red_scale
> What: /sys/bus/iio/devices/iio:deviceX/in_intensity_green_scale
> What: /sys/bus/iio/devices/iio:deviceX/in_intensity_blue_scale
> What: /sys/bus/iio/devices/iio:deviceX/in_concentration_co2_scale
> +What: /sys/bus/iio/devices/iio:deviceX/in_volumeflow_scale
> +What: /sys/bus/iio/devices/iio:deviceX/in_volumeflowY_scale
I'm going to assume this driver only uses one of these. Generally we only introduce
stuff on first use, so drop the one you aren't using.
> KernelVersion: 2.6.35
> Contact: linux-iio@vger.kernel.org
> Description:
> @@ -2458,3 +2460,12 @@ Description:
> seconds, expressed as:
>
> - a range specified as "[min step max]"
> +
> +What: /sys/bus/iio/devices/iio:deviceX/in_volumeflow_raw
> +What: /sys/bus/iio/devices/iio:deviceX/in_volumeflowY_raw
> +KernelVersion: 6.19
> +Contact: linux-iio@vger.kernel.org
> +Description:
> + Raw (unscaled) volumetric flow rate reading from the channel.
> + To convert to standard units (litres per second) apply the
> + channel's _scale (and _offset, when present).
> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> index 22eefd048..aa34fcd8e 100644
> --- a/drivers/iio/industrialio-core.c
> +++ b/drivers/iio/industrialio-core.c
> @@ -98,6 +98,7 @@ static const char * const iio_chan_type_name_spec[] = {
> [IIO_CHROMATICITY] = "chromaticity",
> [IIO_ATTENTION] = "attention",
> [IIO_ALTCURRENT] = "altcurrent",
> + [IIO_VOLUMEFLOW] = "volumeflow",
> };
>
> static const char * const iio_modifier_names[] = {
> diff --git a/include/uapi/linux/iio/types.h b/include/uapi/linux/iio/types.h
> index 6d269b844..49480f321 100644
> --- a/include/uapi/linux/iio/types.h
> +++ b/include/uapi/linux/iio/types.h
> @@ -53,6 +53,7 @@ enum iio_chan_type {
> IIO_CHROMATICITY,
> IIO_ATTENTION,
> IIO_ALTCURRENT,
> + IIO_VOLUMEFLOW,
> };
>
> enum iio_modifier {
> diff --git a/tools/iio/iio_event_monitor.c b/tools/iio/iio_event_monitor.c
> index 03ca33869..078004750 100644
> --- a/tools/iio/iio_event_monitor.c
> +++ b/tools/iio/iio_event_monitor.c
> @@ -65,6 +65,7 @@ static const char * const iio_chan_type_name_spec[] = {
> [IIO_CHROMATICITY] = "chromaticity",
> [IIO_ATTENTION] = "attention",
> [IIO_ALTCURRENT] = "altcurrent",
> + [IIO_VOLUMEFLOW] = "volumeflow",
> };
>
> static const char * const iio_ev_type_text[] = {
> @@ -193,6 +194,7 @@ static bool event_is_known(struct iio_event_data *event)
> case IIO_CHROMATICITY:
> case IIO_ATTENTION:
> case IIO_ALTCURRENT:
> + case IIO_VOLUMEFLOW:
> break;
> default:
> return false;
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 = <®_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.0On 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 = <®_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
>
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
Add a driver for the Sensirion SLF3S family of digital liquid-flow
sensors (SLF3S-0600F, SLF3S-1300F and SLF3S-4000B). The sensors
communicate over I2C and return a 16-bit signed flow value, a 16-bit
signed temperature reading and a status word - each protected by a
CRC-8 byte - in every measurement frame.
The driver exposes:
in_volumeflow_raw - signed raw counts
in_volumeflow_scale - litres per second per LSB (per variant)
in_temp_raw - signed raw counts
in_temp_scale - millidegrees Celsius per LSB
The variant is auto-detected from the product-info word read at
probe time. All three SLF3S devices are factory-calibrated for both
water and isopropyl alcohol; the calibration medium is selected via
the sensirion,medium device property and defaults to water.
Scale factors are taken from the respective datasheets (Table 16
for SLF3S-0600F, Table 15 for SLF3S-1300F and SLF3S-4000B):
SLF3S-0600F: 10 (ul/min)^-1 -> 1/600 000 000 (l/s)/LSB
SLF3S-1300F: 500 (ml/min)^-1 -> 1/30 000 000 (l/s)/LSB
SLF3S-4000B: 32 (ml/min)^-1 -> 1/1 920 000 (l/s)/LSB
Signed-off-by: Wadim Mueller <wafgo01@gmail.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Jean Delvare <jdelvare@suse.com>
Cc: Andreas Klinger <ak@it-klinger.de>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: linux-hwmon@vger.kernel.org
Cc: Maxwell Doose <m32285159@gmail.com>
---
drivers/iio/Kconfig | 1 +
drivers/iio/Makefile | 1 +
drivers/iio/flow/Kconfig | 27 +++
drivers/iio/flow/Makefile | 7 +
drivers/iio/flow/slf3s.c | 345 ++++++++++++++++++++++++++++++++++++++
5 files changed, 381 insertions(+)
create mode 100644 drivers/iio/flow/Kconfig
create mode 100644 drivers/iio/flow/Makefile
create mode 100644 drivers/iio/flow/slf3s.c
diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
index 661127aed..652557a5b 100644
--- a/drivers/iio/Kconfig
+++ b/drivers/iio/Kconfig
@@ -92,6 +92,7 @@ source "drivers/iio/common/Kconfig"
source "drivers/iio/dac/Kconfig"
source "drivers/iio/dummy/Kconfig"
source "drivers/iio/filter/Kconfig"
+source "drivers/iio/flow/Kconfig"
source "drivers/iio/frequency/Kconfig"
source "drivers/iio/gyro/Kconfig"
source "drivers/iio/health/Kconfig"
diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
index cb80ef837..f03a4100c 100644
--- a/drivers/iio/Makefile
+++ b/drivers/iio/Makefile
@@ -29,6 +29,7 @@ obj-y += dac/
obj-y += dummy/
obj-y += gyro/
obj-y += filter/
+obj-y += flow/
obj-y += frequency/
obj-y += health/
obj-y += humidity/
diff --git a/drivers/iio/flow/Kconfig b/drivers/iio/flow/Kconfig
new file mode 100644
index 000000000..1eee131ea
--- /dev/null
+++ b/drivers/iio/flow/Kconfig
@@ -0,0 +1,27 @@
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# Liquid / gas flow sensor drivers
+#
+# When adding new entries keep the list in alphabetical order
+
+menu "Flow sensors"
+
+config SENSIRION_SLF3S
+ tristate "Sensirion SLF3S liquid flow sensor"
+ depends on I2C
+ select CRC8
+ help
+ Say yes here to build support for the Sensirion SLF3S family
+ of digital liquid-flow sensors:
+
+ - SLF3S-0600F
+ - SLF3S-1300F
+ - SLF3S-4000B
+
+ The driver reports the volumetric flow rate and the embedded
+ temperature reading via the standard IIO interface.
+
+ To compile this driver as a module, choose M here: the module
+ will be called slf3s.
+
+endmenu
diff --git a/drivers/iio/flow/Makefile b/drivers/iio/flow/Makefile
new file mode 100644
index 000000000..3cf4ab95c
--- /dev/null
+++ b/drivers/iio/flow/Makefile
@@ -0,0 +1,7 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# Makefile for industrial I/O flow sensor drivers
+#
+
+# When adding new entries keep the list in alphabetical order
+obj-$(CONFIG_SENSIRION_SLF3S) += slf3s.o
diff --git a/drivers/iio/flow/slf3s.c b/drivers/iio/flow/slf3s.c
new file mode 100644
index 000000000..f971a2dc2
--- /dev/null
+++ b/drivers/iio/flow/slf3s.c
@@ -0,0 +1,345 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Sensirion SLF3S liquid flow sensor driver.
+ *
+ * Supports the SLF3S-0600F, SLF3S-1300F and SLF3S-4000B liquid-flow
+ * sensors over I2C. Each measurement frame returns a 16-bit signed
+ * flow value, a 16-bit signed temperature value and a status word,
+ * each protected by a CRC-8 byte.
+ *
+ * Datasheet: https://sensirion.com/products/catalog/SLF3S-0600F/
+ *
+ * Copyright (C) 2026 CMBlu Energy GmbH
+ * Author: Wadim Mueller <wafgo01@gmail.com>
+ */
+
+#include <linux/bitops.h>
+#include <linux/crc8.h>
+#include <linux/delay.h>
+#include <linux/i2c.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/property.h>
+#include <linux/regulator/consumer.h>
+#include <linux/unaligned.h>
+
+#include <linux/iio/iio.h>
+
+#define SLF3S_CRC8_POLY 0x31
+#define SLF3S_CRC8_INIT 0xff
+
+#define SLF3S_PRODUCT_ID_LEN 18
+#define SLF3S_PRODUCT_FAMILY_BYTE 1
+#define SLF3S_PRODUCT_SUBTYPE_BYTE 3
+#define SLF3S_PRODUCT_FAMILY_ID 0x03
+
+#define SLF3S_MEAS_LEN 9
+#define SLF3S_MEAS_START_DELAY_US 12000
+
+/*
+ * Temperature LSB equals 1/200 degC. IIO_TEMP uses milli-degrees,
+ * therefore the scale exposed to userspace is 1000 / 200 = 5.
+ */
+#define SLF3S_TEMP_SCALE_MILLIC 5
+
+static const u8 slf3s_cmd_prep_pid[] = { 0x36, 0x7c };
+static const u8 slf3s_cmd_read_pid[] = { 0xe1, 0x02 };
+static const u8 slf3s_cmd_start_water[] = { 0x36, 0x08 };
+static const u8 slf3s_cmd_start_ipa[] = { 0x36, 0x15 };
+static const u8 slf3s_cmd_stop_meas[] = { 0x3f, 0xf9 };
+
+/**
+ * struct slf3s_variant - per-variant calibration constants
+ * @sub_type: product-info sub-type byte returned by the sensor
+ * @name: name reported via @iio_dev.name
+ * @scale_num: flow scale numerator (l/s per LSB)
+ * @scale_den: flow scale denominator (l/s per LSB)
+ */
+struct slf3s_variant {
+ u8 sub_type;
+ const char *name;
+ int scale_num;
+ int scale_den;
+};
+
+static const struct slf3s_variant slf3s_variants[] = {
+ [0] = {
+ .sub_type = 0x03,
+ .name = "slf3s-0600f",
+ .scale_num = 1,
+ .scale_den = 600000000,
+ },
+ [1] = {
+ .sub_type = 0x02,
+ .name = "slf3s-1300f",
+ .scale_num = 1,
+ .scale_den = 30000000,
+ },
+ [2] = {
+ .sub_type = 0x05,
+ .name = "slf3s-4000b",
+ .scale_num = 1,
+ .scale_den = 1920000,
+ },
+};
+
+/**
+ * struct slf3s_data - per-device state
+ * @client: I2C client this instance is bound to
+ * @variant: pointer into @slf3s_variants for the detected device
+ * @crc_table: pre-computed CRC-8 lookup table for SLF3S_CRC8_POLY
+ */
+struct slf3s_data {
+ struct i2c_client *client;
+ const struct slf3s_variant *variant;
+ u8 crc_table[CRC8_TABLE_SIZE];
+};
+
+static bool slf3s_crc_valid(const struct slf3s_data *sf, const u8 *block)
+{
+ return crc8(sf->crc_table, block, 2, SLF3S_CRC8_INIT) == block[2];
+}
+
+static int slf3s_send_cmd(struct i2c_client *client, const u8 cmd[static 2])
+{
+ int ret = i2c_master_send(client, cmd, 2);
+
+ if (ret == 2)
+ return 0;
+ return ret < 0 ? ret : -EIO;
+}
+
+/*
+ * Read the product-info block and update @sf->variant. The kernel
+ * trusts the DT compatible (or i2c id_table .data) above all else; the
+ * sub-type byte is a sanity hint. This means:
+ *
+ * - bus / CRC failures are real errors and must fail probe;
+ * - if the caller already picked a variant (specific compatible), the
+ * PID is logged for diagnostics but mismatches do not fail probe;
+ * - if the caller has no variant (generic "sensirion,slf3s" fallback),
+ * the sub-type byte is used to pick one; unknown sub-type fails.
+ */
+static int slf3s_detect_variant(struct slf3s_data *sf)
+{
+ struct i2c_client *client = sf->client;
+ u8 buf[SLF3S_PRODUCT_ID_LEN];
+ int ret;
+
+ ret = slf3s_send_cmd(client, slf3s_cmd_prep_pid);
+ if (ret)
+ return ret;
+
+ ret = slf3s_send_cmd(client, slf3s_cmd_read_pid);
+ if (ret)
+ return ret;
+
+ ret = i2c_master_recv(client, buf, sizeof(buf));
+ if (ret < 0)
+ return ret;
+ if (ret != sizeof(buf))
+ return -EIO;
+
+ for (unsigned int i = 0; i < SLF3S_PRODUCT_ID_LEN; i += 3) {
+ if (!slf3s_crc_valid(sf, &buf[i]))
+ return -EIO;
+ }
+
+ if (buf[SLF3S_PRODUCT_FAMILY_BYTE] != SLF3S_PRODUCT_FAMILY_ID)
+ dev_dbg(&client->dev,
+ "unexpected family byte 0x%02x (expected 0x%02x)\n",
+ buf[SLF3S_PRODUCT_FAMILY_BYTE],
+ SLF3S_PRODUCT_FAMILY_ID);
+
+ for (unsigned int i = 0; i < ARRAY_SIZE(slf3s_variants); i++) {
+ if (buf[SLF3S_PRODUCT_SUBTYPE_BYTE] !=
+ slf3s_variants[i].sub_type)
+ continue;
+
+ if (sf->variant && sf->variant != &slf3s_variants[i])
+ dev_dbg(&client->dev,
+ "DT compatible says %s but sub-type 0x%02x suggests %s\n",
+ sf->variant->name,
+ buf[SLF3S_PRODUCT_SUBTYPE_BYTE],
+ slf3s_variants[i].name);
+ else if (!sf->variant)
+ sf->variant = &slf3s_variants[i];
+ return 0;
+ }
+
+ if (sf->variant) {
+ dev_dbg(&client->dev,
+ "unknown SLF3S sub-type 0x%02x, trusting DT compatible %s\n",
+ buf[SLF3S_PRODUCT_SUBTYPE_BYTE], sf->variant->name);
+ return 0;
+ }
+
+ dev_dbg(&client->dev, "unknown SLF3S sub-type 0x%02x\n",
+ buf[SLF3S_PRODUCT_SUBTYPE_BYTE]);
+ return -ENODEV;
+}
+
+static int slf3s_read_sample(struct slf3s_data *sf, int *flow, int *temp)
+{
+ u8 buf[SLF3S_MEAS_LEN];
+ int ret;
+
+ ret = i2c_master_recv(sf->client, buf, sizeof(buf));
+ if (ret < 0)
+ return ret;
+ if (ret != sizeof(buf))
+ return -EIO;
+
+ for (unsigned int i = 0; i < SLF3S_MEAS_LEN; i += 3) {
+ if (!slf3s_crc_valid(sf, &buf[i]))
+ return -EIO;
+ }
+
+ *flow = sign_extend32(get_unaligned_be16(&buf[0]), 15);
+ *temp = sign_extend32(get_unaligned_be16(&buf[3]), 15);
+ return 0;
+}
+
+static const struct iio_chan_spec slf3s_channels[] = {
+ {
+ .type = IIO_VOLUMEFLOW,
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
+ BIT(IIO_CHAN_INFO_SCALE),
+ },
+ {
+ .type = IIO_TEMP,
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
+ BIT(IIO_CHAN_INFO_SCALE),
+ },
+};
+
+static int slf3s_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan, int *val,
+ int *val2, long mask)
+{
+ struct slf3s_data *sf = iio_priv(indio_dev);
+ int flow, temp, ret;
+
+ switch (mask) {
+ case IIO_CHAN_INFO_RAW:
+ if (!iio_device_claim_direct(indio_dev))
+ return -EBUSY;
+
+ ret = slf3s_read_sample(sf, &flow, &temp);
+ iio_device_release_direct(indio_dev);
+ if (ret)
+ return ret;
+
+ *val = (chan->type == IIO_VOLUMEFLOW) ? flow : temp;
+ return IIO_VAL_INT;
+ case IIO_CHAN_INFO_SCALE:
+ if (chan->type == IIO_VOLUMEFLOW) {
+ *val = sf->variant->scale_num;
+ *val2 = sf->variant->scale_den;
+ return IIO_VAL_FRACTIONAL;
+ }
+ *val = SLF3S_TEMP_SCALE_MILLIC;
+ return IIO_VAL_INT;
+ default:
+ return -EINVAL;
+ }
+}
+
+static const struct iio_info slf3s_info = {
+ .read_raw = slf3s_read_raw,
+};
+
+static void slf3s_stop_meas(void *data)
+{
+ struct slf3s_data *sf = data;
+
+ slf3s_send_cmd(sf->client, slf3s_cmd_stop_meas);
+}
+
+static int slf3s_probe(struct i2c_client *client)
+{
+ struct device *dev = &client->dev;
+ struct iio_dev *indio_dev;
+ struct slf3s_data *sf;
+ const u8 *start_cmd = slf3s_cmd_start_water;
+ const char *medium;
+ int ret;
+
+ indio_dev = devm_iio_device_alloc(dev, sizeof(*sf));
+ if (!indio_dev)
+ return -ENOMEM;
+
+ sf = iio_priv(indio_dev);
+ sf->client = client;
+ sf->variant = i2c_get_match_data(client);
+ crc8_populate_msb(sf->crc_table, SLF3S_CRC8_POLY);
+
+ ret = devm_regulator_get_enable(dev, "vdd");
+ if (ret)
+ return dev_err_probe(dev, ret, "failed to enable vdd supply\n");
+
+ ret = slf3s_detect_variant(sf);
+ if (ret)
+ return dev_err_probe(dev, ret, "product info read failed\n");
+
+ ret = device_property_read_string(dev, "sensirion,medium", &medium);
+ if (!ret) {
+ if (!strcmp(medium, "ipa"))
+ start_cmd = slf3s_cmd_start_ipa;
+ else if (strcmp(medium, "water"))
+ return dev_err_probe(dev, -EINVAL,
+ "unknown sensirion,medium '%s'\n",
+ medium);
+ }
+
+ ret = slf3s_send_cmd(client, start_cmd);
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "failed to start measurement\n");
+
+ fsleep(SLF3S_MEAS_START_DELAY_US);
+
+ ret = devm_add_action_or_reset(dev, slf3s_stop_meas, sf);
+ if (ret)
+ return ret;
+
+ indio_dev->name = sf->variant->name;
+ indio_dev->channels = slf3s_channels;
+ indio_dev->num_channels = ARRAY_SIZE(slf3s_channels);
+ indio_dev->info = &slf3s_info;
+ indio_dev->modes = INDIO_DIRECT_MODE;
+
+ return devm_iio_device_register(dev, indio_dev);
+}
+
+static const struct i2c_device_id slf3s_id[] = {
+ { .name = "slf3s-0600f", .driver_data = (kernel_ulong_t)&slf3s_variants[0] },
+ { .name = "slf3s-1300f", .driver_data = (kernel_ulong_t)&slf3s_variants[1] },
+ { .name = "slf3s-4000b", .driver_data = (kernel_ulong_t)&slf3s_variants[2] },
+ { .name = "slf3s" },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, slf3s_id);
+
+static const struct of_device_id slf3s_of_match[] = {
+ { .compatible = "sensirion,slf3s-0600f", .data = &slf3s_variants[0] },
+ { .compatible = "sensirion,slf3s-1300f", .data = &slf3s_variants[1] },
+ { .compatible = "sensirion,slf3s-4000b", .data = &slf3s_variants[2] },
+ { .compatible = "sensirion,slf3s" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, slf3s_of_match);
+
+static struct i2c_driver slf3s_driver = {
+ .driver = {
+ .name = "slf3s",
+ .of_match_table = slf3s_of_match,
+ },
+ .probe = slf3s_probe,
+ .id_table = slf3s_id,
+};
+module_i2c_driver(slf3s_driver);
+
+MODULE_AUTHOR("Wadim Mueller <wafgo01@gmail.com>");
+MODULE_DESCRIPTION("Sensirion SLF3S liquid flow sensor driver");
+MODULE_LICENSE("GPL");
--
2.52.0On Wed, 27 May 2026 20:42:54 +0200
Wadim Mueller <wafgo01@gmail.com> wrote:
> Add a driver for the Sensirion SLF3S family of digital liquid-flow
> sensors (SLF3S-0600F, SLF3S-1300F and SLF3S-4000B). The sensors
> communicate over I2C and return a 16-bit signed flow value, a 16-bit
> signed temperature reading and a status word - each protected by a
> CRC-8 byte - in every measurement frame.
>
> The driver exposes:
>
> in_volumeflow_raw - signed raw counts
> in_volumeflow_scale - litres per second per LSB (per variant)
> in_temp_raw - signed raw counts
> in_temp_scale - millidegrees Celsius per LSB
>
> The variant is auto-detected from the product-info word read at
> probe time. All three SLF3S devices are factory-calibrated for both
> water and isopropyl alcohol; the calibration medium is selected via
> the sensirion,medium device property and defaults to water.
>
> Scale factors are taken from the respective datasheets (Table 16
> for SLF3S-0600F, Table 15 for SLF3S-1300F and SLF3S-4000B):
>
> SLF3S-0600F: 10 (ul/min)^-1 -> 1/600 000 000 (l/s)/LSB
> SLF3S-1300F: 500 (ml/min)^-1 -> 1/30 000 000 (l/s)/LSB
> SLF3S-4000B: 32 (ml/min)^-1 -> 1/1 920 000 (l/s)/LSB
>
> Signed-off-by: Wadim Mueller <wafgo01@gmail.com>
> Cc: Guenter Roeck <linux@roeck-us.net>
> Cc: Jean Delvare <jdelvare@suse.com>
> Cc: Andreas Klinger <ak@it-klinger.de>
> Cc: Lars-Peter Clausen <lars@metafoo.de>
> Cc: linux-hwmon@vger.kernel.org
> Cc: Maxwell Doose <m32285159@gmail.com>
A few fairly minor things inline. Also check out sashiko's review
https://sashiko.dev/#/patchset/20260527184257.141635-1-wafgo01%40gmail.com
(Note the DMA buffers stuff is wrong for I2C so ignore that)
> diff --git a/drivers/iio/flow/slf3s.c b/drivers/iio/flow/slf3s.c
> new file mode 100644
> index 000000000..f971a2dc2
> --- /dev/null
> +++ b/drivers/iio/flow/slf3s.c
> @@ -0,0 +1,345 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Sensirion SLF3S liquid flow sensor driver.
> + *
> + * Supports the SLF3S-0600F, SLF3S-1300F and SLF3S-4000B liquid-flow
> + * sensors over I2C. Each measurement frame returns a 16-bit signed
> + * flow value, a 16-bit signed temperature value and a status word,
> + * each protected by a CRC-8 byte.
> + *
> + * Datasheet: https://sensirion.com/products/catalog/SLF3S-0600F/
> + *
> + * Copyright (C) 2026 CMBlu Energy GmbH
> + * Author: Wadim Mueller <wafgo01@gmail.com>
> + */
> +
> +#include <linux/bitops.h>
> +#include <linux/crc8.h>
> +#include <linux/delay.h>
Check these. I'd expect dev_printk.h for instance.
Follow IWYU (approximately) for includes.
> +#include <linux/i2c.h>
> +#include <linux/mod_devicetable.h>
> +#include <linux/module.h>
> +#include <linux/property.h>
> +#include <linux/regulator/consumer.h>
> +#include <linux/unaligned.h>
> +
> +#include <linux/iio/iio.h>
> +
> +#define SLF3S_CRC8_POLY 0x31
> +#define SLF3S_CRC8_INIT 0xff
> +
> +#define SLF3S_PRODUCT_ID_LEN 18
> +#define SLF3S_PRODUCT_FAMILY_BYTE 1
> +#define SLF3S_PRODUCT_SUBTYPE_BYTE 3
> +#define SLF3S_PRODUCT_FAMILY_ID 0x03
> +
> +#define SLF3S_MEAS_LEN 9
I don't think this constant being a define is that useful. I'd push
the value down to where you set how big the buffer is then use ARRAY_SIZE()
for the loop
> +#define SLF3S_MEAS_START_DELAY_US 12000
> +
> +/*
> + * Temperature LSB equals 1/200 degC. IIO_TEMP uses milli-degrees,
> + * therefore the scale exposed to userspace is 1000 / 200 = 5.
> + */
> +#define SLF3S_TEMP_SCALE_MILLIC 5
I'd put this value inline with the comment. It's only used in one
place and that is where people will look for information on scale.
> +
> +static const struct slf3s_variant slf3s_variants[] = {
> + [0] = {
> + .sub_type = 0x03,
> + .name = "slf3s-0600f",
> + .scale_num = 1,
> + .scale_den = 600000000,
Probably more readable with 600 * MICRO
> + },
> + [1] = {
> + .sub_type = 0x02,
> + .name = "slf3s-1300f",
> + .scale_num = 1,
> + .scale_den = 30000000,
30 * MICRO
> + },
> + [2] = {
> + .sub_type = 0x05,
> + .name = "slf3s-4000b",
> + .scale_num = 1,
> + .scale_den = 1920000,
1920 * MILLI or leave this one as is. 4 zeros are easy to count ;)
> + },
> +};
> +
> +/**
> + * struct slf3s_data - per-device state
> + * @client: I2C client this instance is bound to
> + * @variant: pointer into @slf3s_variants for the detected device
> + * @crc_table: pre-computed CRC-8 lookup table for SLF3S_CRC8_POLY
> + */
> +struct slf3s_data {
> + struct i2c_client *client;
> + const struct slf3s_variant *variant;
> + u8 crc_table[CRC8_TABLE_SIZE];
> +};
> +
> +static bool slf3s_crc_valid(const struct slf3s_data *sf, const u8 *block)
I'd be consistent and have const u8 block[at_least 3]
the make it clear how big that is expected to be.
> +{
> + return crc8(sf->crc_table, block, 2, SLF3S_CRC8_INIT) == block[2];
> +}
> +
> +static int slf3s_send_cmd(struct i2c_client *client, const u8 cmd[static 2])
Use at_least, not static for kernel code as it makes it much more obvious what
is going on.
Note the sashiko report on this memory potentially being used for DMA is wrong.
The i2c subsystem only does that if you opt in.
> +{
> + int ret = i2c_master_send(client, cmd, 2);
> +
> + if (ret == 2)
> + return 0;
> + return ret < 0 ? ret : -EIO;
> +}
> +
> +/*
> + * Read the product-info block and update @sf->variant. The kernel
wrap at 80 chars. This is a bit short in places.
> + * trusts the DT compatible (or i2c id_table .data) above all else; the
> + * sub-type byte is a sanity hint. This means:
> + *
> + * - bus / CRC failures are real errors and must fail probe;
> + * - if the caller already picked a variant (specific compatible), the
> + * PID is logged for diagnostics but mismatches do not fail probe;
> + * - if the caller has no variant (generic "sensirion,slf3s" fallback),
> + * the sub-type byte is used to pick one; unknown sub-type fails.
This is interesting approach, but lets discuss it in the dt-binding thread.
> + */
> +static int slf3s_detect_variant(struct slf3s_data *sf)
> +{
> + struct i2c_client *client = sf->client;
> + u8 buf[SLF3S_PRODUCT_ID_LEN];
> + int ret;
> +
> + ret = slf3s_send_cmd(client, slf3s_cmd_prep_pid);
> + if (ret)
> + return ret;
> +
> + ret = slf3s_send_cmd(client, slf3s_cmd_read_pid);
> + if (ret)
> + return ret;
> +
> + ret = i2c_master_recv(client, buf, sizeof(buf));
> + if (ret < 0)
> + return ret;
> + if (ret != sizeof(buf))
> + return -EIO;
> +
> + for (unsigned int i = 0; i < SLF3S_PRODUCT_ID_LEN; i += 3) {
> + if (!slf3s_crc_valid(sf, &buf[i]))
> + return -EIO;
> + }
> +
> + if (buf[SLF3S_PRODUCT_FAMILY_BYTE] != SLF3S_PRODUCT_FAMILY_ID)
> + dev_dbg(&client->dev,
> + "unexpected family byte 0x%02x (expected 0x%02x)\n",
> + buf[SLF3S_PRODUCT_FAMILY_BYTE],
> + SLF3S_PRODUCT_FAMILY_ID);
> +
> + for (unsigned int i = 0; i < ARRAY_SIZE(slf3s_variants); i++) {
> + if (buf[SLF3S_PRODUCT_SUBTYPE_BYTE] !=
> + slf3s_variants[i].sub_type)
I'd go slightly long and have that one line.
if (buf[SLF3S_PRODUCT_SUBTYPE_BYTE] != slf3s_variants[i].sub_type)
We are a bit flexible on the 80 chars where it helps readabilty.
> + continue;
> +
> + if (sf->variant && sf->variant != &slf3s_variants[i])
> + dev_dbg(&client->dev,
> + "DT compatible says %s but sub-type 0x%02x suggests %s\n",
> + sf->variant->name,
> + buf[SLF3S_PRODUCT_SUBTYPE_BYTE],
> + slf3s_variants[i].name);
> + else if (!sf->variant)
If this happens I'd go with the detection over the dt provided. And dev_info
for the mismatch as we want people to know wrong sensor is described.
> + sf->variant = &slf3s_variants[i];
> + return 0;
> + }
> +
> + if (sf->variant) {
> + dev_dbg(&client->dev,
> + "unknown SLF3S sub-type 0x%02x, trusting DT compatible %s\n",
> + buf[SLF3S_PRODUCT_SUBTYPE_BYTE], sf->variant->name);
> + return 0;
> + }
> +
> + dev_dbg(&client->dev, "unknown SLF3S sub-type 0x%02x\n",
> + buf[SLF3S_PRODUCT_SUBTYPE_BYTE]);
As below. I'd have a blank line here
> + return -ENODEV;
> +}
> +
> +static int slf3s_read_sample(struct slf3s_data *sf, int *flow, int *temp)
> +{
> + u8 buf[SLF3S_MEAS_LEN];
> + int ret;
> +
> + ret = i2c_master_recv(sf->client, buf, sizeof(buf));
> + if (ret < 0)
> + return ret;
> + if (ret != sizeof(buf))
> + return -EIO;
> +
> + for (unsigned int i = 0; i < SLF3S_MEAS_LEN; i += 3) {
> + if (!slf3s_crc_valid(sf, &buf[i]))
> + return -EIO;
> + }
> +
> + *flow = sign_extend32(get_unaligned_be16(&buf[0]), 15);
> + *temp = sign_extend32(get_unaligned_be16(&buf[3]), 15);
Trivial but good to have a blank line before simple return statements like
this. Just makes the code a tiny bit more readable.
> + return 0;
> +}
> +
> +static int slf3s_read_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan, int *val,
> + int *val2, long mask)
> +{
> + struct slf3s_data *sf = iio_priv(indio_dev);
> + int flow, temp, ret;
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_RAW:
> + if (!iio_device_claim_direct(indio_dev))
> + return -EBUSY;
> +
> + ret = slf3s_read_sample(sf, &flow, &temp);
> + iio_device_release_direct(indio_dev);
> + if (ret)
> + return ret;
> +
> + *val = (chan->type == IIO_VOLUMEFLOW) ? flow : temp;
> + return IIO_VAL_INT;
> + case IIO_CHAN_INFO_SCALE:
> + if (chan->type == IIO_VOLUMEFLOW) {
> + *val = sf->variant->scale_num;
> + *val2 = sf->variant->scale_den;
Sashiko (probably correctly) identifies that the formatting that the IIO core
does for an IIO_VAL_FRACTIONAL only goes to 9 decimal places. That means
in some cases the scale is truncated to 1 digit losing much of its usefulness.
https://sashiko.dev/#/patchset/20260527184257.141635-1-wafgo01%40gmail.com
As such we need to increase the number of digits or maybe switch to using
https://lore.kernel.org/all/20260524-adf41513-iio-driver-v14-6-06824d9c15f4@analog.com/
Which defines IIO_VAL_DECIMAL64_PICO
+CC Rodrigo
> + return IIO_VAL_FRACTIONAL;
> + }
> + *val = SLF3S_TEMP_SCALE_MILLIC;
> + return IIO_VAL_INT;
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +static int slf3s_probe(struct i2c_client *client)
> +{
> + struct device *dev = &client->dev;
> + struct iio_dev *indio_dev;
> + struct slf3s_data *sf;
> + const u8 *start_cmd = slf3s_cmd_start_water;
> + const char *medium;
> + int ret;
> +
> + indio_dev = devm_iio_device_alloc(dev, sizeof(*sf));
> + if (!indio_dev)
> + return -ENOMEM;
> +
> + sf = iio_priv(indio_dev);
> + sf->client = client;
> + sf->variant = i2c_get_match_data(client);
> + crc8_populate_msb(sf->crc_table, SLF3S_CRC8_POLY);
> +
> + ret = devm_regulator_get_enable(dev, "vdd");
> + if (ret)
> + return dev_err_probe(dev, ret, "failed to enable vdd supply\n");
More than likely we need some level of sleep here for the device to wake up.
Is there anything in the datasheet?
> +
> + ret = slf3s_detect_variant(sf);
> + if (ret)
> + return dev_err_probe(dev, ret, "product info read failed\n");
> +
> +static const struct of_device_id slf3s_of_match[] = {
> + { .compatible = "sensirion,slf3s-0600f", .data = &slf3s_variants[0] },
> + { .compatible = "sensirion,slf3s-1300f", .data = &slf3s_variants[1] },
> + { .compatible = "sensirion,slf3s-4000b", .data = &slf3s_variants[2] },
> + { .compatible = "sensirion,slf3s" },
This came up in the dt review, so I'll assume you'll address it there. How useful
is the generic compatible?
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, slf3s_of_match);
> +
> +static struct i2c_driver slf3s_driver = {
> + .driver = {
> + .name = "slf3s",
> + .of_match_table = slf3s_of_match,
> + },
> + .probe = slf3s_probe,
> + .id_table = slf3s_id,
> +};
> +module_i2c_driver(slf3s_driver);
> +
> +MODULE_AUTHOR("Wadim Mueller <wafgo01@gmail.com>");
> +MODULE_DESCRIPTION("Sensirion SLF3S liquid flow sensor driver");
> +MODULE_LICENSE("GPL");
On Thu, 28 May 2026 12:22:44 +0100 Jonathan Cameron <jic23@kernel.org> wrote: Thanks for the review (and to Rodrigo for jumping in). Inline replies, will address all of it in v3. > Check these. I'd expect dev_printk.h for instance. > Follow IWYU (approximately) for includes. Will go through the includes and add the missing ones for what is used directly. > I don't think this [SLF3S_MEAS_LEN] constant being a define is > that useful. [...] use ARRAY_SIZE() for the loop Will move the literal to the buf declaration and use ARRAY_SIZE(buf). > I'd put this value [SLF3S_TEMP_SCALE_MILLIC] inline with the > comment. Will inline at the call site and drop the define. > Probably more readable with 600 * MICRO / 30 * MICRO / 1920 * MILLI Ack, will do. > I'd be consistent and have const u8 block[at_least 3] > [...] Use at_least, not static for kernel code Will switch both helpers to [at_least N]. > wrap at 80 chars Will reflow. > If this happens I'd go with the detection over the dt provided. > And dev_info for the mismatch [...] Will invert: detection wins, DT is fallback for unknown sub-type, mismatch goes to dev_info. > More than likely we need some level of sleep here for the device to > wake up. Is there anything in the datasheet? Yes, tPU = 25 ms max (time to sensor ready). Will add fsleep(25000) after the regulator enable. Also tw = 60 ms typ (warm-up until output within spec), so will bump the existing SLF3S_MEAS_START_DELAY_US from 12 ms to 60 ms. > How useful is the generic compatible? Will be dropped in v3 (agreed with Krzysztof in the binding thread). Also moving sensirion,medium out of DT into a sysfs attribute, since it's runtime config. > Sashiko (probably correctly) identifies that the formatting that the > IIO core does for an IIO_VAL_FRACTIONAL only goes to 9 decimal places. > [...] maybe switch to using IIO_VAL_DECIMAL64_PICO > +CC Rodrigo Confirmed, the SLF3S-0600F scale (~1.67e-9 l/s/LSB) gets truncated to 1 digit, the 1300F loses some precision too. I would prefer waiting for Rodrigo's IIO_VAL_DECIMAL64_PICO over bumping the FRACTIONAL formatter, since pico covers all variants and avoids changing core behaviour for everyone. Plan would be to send v3 with all other points addressed and respin to v4 once PICO is in mainline. Ok with you, or would you rather see the FRACTIONAL bump now? Thanks again, Wadim
> > Will go through the includes and add the missing ones for what is > used directly. General hint on process. Don't bother saying yes. Just delete those bits when replying so we can focus on the more interesting stuff: questions etc. > > > More than likely we need some level of sleep here for the device to > > wake up. Is there anything in the datasheet? > > Yes, tPU = 25 ms max (time to sensor ready). Will add > fsleep(25000) after the regulator enable. Also tw = 60 ms typ > (warm-up until output within spec), so will bump the existing > SLF3S_MEAS_START_DELAY_US from 12 ms to 60 ms. > > Sashiko (probably correctly) identifies that the formatting that the > > IIO core does for an IIO_VAL_FRACTIONAL only goes to 9 decimal places. > > [...] maybe switch to using IIO_VAL_DECIMAL64_PICO > > +CC Rodrigo > > Confirmed, the SLF3S-0600F scale (~1.67e-9 l/s/LSB) gets > truncated to 1 digit, the 1300F loses some precision too. > > I would prefer waiting for Rodrigo's IIO_VAL_DECIMAL64_PICO over > bumping the FRACTIONAL formatter, since pico covers all variants > and avoids changing core behaviour for everyone. Plan would be > to send v3 with all other points addressed and respin to v4 once > PICO is in mainline. Ok with you, or would you rather see the > FRACTIONAL bump now? PICO path seems the easier one, base on top of Rodrigo's series and add a note about the dependency. I have no idea what Sashiko will do with a list of dependent patches, so we may get some spurious suggestions that the code won't build etc like we currently get for scan_type.format Jonathan > > Thanks again, > Wadim
On 26/05/28 12:22PM, Jonathan Cameron wrote:
> On Wed, 27 May 2026 20:42:54 +0200
> Wadim Mueller <wafgo01@gmail.com> wrote:
>
> > Add a driver for the Sensirion SLF3S family of digital liquid-flow
> > sensors (SLF3S-0600F, SLF3S-1300F and SLF3S-4000B). The sensors
> > communicate over I2C and return a 16-bit signed flow value, a 16-bit
> > signed temperature reading and a status word - each protected by a
> > CRC-8 byte - in every measurement frame.
> >
> > The driver exposes:
> >
> > in_volumeflow_raw - signed raw counts
> > in_volumeflow_scale - litres per second per LSB (per variant)
> > in_temp_raw - signed raw counts
> > in_temp_scale - millidegrees Celsius per LSB
> >
> > The variant is auto-detected from the product-info word read at
> > probe time. All three SLF3S devices are factory-calibrated for both
> > water and isopropyl alcohol; the calibration medium is selected via
> > the sensirion,medium device property and defaults to water.
> >
> > Scale factors are taken from the respective datasheets (Table 16
> > for SLF3S-0600F, Table 15 for SLF3S-1300F and SLF3S-4000B):
> >
> > SLF3S-0600F: 10 (ul/min)^-1 -> 1/600 000 000 (l/s)/LSB
> > SLF3S-1300F: 500 (ml/min)^-1 -> 1/30 000 000 (l/s)/LSB
> > SLF3S-4000B: 32 (ml/min)^-1 -> 1/1 920 000 (l/s)/LSB
...
> > +static int slf3s_read_raw(struct iio_dev *indio_dev,
> > + struct iio_chan_spec const *chan, int *val,
> > + int *val2, long mask)
> > +{
> > + struct slf3s_data *sf = iio_priv(indio_dev);
> > + int flow, temp, ret;
> > +
> > + switch (mask) {
> > + case IIO_CHAN_INFO_RAW:
> > + if (!iio_device_claim_direct(indio_dev))
> > + return -EBUSY;
> > +
> > + ret = slf3s_read_sample(sf, &flow, &temp);
> > + iio_device_release_direct(indio_dev);
> > + if (ret)
> > + return ret;
> > +
> > + *val = (chan->type == IIO_VOLUMEFLOW) ? flow : temp;
> > + return IIO_VAL_INT;
> > + case IIO_CHAN_INFO_SCALE:
> > + if (chan->type == IIO_VOLUMEFLOW) {
> > + *val = sf->variant->scale_num;
> > + *val2 = sf->variant->scale_den;
>
> Sashiko (probably correctly) identifies that the formatting that the IIO core
> does for an IIO_VAL_FRACTIONAL only goes to 9 decimal places. That means
> in some cases the scale is truncated to 1 digit losing much of its usefulness.
> https://sashiko.dev/#/patchset/20260527184257.141635-1-wafgo01%40gmail.com
>
> As such we need to increase the number of digits or maybe switch to using
> https://lore.kernel.org/all/20260524-adf41513-iio-driver-v14-6-06824d9c15f4@analog.com/
>
> Which defines IIO_VAL_DECIMAL64_PICO
yes, pico would be enough, but IIO_VAL_DECIMAL64_FEMTO could also be defined if needed.
There will be a v15, then let me know if any changes are needed.
--
Kind regards,
Rodrigo Alencar
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
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
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
© 2016 - 2026 Red Hat, Inc.