Re: [PATCH 1/4] dt-bindings: sound: Add simple-iio-aux

[Rob Herring <robh@kernel.org>]

On Fri, Apr 21, 2023 at 02:41:19PM +0200, Herve Codina wrote:
> Industrial I/O devices can be present in the audio path.
> These devices needs to be viewed as audio components in order to be
> fully integrated in the audio path.
> 
> simple-iio-aux allows to consider these Industrial I/O devices as
> auxliary audio devices.

What makes it simple? Any binding called simple or generic is a trigger 
for me. Best to avoid those terms. :)

Examples of devices would be useful here.

> 
> Signed-off-by: Herve Codina <herve.codina@bootlin.com>
> ---
>  .../bindings/sound/simple-iio-aux.yaml        | 65 +++++++++++++++++++
>  1 file changed, 65 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/sound/simple-iio-aux.yaml
> 
> diff --git a/Documentation/devicetree/bindings/sound/simple-iio-aux.yaml b/Documentation/devicetree/bindings/sound/simple-iio-aux.yaml
> new file mode 100644
> index 000000000000..fab128fce4fc
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/simple-iio-aux.yaml
> @@ -0,0 +1,65 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/sound/simple-iio-aux.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Simple IIO auxiliary
> +
> +maintainers:
> +  - Herve Codina <herve.codina@bootlin.com>
> +
> +description: |

Don't need '|'

> +  Auxiliary device based on Industrial I/O device channels
> +
> +allOf:
> +  - $ref: /schemas/iio/iio-consumer.yaml

You don't need to reference consumer schemas.

> +  - $ref: dai-common.yaml#
> +
> +properties:
> +  compatible:
> +    const: simple-iio-aux
> +
> +  io-channels:
> +    description:
> +      Industrial I/O device channels used
> +
> +  io-channel-names:
> +    description:
> +      Industrial I/O channel names related to io-channels.
> +      These names are used to provides sound controls, widgets and routes names.
> +
> +  invert:

Property names should globally only have 1 type definition. This is 
generic enough I'd be concerned that's not the case.

> +    $ref: /schemas/types.yaml#/definitions/uint32-array
> +    description: |
> +      A list of 0/1 flags defining whether or not the related channel is
> +      inverted
> +    items:
> +      enum: [0, 1]
> +      default: 0
> +      description: |
> +        Invert the sound control value compared to the IIO channel raw value.
> +          - 1: The related sound control value is inverted meaning that the
> +               minimum sound control value correspond to the maximum IIO channel
> +               raw value and the maximum sound control value correspond to the
> +               minimum IIO channel raw value.
> +          - 0: The related sound control value is not inverted meaning that the
> +               minimum (resp maximum) sound control value correspond to the
> +               minimum (resp maximum) IIO channel raw value.
> +
> +required:
> +  - compatible
> +  - io-channels
> +  - io-channel-names
> +
> +unevaluatedProperties: false
> +
> +examples:
> +  - |
> +    aux {
> +        compatible = "simple-iio-aux";
> +        io-channels = <&iio 0>, <&iio 1>, <&iio 2>, <&iio 3>;
> +        io-channel-names = "CH0", "CH1", "CH2", "CH3";

Not really useful names. Do you have a real example?

> +        /* Invert CH1 and CH2 */
> +        invert = <0 1 1>;

IMO, invert should be same length as io-channels.

> +    };

How do support multiple instances? Say you have 2 sound cards (or 1 
sound card with multiple audio paths) each with different sets of IIO 
channels associated with it. You'd need a link to each 'aux' node. Why 
not just add io-channels to the sound card nodes directly? That's 
already just a virtual, top-level container node grouping all the 
components. I don't see why we need another virtual node grouping a 
subset of them.

Rob