Re: [PATCH 1/2] dt-bindings: iio: adc: add lltc,ltc2387

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] dt-bindings: iio: adc: conflicting uint32 type for adi,gain-milli
- [Medium] dt-bindings: iio: adc: lltc,ltc2387: undocumented synthetic -x4 compatibles
- [Low] dt-bindings: iio: adc: lltc,ltc2387: example indentation and property order
--

commit 3bc833c852704e956c19734cf54a047dca662012
Author: Sergiu Cuciurean <sergiu.cuciurean@analog.com>

dt-bindings: iio: adc: add lltc,ltc2387

This commit adds devicetree bindings for the Linear Technology LTC2387-16
and LTC2387-18 SAR ADCs as well as the Analog Devices ADAQ23875, ADAQ23876,
and ADAQ23878 uModule ADCs.

> diff --git a/Documentation/devicetree/bindings/iio/adc/lltc,ltc2387.yaml b/Documentation/devicetree/bindings/iio/adc/lltc,ltc2387.yaml
> new file mode 100644
> index 0000000000000..f912260c8f790
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/lltc,ltc2387.yaml
> @@ -0,0 +1,138 @@

[ ... ]

> +properties:
> +  compatible:
> +    enum:
> +      - adi,adaq23875
> +      - adi,adaq23876
> +      - adi,adaq23878
> +      - lltc,ltc2387-16
> +      - lltc,ltc2387-16-x4
> +      - lltc,ltc2387-18
> +      - lltc,ltc2387-18-x4

[Severity: Medium]
Are lltc,ltc2387-16-x4 and lltc,ltc2387-18-x4 actual IC part numbers, or do
they represent a board/FPGA topology where four discrete LTC2387 chips share
conversion and clock signals and have their samples packed together by an AXI
ADC core?

The LTC2387-16 and LTC2387-18 are single-channel SAR ADCs, and neither the
commit message nor the binding description documents these -x4 compatible
strings. Should multi-chip board or FPGA topologies be described using
standard devicetree properties rather than encoding a chip count into
synthetic compatible strings?

[ ... ]

> +  adi,gain-milli:
> +    description:
> +      Gain of the fully-differential amplifier that the ADAQ2387x modules
> +      integrate ahead of the LTC2387 die, expressed as gain * 1000. It is
> +      fixed on the ADAQ23875 and set by pin strapping on the ADAQ23876 and
> +      ADAQ23878, so it must match the board. The bare ltc2387-* parts have
> +      no amplifier.
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    enum: [370, 730, 870, 1380, 2000, 2250]

[Severity: Medium]
Does defining adi,gain-milli with $ref: /schemas/types.yaml#/definitions/uint32
cause a property type conflict with existing Analog Devices ADC bindings?

In Documentation/devicetree/bindings/iio/adc/adi,ad4000.yaml and
Documentation/devicetree/bindings/iio/adc/adi,ad7380.yaml, adi,gain-milli is
already defined as uint16:

  adi,gain-milli:
    ...
    $ref: /schemas/types.yaml#/definitions/uint16

Because vendor properties share a global type namespace across schemas in
dtschema, shouldn't adi,gain-milli use /schemas/types.yaml#/definitions/uint16
here (and /bits/ 16 <870> in the example below) to avoid a dt_binding_check
conflict and keep the devicetree ABI consistent across ADI ADC bindings?

[ ... ]

> +examples:
> +  - |
> +    adc {
> +            compatible = "lltc,ltc2387-16";
> +            clocks = <&clk 0>;
> +            io-backends = <&axi_adc>;
> +            pwms = <&pwm 0 0>, <&pwm 1 0>;
> +            pwm-names = "cnv", "clk_gate";
> +            vref-supply = <&vref>;
> +    };
> +  - |
> +    adc {
> +            compatible = "adi,adaq23878";
> +            clocks = <&clk 0>;
> +            io-backends = <&axi_adc>;
> +            pwms = <&pwm 0 0>, <&pwm 1 0>;
> +            pwm-names = "cnv", "clk_gate";
> +            vref-supply = <&vref>;
> +            adi,use-two-lanes;
> +            adi,gain-milli = <870>;
> +    };

[Severity: Low]
This isn't a bug, but both examples indent the properties inside the adc node
by 8 spaces instead of 4 spaces, and the second example places
adi,use-two-lanes before adi,gain-milli instead of in alphabetical order
within the vendor-specific property group, which triggers warnings from
scripts/dtc/dt-check-style --mode=strict.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261027134409.76824-1-Nicolae-daniel.Deaconescu@analog.com?part=1