lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3de10398-6521-4c8a-9af1-e8d15421b963@baylibre.com>
Date: Fri, 11 Jul 2025 12:43:09 -0500
From: David Lechner <dlechner@...libre.com>
To: Antoniu Miclaus <antoniu.miclaus@...log.com>, jic23@...nel.org,
 robh@...nel.org, conor+dt@...nel.org, devicetree@...r.kernel.org,
 linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] dt-bindings: iio: adc: add ade9000

On 7/11/25 8:02 AM, Antoniu Miclaus wrote:
> Add devicetree bindings support for ade9000.
> 
> Signed-off-by: Antoniu Miclaus <antoniu.miclaus@...log.com>
> ---
>  .../bindings/iio/adc/adi,ade9000.yaml         | 157 ++++++++++++++++++
>  1 file changed, 157 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iio/adc/adi,ade9000.yaml
> 
> diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ade9000.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ade9000.yaml
> new file mode 100644
> index 000000000000..660dca4ea9b5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/adi,ade9000.yaml
> @@ -0,0 +1,157 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +# Copyright 2025 Analog Devices Inc.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/bindings/iio/adc/adi,ade9000.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Analog Devices ADE9000 High Performance, Polyphase Energy Metering driver
> +
> +maintainers:
> +  - Antoniu Miclaus <antoniu.miclaus@...log.com>
> +
> +description: |
> +  The ADE9000 s a highly accurate, fully integrated, multiphase energy and power
> +  quality monitoring device. Superior analog performance and a digital signal
> +  processing (DSP) core enable accurate energy monitoring over a wide dynamic
> +  range. An integrated high end reference ensures low drift over temperature
> +  with a combined drift of less than ±25 ppm/°C maximum for the entire channel
> +  including a programmable gain amplifier (PGA) and an analog-to- digital
> +  converter (ADC).
> +
> +  https://www.analog.com/media/en/technical-documentation/data-sheets/ADE9000.pdf
> +
> +properties:
> +  compatible:
> +    enum:
> +      - adi,ade9000
> +
> +  reg:
> +    maxItems: 1
> +
> +  '#address-cells':
> +    const: 1
> +
> +  '#size-cells':
> +    const: 0
> +
> +  spi-max-frequency:
> +    maximum: 20000000
> +
> +  interrupts:
> +    maxItems: 2

Let's keep this together with interrupt-names.

> +
> +  reset-gpios:
> +    description: |
> +      Must be the device tree identifier of the RESET pin. As the line is
> +      active low, it should be marked GPIO_ACTIVE_LOW.
> +    maxItems: 1
> +
> +  interrupt-names:
> +    items:
> +      - const: irq0
> +      - const: irq1

The C4/EVENT/DREADY pins can also be an output and would make sense
as a 3rd interrupt.

> +
> +  adi,wf-cap-en:
> +    description: Enable fixed data rate for waveform buffer instead of resampled data
> +    type: boolean

This one sounds like a runtime setting depending on how you want to
configure sampling.

> +
> +  adi,wf-mode:
> +    description: |
> +      Waveform buffer filling and trigger mode.
> +      0 - Stop when waveform buffer is full
> +      1 - Continuous fill, stop only on enabled trigger events
> +      2 - Continuous filling, center capture around enabled trigger events
> +      3 - Streaming mode
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    enum: [0, 1, 2, 3]

This one sounds like something that would be determined by how
a buffered read is setup in the IIO driver, not something that
should be in the devicetree.

> +
> +  adi,wf-src:
> +    description: |
> +      Waveform buffer data source selection.
> +      0 - Sinc4 output, at 16 kSPS
> +      1 - Reserved
> +      2 - Sinc4 + IIR LPF output, at 4 kSPS
> +      3 - Current and voltage channel waveform samples, processed by the DSP at 4 kSPS
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    enum: [0, 2, 3]

There is a standard filter_type attribute that should be used
for selecting the filter type rather than hard-coding it in the
devicetree.

> +
> +  adi,wf-in-en:
> +    description: Enable IN waveform samples readout from waveform buffer
> +    type: boolean

This one also sounds like something that would be configured based
on how a scan is setup at runtime.

> +
> +  adi,egy-time:
> +    description: Energy accumulation time setting for energy registers
> +    $ref: /schemas/types.yaml#/definitions/uint32

And another one that sounds like it would be more of a runtime
setting based on what type of data capture you are setting up.

> +

Power and reference voltage supplies are missing.

ref-supply, vdd-supply

And there is a clock input and a clock output that we could
add trivial bindings for.


> +required:
> +  - compatible
> +  - reg
> +  - reset-gpios
> +  - interrupts
> +  - interrupt-names
> +  - adi,wf-mode
> +  - adi,wf-src
> +
> +additionalProperties: false
> +
> +patternProperties:
> +  "^phase@[0-2]$":
> +    type: object
> +    description: |
> +      Represents the external phases which are externally connected. Each phase
> +      has a current, voltage and power component
> +
> +    properties:
> +      reg:
> +        description: |
> +          The phase represented by a number
> +          0 - Phase A
> +          1 - Phase B
> +          2 - Phase C
> +        $ref: /schemas/types.yaml#/definitions/uint32
> +        enum: [0, 1, 2]

If we are calling this an ADC, we should be using adc.yaml and
calling these channel@ rather than phase@. There could be a custom
adi,phase property for each channel if needed. But I'm guessing
IAP/IAN is always going to be phase A, IBP/IBN is always going to
be phase B, etc. so I'm not sure we actually need any special channel
properties at this point.

> +
> +    required:
> +      - reg
> +
> +    additionalProperties: false
> +

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ