linux-kernel - Re: [PATCH] ASoC: kirkwood-i2s: fix a compilation warning

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

Message-ID: <20130715232921.GH11538@sirena.org.uk>
Date:	Tue, 16 Jul 2013 00:29:21 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	Jean-Francois Moine <moinejf@...e.fr>,
	Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.de>,
	alsa-devel@...a-project.org, linux-kernel@...r.kernel.org,
	Liam Girdwood <lgirdwood@...il.com>
Subject: Re: [PATCH] ASoC: kirkwood-i2s: fix a compilation warning

On Mon, Jul 15, 2013 at 11:58:36PM +0100, Mark Brown wrote:
> On Mon, Jul 15, 2013 at 10:37:27PM +0100, Russell King - ARM Linux wrote:

> > I suggest you go back and re-read the driver because it most certainly
> > does use extclk.  What makes you think it won't?

> The only thing I can see which is pushing a constraint up the stack is
> KIRKWOOD_I2S_RATES in the DAIs which only allows 44.1kHz, 48kHz and
> 96kHz, the rates for which the internal clock is used.  The driver will

Ugh, I just saw the dai_extclk stuff.  That's probably also problematic
the other way - it'll break if someone decides to put a non-programmable
clock on there, or something that can't generate arbatrary frequencies
like a crystal plus divider.  It's also not clear to me why the driver
ever uses the internal clocks if something external has been provided.

This does mean the change is safe, though - but it needs to be called
out in both the code and the changelog how this is happening.

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