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: <20180309111938.irzwypdehuckx35s@earth.universe>
Date:   Fri, 9 Mar 2018 12:19:38 +0100
From:   Sebastian Reichel <sebastian.reichel@...labora.co.uk>
To:     Lee Jones <lee.jones@...aro.org>
Cc:     Mark Brown <broonie@...nel.org>,
        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:
> 
> > On Thu, Mar 08, 2018 at 10:48:31AM +0000, Lee Jones wrote:
> > > On Thu, 08 Mar 2018, Sebastian Reichel wrote:
> > 
> > > > I had it in PATCHv1-PATCHv4. It was removed, since Mark didn't want
> > > > to have it in the DT ABI.
> > 
> > > Right, but why?  Is it not a hardware device?  I think converting from
> > > devm_of_platform_populate() for one sub-device is a bit drastic.
> > 
> > It's not a separate physical device or IP and doesn't exist outside of
> > the MFD, it's just how Linux is currently choosing to divide up the chip
> > right now but that's totally open to change even in future versions of
> > 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)?

The audio codec goes from register 0x0800 - 0x0844, with the next
register being defined @ 0x0a00. So it definetly has its own register
range. I should note though, that 0x0800 is the audio regulator
control. In Linux we handle this one in the regulator driver instead
of in the audio driver. But this is mostly hidden in DT (the voltage
ranges for VAUDIO are described in the regulator node now).

> 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.

We still have the node, so that it can be used with the ASoC graph
binding. It just has no compatible value. Instead it is identified
by the node's name.

-- Sebastian

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ