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]

Message-ID: <20180219130514.GC32761@sirena.org.uk>
Date:   Mon, 19 Feb 2018 13:05:14 +0000
From:   Mark Brown <broonie@...nel.org>
To:     Tony Lindgren <tony@...mide.com>
Cc:     Sebastian Reichel <sebastian.reichel@...labora.co.uk>,
        Liam Girdwood <lgirdwood@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        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

On Fri, Feb 16, 2018 at 07:57:07AM -0800, Tony Lindgren wrote:
> * Mark Brown <broonie@...nel.org> [180216 15:17]:

> > It's not just other operating systems, it's also other versions of
> > Linux we have to think about here.  The most obvious issue with audio is
> > the clocking where the division between ASoC and clock APIs is not super
> > obvious and could easily change in the future.

> Yeah let's stick to describing how the hardware is wired in the
> dts files. In this case it's really only the routing to the SoC,
> right?

The SoC and anything else on the board like external amps and so on.

> One advantage of using a compatible property for the pmic subdevices
> though is that it leaves out a dependency between various device
> drivers things happen automagically. The mfd core driver can be
> minimal and just implement interrupt handling and regmap. So no need
> to to parse the child nodes in the pmic mfd driver :)

There's no need to do that anyway - with a MFD the child devices can
assume that they're part of the MFD and reference their parent.

> So personally I'd prefer the option that requires least amount
> of custom code if compatible vs no compatible property is the
> only issue here.

It's a few lines of code to register the child devices from code rather
than the DT, and keeps it out of the ABI.

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