linux-kernel - Re: [PATCHv4 1/4] dt-bindings: sound: add motorola,cpcap-audio-codec

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]

Date:   Fri, 16 Feb 2018 14:25:38 +0100
From:   Sebastian Reichel <sebastian.reichel@...labora.co.uk>
To:     Mark Brown <broonie@...nel.org>
Cc:     Liam Girdwood <lgirdwood@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        Tony Lindgren <tony@...mide.com>,
        Jaroslav Kysela <perex@...ex.cz>,
        Takashi Iwai <tiwai@...e.com>, alsa-devel@...a-project.org,
        linux-omap@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCHv4 1/4] dt-bindings: sound: add motorola,cpcap-audio-codec

Hi Mark,

On Fri, Feb 16, 2018 at 11:30:08AM +0000, Mark Brown wrote:
> On Wed, Feb 14, 2018 at 11:07:38PM +0100, Sebastian Reichel wrote:
> 
> > +&cpcap {
> > +	audio-codec {
> > +		compatible = "motorola,cpcap-audio-codec";
> > +	};
> 
> Why are we adding a separate DT node with no content for this?  This is
> a single chip, we already know that the CODEC part is there from the DT
> telling us that the chip is there and what we decide is part of the
> CODEC is going to depend on what the OS running on the system is doing.

While it looks empty in the DT binding file, it's actually not empty
once some standard properties are added to support audio-graph-card.
A real world example looks like this:

&cpcap {
    audio-codec {
        compatible = "motorola,cpcap-audio-codec";
        #sound-dai-cells = <1>;

        port@0 {
            cpcap_audio_codec0: endpoint {
                remote-endpoint = <&cpu_dai2>;
            };
        };

        port@1 {
            cpcap_audio_codec1: endpoint {
                remote-endpoint = <&cpu_dai3>;
            };
       };
    };
};

Having all of this directly in the cpcap node doesn't look like
an improvement for any OS. Once there is a node it makes sense
to add a compatible IMHO. As a side effect this also avoids having
special handling for the audio codec. This is the last missing
sub-component, see arch/arm/boot/dts/motorola-cpcap-mapphone.dtsi

-- Sebastian

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)