Devicetree
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Wadim Mueller <wafgo01@gmail.com>
Cc: krzk+dt@kernel.org, robh@kernel.org, conor+dt@kernel.org,
	dlechner@baylibre.com, nuno.sa@analog.com, andy@kernel.org,
	maxwell@maxwelld.cc, linux-iio@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	marcelo.schmitt1@gmail.com, 455.rodrigo.alencar@gmail.com
Subject: Re: [PATCH v6 0/4] iio: flow: Sensirion SLF3S liquid flow sensor
Date: Sun, 2 Aug 2026 00:50:42 +0100	[thread overview]
Message-ID: <20260802005042.2352936e@jic23-huawei> (raw)
In-Reply-To: <20260728214943.29820-1-wafgo01@gmail.com>

On Tue, 28 Jul 2026 23:49:39 +0200
Wadim Mueller <wafgo01@gmail.com> wrote:

> Hi all,
> 
> this series adds a driver for the Sensirion SLF3S family of I2C liquid
> flow sensors (SLF3S-0600F / -1300F / -4000B) and a new IIO_VOLUMEFLOW
> channel type.

I'm going to apply this now, but as it will be in my testing branch (which
I do rebase) for a few days fully welcome any additional comments or
tags.

Applied to the testing branch of iio.git

Thanks,

Jonathan
> 
> First of all: sorry for the noise.  Patch 4/4 of v5 never made it to the
> list or to patchwork - it got lost on the way out from the machine I sent
> v5 from, as Jonathan noticed:
> 
>   https://lore.kernel.org/linux-iio/20260720032927.14fc4f9f@jic23-huawei/
> 
> So this v6 is mostly a resend of v5 with the driver patch actually
> included, plus the binding change we converged on in the meantime.  The
> driver changes that were listed in the v5 changelog are repeated below,
> since nobody got to see them.
> 
> The series is based on iio.git testing, which already contains Rodrigo
> Alencar's IIO_VAL_DECIMAL64_* core formatting work; patch 3/4 adds the
> IIO_VAL_DECIMAL64_FEMTO format type on top of it.
> 
> Changes since v5
> ----------------
>   * 4/4 is included this time - v5 only had 1-3 on the list
>   * dt-bindings: dropped the fallback compatible entirely; each variant
>     now has its own compatible, per the conclusion of the v4 discussion
>     between Krzysztof and Jonathan.  Since the driver has to look at the
>     product-information register anyway, a fallback buys nothing, while
>     separate compatibles let a future drop-in part claim a known
>     compatible and work on older kernels
>   * dt-bindings: dropped Krzysztof's Reviewed-by, since the compatible
>     schema changed
>   * dt-bindings: commit message and example updated accordingly
>   * driver: reworded the slf3s_detect_variant() comment and the commit
>     message, which referred to the now-gone fallback compatible.  The
>     behaviour is unchanged: an unknown sub-type still falls back to the
>     variant named in the device tree / I2C table
>   * rebased onto current iio.git testing
> 
> Changes since v4 (from the v5 posting, repeated because 4/4 was lost)
> ---------------------------------------------------------------------
>   * driver: include err.h for PTR_ERR() and math.h for struct s32_fract,
>     per Andy
>   * driver: fold the per-variant scale_num/scale_den pair into a
>     struct s32_fract, per Andy
>   * driver: add enum slf3s_variant_id and use it for the variant table
>     and the I2C/OF match tables instead of bare indices, per Andy
>   * driver: slf3s_send_cmd(): drop the "at_least 2" parameter
>     annotation, decouple the ret assignment from its declaration and
>     check errors first, per Andy
>   * driver: use sizeof() instead of ARRAY_SIZE() for the measurement
>     byte buffer, per Andy
>   * driver: parenthesise the (FEMTO / MILLI) factor so it folds into a
>     single constant multiplication, per Andy
>   * driver: derive the temperature scale from MILLIDEGREE_PER_DEGREE
>     instead of a bare 1000, per Andy
>   * driver: checked the struct slf3s_data layout (re Andy's pahole
>     question): the non-pointer members total 260 bytes, so one 4-byte
>     hole remains for any member order; left as is
>   * driver: drop the inline comment on the mutex that duplicated the
>     kernel-doc, per Jonathan (checkpatch still moans about it)
>   * driver: fix the duplicated argument in the DT/sensor variant
>     mismatch dev_info(), per Jonathan
>   * driver: reformat the i2c_device_id/of_device_id tables to one
>     member per line, per Jonathan
>   * MAINTAINERS: updated Maxwell's address in the R: entry to
>     maxwell@maxwelld.cc, as he requested on the v4 thread
> 
> The signaling-flags word (air-in-line / high-flow / smoothing status) in
> each measurement frame is intentionally not read; exposing it can be a
> later follow-up.
> 
> v5: https://lore.kernel.org/linux-iio/20260714085358.20842-1-wafgo01@gmail.com/
> v4: https://lore.kernel.org/linux-iio/20260611132700.671322-1-wafgo01@gmail.com/
> 
> Thanks,
> Wadim
> 
> Wadim Mueller (4):
>   iio: types: add IIO_VOLUMEFLOW channel type
>   dt-bindings: iio: flow: add Sensirion SLF3S liquid flow sensor
>   iio: core: add IIO_VAL_DECIMAL64_FEMTO format type
>   iio: flow: add Sensirion SLF3S liquid flow sensor driver
> 
>  Documentation/ABI/testing/sysfs-bus-iio       |  11 +
>  Documentation/ABI/testing/sysfs-bus-iio-flow  |  21 +
>  .../bindings/iio/flow/sensirion,slf3s.yaml    |  55 ++
>  MAINTAINERS                                   |   8 +
>  drivers/iio/Kconfig                           |   1 +
>  drivers/iio/Makefile                          |   1 +
>  drivers/iio/flow/Kconfig                      |  22 +
>  drivers/iio/flow/Makefile                     |   7 +
>  drivers/iio/flow/slf3s.c                      | 543 ++++++++++++++++++
>  drivers/iio/industrialio-core.c               |   3 +
>  include/linux/iio/types.h                     |   1 +
>  include/uapi/linux/iio/types.h                |   1 +
>  tools/iio/iio_event_monitor.c                 |   2 +
>  13 files changed, 676 insertions(+)
>  create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-flow
>  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
> 
> 
> base-commit: e0484d62e8e1cff75b210938be835ea6221bda59


      parent reply	other threads:[~2026-08-01 23:50 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-28 21:49 [PATCH v6 0/4] iio: flow: Sensirion SLF3S liquid flow sensor Wadim Mueller
2026-07-28 21:49 ` [PATCH v6 1/4] iio: types: add IIO_VOLUMEFLOW channel type Wadim Mueller
2026-07-28 21:49 ` [PATCH v6 2/4] dt-bindings: iio: flow: add Sensirion SLF3S liquid flow sensor Wadim Mueller
2026-07-28 21:55   ` sashiko-bot
2026-08-01 23:46   ` Jonathan Cameron
2026-07-28 21:49 ` [PATCH v6 3/4] iio: core: add IIO_VAL_DECIMAL64_FEMTO format type Wadim Mueller
2026-07-28 21:49 ` [PATCH v6 4/4] iio: flow: add Sensirion SLF3S liquid flow sensor driver Wadim Mueller
2026-07-29 12:21   ` Uwe Kleine-König
2026-08-02  0:04     ` Jonathan Cameron
2026-08-01 23:50 ` Jonathan Cameron [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260802005042.2352936e@jic23-huawei \
    --to=jic23@kernel.org \
    --cc=455.rodrigo.alencar@gmail.com \
    --cc=andy@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dlechner@baylibre.com \
    --cc=krzk+dt@kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcelo.schmitt1@gmail.com \
    --cc=maxwell@maxwelld.cc \
    --cc=nuno.sa@analog.com \
    --cc=robh@kernel.org \
    --cc=wafgo01@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox