On 14/11/2022 08:45, Krzysztof Kozlowski wrote:
On 09/11/2022 17:53, Richard Fitzgerald wrote:
Codecs in this family have multiple digital and analog audio I/O that support a variety of external hardware connections and configurations.
Signed-off-by: Richard Fitzgerald rf@opensource.cirrus.com
.../bindings/sound/cirrus,cs48l32.yaml | 96 +++++++++++++++++++ include/dt-bindings/sound/cs48l32.h | 25 +++++ 2 files changed, 121 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/cirrus,cs48l32.yaml create mode 100644 include/dt-bindings/sound/cs48l32.h
diff --git a/Documentation/devicetree/bindings/sound/cirrus,cs48l32.yaml b/Documentation/devicetree/bindings/sound/cirrus,cs48l32.yaml new file mode 100644 index 000000000000..70fb294c6dc1 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/cirrus,cs48l32.yaml @@ -0,0 +1,96 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/cirrus,cs48l32.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml#
+title: Cirrus Logic CS48L31/32/33 audio CODECs
+maintainers:
- patches@opensource.cirrus.com
+description: |
- This describes audio configuration bindings for these codecs.
Don't start with "This". Instead describe the hardware.
- See also the core bindings for the parent MFD driver:
- Documentation/devicetree/bindings/mfd/cirrus,cs48l32.yaml
Same comment as for pinctrl patch.
- and defines for values used in these bindings:
- include/dt-bindings/sound/cs48l32.h
- The properties are all contained in the parent MFD node.
+properties:
Missing compatible. What's the point to organize bindings like that? The schema on its own does nothing - does not match anything.
Do you mean child drivers should not share the MFD node? Or do you mean that if they share the MFD node all the child driver bindings should be documented in the MFD schema instead of having a sub-schema for each class of hardware functionality?
I'm certainly willing to collapse all the bindings into a single MFD schema yaml. For this driver we followed the same structure that was accepted for madera (and there was some discussion when we upstreamed madera about how the bindings should be organized which resulted in them being changed). We pretty much assumed that the safe bet was to do the same that was accepted by the maintainer last time around.