linux-kernel - Re: [PATCH v5] ASoC: rockchip: Add machine driver for RK3399 GRU 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAL_JsqKEDw14HmbW=78_4P03nFDfmT7kOn4RsTF-PrBi+jWr0g@mail.gmail.com>
Date:	Wed, 15 Jun 2016 07:44:32 -0500
From:	Rob Herring <robh@...nel.org>
To:	Mark Brown <broonie@...nel.org>
Cc:	Xing Zheng <zhengxing@...k-chips.com>,
	"open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
	Doug Anderson <dianders@...omium.org>,
	Heiko Stübner <heiko@...ech.de>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	Liam Girdwood <lgirdwood@...il.com>,
	Jaroslav Kysela <perex@...ex.cz>,
	Takashi Iwai <tiwai@...e.com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Linux-ALSA <alsa-devel@...a-project.org>
Subject: Re: [PATCH v5] ASoC: rockchip: Add machine driver for RK3399 GRU Boards

On Wed, Jun 15, 2016 at 4:53 AM, Mark Brown <broonie@...nel.org> wrote:
> On Tue, Jun 14, 2016 at 05:38:10PM -0500, Rob Herring wrote:
>> On Mon, Jun 13, 2016 at 04:42:18PM +0800, Xing Zheng wrote:
>
>> > +sound {
>> > +   compatible = "rockchip,rk3399-gru-sound";
>> > +   rockchip,cpu = <&i2s0>;
>> > +   rockchip,codec = <&max98357a &rt5514 &da7219>;
>
>> These seem fairly standard though a variety of versions in the bindings.
>> Can we use audio-codec and audio-cpu (or cpu or audio-dai) here? Mark?
>
> Well, the roles aren't actually that standard (the fact that there's
> multiple CODECs and one CPU DAI here is really odd and definitely needs
> a very system specific interpretation).  If they were standard we
> already have the simple-card binding that things should be using.
> There's no point in standard property names if the interpretation has to
> be non-standard.

Okay, I agree with the system specific interpretation part. However, I
don't think using simple-card or not determines using common
properties.

> The vendor specific prefixes are there because all bindings are supposed
> to add prefixes to property names.

...unless they are common.

Rob