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

[sashiko-bot@kernel.org]

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