linux-kernel - Re: [PATCH v4 1/1] ASoc: kirkwood: add DT support to the mvebu audio subsystem

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: <20130809194434.GP6427@sirena.org.uk>
Date:	Fri, 9 Aug 2013 20:44:34 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
	Jean-Francois Moine <moinejf@...e.fr>,
	Liam Girdwood <lgirdwood@...il.com>,
	Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.de>,
	Rob Herring <rob.herring@...xeda.com>,
	alsa-devel@...a-project.org, linux-kernel@...r.kernel.org,
	devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v4 1/1] ASoc: kirkwood: add DT support to the mvebu audio
 subsystem

On Fri, Aug 09, 2013 at 07:25:16PM +0100, Russell King - ARM Linux wrote:

> Sigh, you completely miss the point.

> What all three of us are ultimately after is a DT description for the
> kirkwood stuff which covers all its use cases.  The use case which all
> three of us have in common is the Cubox, which is the one which needs
> the spdif stuff to work.

I think I get what needs to be done well enough, I'm not sure that
matches up with what people are wanting the results to look like but
that's another story.

> Now, what you've said to date is:

> 1. you want kirkwood to use DPCM.

Yes.

> 2. you want kirkwood using people to use the simple card stuff with the
>    kirkwood driver you want to use DPCM.

No.  What I'm saying is that if your end goal is a binding for cards
that works for absolutely anything then it should be handled by the
simple card driver since that's what it's there for.   There's no
requirement to do things that way though, certainly not in a first pass.

> To make it work with DPCM, we first need to know what DPCM requires,
> which means we either have to have the knowledge of DPCM and/or have a
> working implementation.  We don't have either of those yet.

> So, I again state plainly that what you're asking is for people to come
> up with a DT description for a DPCM implementation when we haven't yet
> got a working DPCM implementation, even without DT.

> It is this which I assert is a completely rediculous request at this
> moment in time for the reasons stated in my previous email and repeated
> in this email.

I'm not sure I said that anyone need do anything right this very minute?  

In any case since the binding that pulls everything together into the
audio subsystem is supposed to be separate to the bindings for the
bindings for individual components it should be possible to proceed with
those if someone wants to do that (as in the patch under discussion) and
add the bits to tie things together later.

If someone wants to it should also be possible to convert the existing
platforms without S/PDIF support over to DT, providing you don't mind
changing the code once the DPCM and S/PDIF support is added and a bit of
thought is put into where the S/PDIF output will fit into the bindings.
Since DPCM is a Linux internal thing it shouldn't have any impact on the
bindings.

But like I say there's no need to do anything in particular immediately.
The patch under discussion seems basically fine for what it covers,
modulo the fairly minor things Sebastian identified, and can be built on
later.

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