linux-kernel - Re: [alsa-devel] [PATCH v3] ARM: kirkwood: extend the kirkwood i2s driver for DT usage

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] [day] [month] [year] [list]

Message-ID: <20130723171650.GJ9858@sirena.org.uk>
Date:	Tue, 23 Jul 2013 18:16:50 +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>,
	alsa-devel@...a-project.org, Takashi Iwai <tiwai@...e.de>,
	linux-kernel@...r.kernel.org, Liam Girdwood <lgirdwood@...il.com>,
	Rob Herring <rob.herring@...xeda.com>,
	devicetree-discuss@...r.kernel.org
Subject: Re: [alsa-devel] [PATCH v3] ARM: kirkwood: extend the kirkwood i2s
 driver for DT usage

On Tue, Jul 23, 2013 at 04:19:56PM +0100, Russell King - ARM Linux wrote:
> On Tue, Jul 23, 2013 at 04:01:50PM +0100, Mark Brown wrote:

> > Why would platform data have anything to do with this?  To repeat again
> > the way the clocks are mapped should be totally transparent to the
> > driver requesting them, if it isn't then the driver is not using the API
> > properly.

> Total rubbish.  Of course the driver needs to know what the clocks are,
> so that it can program its hardware accordingly.

Of course, but why through platform data?  Though reading your mail I
think we're talking at cross purposes here...

> In this case, it has always been the rule with the clock API that it
> shall be used as:

> 	clk_get(device, "internal");

> to get the internal clock, and:

> 	clk_get(device, "external");

> to get the external clock - or whatever names are appropriate to name the
> clock _inputs_.

This is exactly what I'd expect, yes - but it doesn't need the driver to
have platform data as far as I can see.  As you say the driver should be
requesting the two clock inputs the IP has by name which doesn't need it
to have any platform data, it just needs code like you have above.  The
board specific configuration is all handled within the clk_get() calls.

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