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@xxxxxxxxxxxxxxxxxxxxx>
---
.../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@xxxxxxxxxxxxxxxxxxxxx
+
+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.
