linux-kernel - Re: [PATCH 5/6] ASoC: samsung: Extend Snow driver to support max98089

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: <CAD=FV=U1613Wv0Lyda_O80j6tTt2sPz++Z5cwzcjAQb=L-qkeA@mail.gmail.com>
Date:	Thu, 19 Feb 2015 11:01:57 -0800
From:	Doug Anderson <dianders@...omium.org>
To:	Andreas Färber <afaerber@...e.de>
Cc:	Mark Brown <broonie@...nel.org>,
	Sangbeom Kim <sbkim73@...sung.com>,
	alsa-devel@...a-project.org,
	linux-samsung-soc <linux-samsung-soc@...r.kernel.org>,
	Liam Girdwood <lgirdwood@...il.com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Vincent Palatin <vpalatin@...omium.org>,
	Javier Martinez Canillas <javier.martinez@...labora.co.uk>,
	Tomasz Figa <tomasz.figa@...il.com>,
	Kukjin Kim <kgene@...nel.org>,
	Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.de>,
	Olof Johansson <olof@...om.net>
Subject: Re: [PATCH 5/6] ASoC: samsung: Extend Snow driver to support max98089

Andreas,

On Thu, Feb 19, 2015 at 9:56 AM, Andreas Färber <afaerber@...e.de> wrote:
> Am 19.02.2015 um 18:44 schrieb Doug Anderson:
>> On Thu, Feb 19, 2015 at 1:44 AM, Mark Brown <broonie@...nel.org> wrote:
>>> On Wed, Feb 18, 2015 at 07:25:58PM +0100, Andreas Färber wrote:
>>>
>>>>  static const struct of_device_id snow_of_match[] = {
>>>> +     { .compatible = "google,snow-audio-max98089", },
>>>>       { .compatible = "google,snow-audio-max98090", },
>>>>       { .compatible = "google,snow-audio-max98091", },
>>>>       { .compatible = "google,snow-audio-max98095", },
>>>
>>> Since we completely ignore the CODEC in the property might it not be
>>> better to just add a plain old snow-audio compatible and bind to that,
>>> that way we don't need these driver updates?  Just the "snow" bit should
>>> be enough to know it's one of this class of machines.
>>
>> I think what you're suggesting is that here we should add a new
>> compatible string "google,snow-audio" instead of adding
>> "google,snow-audio-max98089" here.  Then the sound node in the spring
>> DTS would look like:
>>
>>   compatible = "google,snow-audio-max98089", "google,snow-audio";
>
> If we want to be specific just in case, was it an active decision not to
> use "google,peach-pi[t]-audio-max98..."?
>
> Again, either way works for me.

I don't think it was an active decision, but I am certainly nowhere
near an audio expert and I don't think I made that particular decision
(I could be wrong).

One could make the argument that "snow" describes the general hookup
style of the hardware and then you list the actual codec after that,
but that's a pretty weak argument...

-Doug
--
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/