[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YV3XkLzs5VBv3Sic@sirena.org.uk>
Date: Wed, 6 Oct 2021 18:06:24 +0100
From: Mark Brown <broonie@...nel.org>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc: Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
Hans de Goede <hdegoede@...hat.com>,
alsa-devel@...a-project.org, linux-kernel@...r.kernel.org,
Cezary Rojewski <cezary.rojewski@...el.com>,
Liam Girdwood <liam.r.girdwood@...ux.intel.com>,
Jie Yang <yang.jie@...ux.intel.com>,
Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.com>
Subject: Re: [PATCH v1 3/4] ASoC: Intel: bytcr_rt5651: use
devm_clk_get_optional() for mclk
On Wed, Oct 06, 2021 at 07:50:45PM +0300, Andy Shevchenko wrote:
> On Wed, Oct 06, 2021 at 11:37:24AM -0500, Pierre-Louis Bossart wrote:
> > By looking at this code only one cannot really visualize that it's a
> > no-op. I personally prefer to see explicit intent rather than have to
> > dig hundreds of lines below what this clock is optional.
> > I am also not even sure that in real products this clock is actually
> > optional,
> The code tells that it's optional. If it's not the case, the code has
> to be fixed accordingly.
AIUI with the clock API the idiomatic thing is that any optionality is
handled at the point where the clock is acquired - if the clock is
optional you end up with NULL which in the clock API is a dummy clock
and ignored. The rest of the code then doesn't need to worry about any
of this stuff and the handling can only be in one place.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists