[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YvO3ip3LPw2QhADB@sirena.org.uk>
Date: Wed, 10 Aug 2022 14:50:02 +0100
From: Mark Brown <broonie@...nel.org>
To: Christophe JAILLET <christophe.jaillet@...adoo.fr>
Cc: Cezary Rojewski <cezary.rojewski@...el.com>,
Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
Liam Girdwood <liam.r.girdwood@...ux.intel.com>,
Peter Ujfalusi <peter.ujfalusi@...ux.intel.com>,
Bard Liao <yung-chuan.liao@...ux.intel.com>,
Ranjani Sridharan <ranjani.sridharan@...ux.intel.com>,
Kai Vehmanen <kai.vehmanen@...ux.intel.com>,
Jaroslav Kysela <perex@...ex.cz>,
Takashi Iwai <tiwai@...e.com>,
Harsha Priya <harshapriya.n@...el.com>,
"Subhransu S. Prusty" <subhransu.s.prusty@...el.com>,
Vinod Koul <vkoul@...nel.org>,
Sriram Periyasamy <sriramx.periyasamy@...el.com>,
linux-kernel@...r.kernel.org, kernel-janitors@...r.kernel.org,
alsa-devel@...a-project.org
Subject: Re: [PATCH] ASoC: Intel: kbl_rt5663_max98927: Simplify clk_get()
usage
On Sun, Aug 07, 2022 at 10:18:54PM +0200, Christophe JAILLET wrote:
> If clk_get() returns -ENOENT, there is no need to defer the driver, -ENOENT
> will be returned the same for each retries.
> So, return the error code directly instead of -EPROBE_DEFER.
Are you *sure* that this is the case on Intel platforms where we don't
have a full firmware description for clocks and therefore can't identify
cases where we expect a clock to at some point to become available.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists