linux-kernel - Re: [PATCH 20/21] ASoC: codecs: Enable AB8500 CODEC for Device Tree

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: <50116005.6050008@linaro.org>
Date:	Thu, 26 Jul 2012 16:19:33 +0100
From:	Lee Jones <lee.jones@...aro.org>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
CC:	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	STEricsson_nomadik_linux@...t.st.com, linus.walleij@...ricsson.com,
	arnd@...db.de, sameo@...ux.intel.com, olalilja@...oo.se,
	ola.o.lilja@...ricsson.com, alsa-devel@...a-project.org, lrg@...com
Subject: Re: [PATCH 20/21] ASoC: codecs: Enable AB8500 CODEC for Device Tree

On 26/07/12 15:43, Mark Brown wrote:
> On Thu, Jul 26, 2012 at 03:15:01PM +0100, Lee Jones wrote:
>> Sorry missed this:
>
>>> Why are we doing this?  The MFD cells are a totally Linux specific
>>> thing, there's no reason to represent them in the device tree unless
>>> they're in some way reusable and the "ab8500-codec" name suggests that's
>>> unlikely.  Just put the properties on the parent node and instantiate
>>> the MFD cell as normal.
>
>> We have all of the AB8500 devices into the Device Tree to accurately
>> represent the hardware. We will also be passing configuration
>> information into the AB8500 Codec from Device Tree. The only reason
>> we're still registering them using the MFD API is to overcome
>> addressing issues encountered earlier. Each 'device' still belongs
>> in the 'device' tree.
>
> The device here is the AB8500.  The fact that Linux chooses to represent
> it as an MFD with a particular set of subdrivers is a Linux specific
> decision and may well change over time.  For example it's likely that
> we'll want to migrate the clocks out of the audio driver and into the
> clock API when that becomes useful.  Similarly currently a lot of these
> devices use ASoC level jack detection but that's going to move over to
> extcon over time.
>
> There's no way you're going to be able to reuse this for anything that
> isn't an AB8500, there's no abstraction of the SoC integration here.  If
> you had clearly identifiable, repeatable IPs which you could reasonably
> bind to a different bit of silicon then that'd be different but there's
> nothing like that here.  We already know that the functionality covered
> by the driver is going to be present simply by virtue of knowing that
> there's an AB8500 and similarly there's no real way this driver could
> ever be used without the core driver.  All the "device" in the device
> tree is doing is serving as a container to place some of the DT
> properties into, this needs to be separated out from the instantiation
> of the Linux device driver.  There's nothing stopping the driver from
> looking at the OF node of its parent here.
>
> The goal here isn't just to copy the Linux device model and platform
> data into device tree bindings, the device tree bindings need to think
> about what the chip actually is so they can be reused by other OSs and
> by future versions of Linux.
>
>> If we were to take this Device Tree and use it on something
>> non-Linux, that OS will still need to know about each of the AB8500
>> devices and every associated configuration option. Only in Linux do
>> we continue to register them though a different API, which doesn't
>> affect any other OS.
>
> Another OS might have a different idea about how it's going to split up
> the chip which better fits with the models which that OS has for the
> functions present on the device.  The reason this is a distinct device
> in Linux is all to do with how Linux models the hardware.

Okay, so your suggestion is to strip out all of the sub-devices under 
the AB8500. It's doable, but will take some restructuring and thinking 
about. This is a job for another day. I think it's okay to continue with 
the current semantics for the time-being. The line we're discussing does 
need to be split out though. I didn't mean to merge it in with the ASoC 
stuff.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/