linux-kernel - Re: [PATCH v6 2/8] ASoC: atmel: machine driver for at91sam9x5-wm8731 boards

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <51F98CBC.6000302@wwwdotorg.org>
Date:	Wed, 31 Jul 2013 16:16:28 -0600
From:	Stephen Warren <swarren@...dotorg.org>
To:	Mark Brown <broonie@...nel.org>
CC:	Richard Genoud <richard.genoud@...il.com>,
	Nicolas Ferre <nicolas.ferre@...el.com>,
	Liam Girdwood <lgirdwood@...il.com>,
	Bo Shen <voice.shen@...el.com>,
	Lars-Peter Clausen <lars@...afoo.de>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	alsa-devel@...a-project.org, devicetree@...r.kernel.org,
	patches@...nsource.wolfsonmicro.com
Subject: Re: [PATCH v6 2/8] ASoC: atmel: machine driver for at91sam9x5-wm8731
 boards

On 07/30/2013 04:58 PM, Mark Brown wrote:
> On Tue, Jul 30, 2013 at 03:29:17PM -0600, Stephen Warren wrote:
>> On 07/30/2013 02:45 PM, Mark Brown wrote:
> 
>>> You really shouldn't do this, it's not accomplishing much.
> 
>> What it accomplishes is not polluting the CODEC's binding with a
>> set of strings that must always be supported since DT is an ABI.
>> The strings are isolated into the specific audio complex binding,
>> which might possibly become deprecated and replaced with
>> something better and more generic.
> 
> You seem to be assuming that the strings are a bad thing.  I'm not
> sure that this is the case modulo the tooling issues...

I do tend to think that using strings is pretty evil...

> We could start adding the integers right now - something like:
> 
> The X CODEC has the following numbered input and output pins:
> 
> 1. HPOUTL 2. HPOUTR ...
> 
> (see datasheet for details), a header file is provided with 
> constants X_PIN_foo for convenience.
> 
> would work with either approach to identifying the pins or if
> we're being less verbose and just reference the header file for
> the definitions that becomes something like:
> 
> The X CODEC has input and output pins listed with numerical 
> identifiers in the form the X_PIN_foo defined in the X.h header 
> file where foo is the name of the pin.
> 
> (that's not good boilerplate wording but you get my drift) which
> still ends up defining a set of known strings for pins.
> 
> In fact now that I think about this why don't we just go ahead and
> do all this, starting by putting the numbers into the bindings for
> the CODECs since that's the simplest thing and doesn't involve
> writing code? I even have several boards on my desk that run DT
> ASoC...

I'm certainly fine with that compromise.
--
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/