[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150420211426.GN14892@sirena.org.uk>
Date: Mon, 20 Apr 2015 22:14:26 +0100
From: Mark Brown <broonie@...nel.org>
To: Kevin Cernekee <cernekee@...omium.org>
Cc: Lars-Peter Clausen <lars@...afoo.de>, lgirdwood@...il.com,
devicetree@...r.kernel.org, alsa-devel@...a-project.org,
Andrew Bresticker <abrestic@...omium.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
dgreid@...omium.org, Olof Johansson <olofj@...omium.org>
Subject: Re: [alsa-devel] [PATCH 2/3] ASoC: tas571x: New driver for TI
TAS571x power amplifiers
On Mon, Apr 20, 2015 at 01:56:46PM -0700, Kevin Cernekee wrote:
> On Thu, Apr 16, 2015 at 5:57 AM, Lars-Peter Clausen <lars@...afoo.de> wrote:
> > On 04/15/2015 11:42 PM, Kevin Cernekee wrote:
> > If you want to make the clock optional use
> > if (PTR_ERR(priv->mclk) == -ENOENT)
> > return PTR_ERR(priv->mclk);
> > This makes sure that the case where the clock is specified, but there is a
> > error with the specification (e.g. incorrect DT cells) is handled properly.
> Did you mean:
> > if (PTR_ERR(priv->mclk) != -ENOENT)
> > return PTR_ERR(priv->mclk);
> I don't see this in other codec drivers, but I do see the explicit
> EPROBE_DEFER check in max98090, max98095, pcm512x, and wm8960.
That's the most correct way of writing a check for an optional clock,
best practice on this stuff is evolving over time (as is standardization
in the clock API).
Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)
Powered by blists - more mailing lists