linux-kernel - Re: [PATCH] ASoC: generic: add generic compound card with DT 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: <20131231124737.GT31886@sirena.org.uk>
Date:	Tue, 31 Dec 2013 12:47:37 +0000
From:	Mark Brown <broonie@...nel.org>
To:	Jean-Francois Moine <moinejf@...e.fr>
Cc:	Liam Girdwood <lgirdwood@...il.com>,
	Lars-Peter Clausen <lars@...afoo.de>,
	alsa-devel@...a-project.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ASoC: generic: add generic compound card with DT support

On Tue, Dec 31, 2013 at 01:36:10PM +0100, Jean-Francois Moine wrote:
> Mark Brown <broonie@...nel.org> wrote:

> > It would have been useful to have provided that feedback at the time
> > rather than waiting until after it had been merged - it was in review
> > for long enough.  It would also be good to articulate the issues with

> Sorry, I spent a lot of time on DPCM, and I was not yet ready to propose
> something when you accepted Kuninori's patch.

It'd still have been worthwhile to say that you weren't sure it'd work
even if you didn't have an alternative; you could perhaps have worked on
it together.

> > These are Linux-internal concepts which shouldn't appear in a DT binding
> > or at the very least need definition.  One thing to consider here is
> > that these things are all about the internals of a SoC and you'd
> > therefore expect that they would be defined separately from the card so
> > as to avoid having to replicate information in every card using a given
> > SoC.

> Do you mean that, as DPCM cannot be in the DT, there should be a
> specific driver for the Cubox audio card (Marvell Armada 510 + NXP HDMI
> transmitter)?

I'm not saying it can't be in the DT, I'm saying that this doesn't look
like the right way to do things.  For example we could have a way of
specifying parts of the card separately so the SoC can be referenced as
a whole by the card, or we could have the internals behind the DAI
hidden from the DT entirely so the DT just links the DAIs together and
the SoC internals come from the implementation of the DAI devices.

If you can't figure something out a more specific binding is fine, but
if you're trying to do a generic binding for everything then these
things need to be considered.

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