On 14/11/2022 12:00, Richard Fitzgerald wrote: > 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 mean, that regular binding has a compatible which allows the schema to be matched. Splitting parts from top-level properties is used only for re-usable shared/common schemas, which does not seem the case here. > > 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. Just merge it with MFD binding. Best regards, Krzysztof
