linux-kernel - Re: [PATCHv5 3/5] mfd: motorola-cpcap: Add audio-codec support

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: <20180309124017.GB5252@sirena.org.uk>
Date:   Fri, 9 Mar 2018 12:40:17 +0000
From:   Mark Brown <broonie@...nel.org>
To:     Lee Jones <lee.jones@...aro.org>
Cc:     Sebastian Reichel <sebastian.reichel@...labora.co.uk>,
        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, kernel@...labora.com
Subject: Re: [PATCHv5 3/5] mfd: motorola-cpcap: Add audio-codec support

On Fri, Mar 09, 2018 at 08:34:14AM +0000, Lee Jones wrote:
> On Thu, 08 Mar 2018, Mark Brown wrote:

> > Linux.  Clocks are a big issue with audio stuff, right now sections of
> > the clock tree get handled in the CODEC driver but we're going to want
> > to push them out to a clock driver so we're not reimplementing handling
> > for clocks.

> How is the CODEC controlled?  Does it have its own registers?  I guess
> by "it's not a separate device or IP" you mean that it doesn't.  But
> that begs the question, how does this then device differ from all the
> other devices (adc, battery, charger, regulator, rtc, pwrbutton,
> usb-phy and led)?

I'm not convinced that this is a particularly good idea for the other
functions but anyway...  the big thing here is that in these devices the
CODEC is generally not the level that the IP is created at, it's a
collection of interlinked IPs which usually includes not only audio
stuff but also some clocking stuff.  The repeatable blocks that could
get reused independently are generally a level down from the CODEC
level, for example if you look at something like wm8994 there's a couple
of identical FLL IPs which could make sense to enumerate individually in
the DT.  The top level generally doesn't get reused and is purely an
encoding of what Linux is currently doing.

Regulators have a bit of this going on as well - you can see it in the
wm831x series of drivers where the devices have a bunch of consistently
defined regulators that are laid out in various configurations so we
have one platform device per physical regulator (not sure if that ever
got converted to DT).

Most of the other things you list are more at the level of the FLL where
it's a single thing doing a single task that is likely to be repeated
somewhere else as a block so there's more sense, though how often that
actually happens can be questionable.

> I'm asking, not to be awkward, but to avoid 50 lines of potentially
> unnecessary static code.  If this is a real (sub-)device, even if it's
> part of a larger, single device (MFD) then there is no reason why it
> can't be represented as a single, albeit empty node.

It never used to be that complicated to define MFD functions?  It was a
data table and then a function call to register the table en masse.
Certainly not anything it's worth defining an ABI to avoid.

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