[PATCH] ASoC: Intel: kbl_rt5663_max98927: Simplify clk_get() usage
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.
Remove this special case and use dev_err_probe() to simplify code. It will also be less verbose if the clk is really deferred.
Fixes: f7f61e08fe58 ("ASoC: Intel: kbl: Enable mclk and ssp sclk early") Signed-off-by: Christophe JAILLET christophe.jaillet@wanadoo.fr --- This is based on my understanding of clk_get(). Review with care.
Not sure the Fixes tag is needed. The patch does not fix anything. If devm_clk_get() returns -ENOENT, it will just loop several time until the framework gives up. If it returns -EPROBE_DEFER, this case is already handled by the "return ret;"
So this patch should be a no-op, just a clean-up. --- sound/soc/intel/boards/kbl_rt5663_max98927.c | 31 ++++---------------- 1 file changed, 6 insertions(+), 25 deletions(-)
diff --git a/sound/soc/intel/boards/kbl_rt5663_max98927.c b/sound/soc/intel/boards/kbl_rt5663_max98927.c index 2d4224c5b152..07b00af2fa3c 100644 --- a/sound/soc/intel/boards/kbl_rt5663_max98927.c +++ b/sound/soc/intel/boards/kbl_rt5663_max98927.c @@ -989,7 +989,6 @@ static int kabylake_audio_probe(struct platform_device *pdev) { struct kbl_rt5663_private *ctx; struct snd_soc_acpi_mach *mach; - int ret;
ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_KERNEL); if (!ctx) @@ -1009,32 +1008,14 @@ static int kabylake_audio_probe(struct platform_device *pdev) &constraints_dmic_2ch : &constraints_dmic_channels;
ctx->mclk = devm_clk_get(&pdev->dev, "ssp1_mclk"); - if (IS_ERR(ctx->mclk)) { - ret = PTR_ERR(ctx->mclk); - if (ret == -ENOENT) { - dev_info(&pdev->dev, - "Failed to get ssp1_sclk, defer probe\n"); - return -EPROBE_DEFER; - } - - dev_err(&pdev->dev, "Failed to get ssp1_mclk with err:%d\n", - ret); - return ret; - } + if (IS_ERR(ctx->mclk)) + return dev_err_probe(&pdev->dev, PTR_ERR(ctx->mclk), + "Failed to get ssp1_mclk\n");
ctx->sclk = devm_clk_get(&pdev->dev, "ssp1_sclk"); - if (IS_ERR(ctx->sclk)) { - ret = PTR_ERR(ctx->sclk); - if (ret == -ENOENT) { - dev_info(&pdev->dev, - "Failed to get ssp1_sclk, defer probe\n"); - return -EPROBE_DEFER; - } - - dev_err(&pdev->dev, "Failed to get ssp1_sclk with err:%d\n", - ret); - return ret; - } + if (IS_ERR(ctx->sclk)) + return dev_err_probe(&pdev->dev, PTR_ERR(ctx->sclk), + "Failed to get ssp1_sclk\n");
return devm_snd_soc_register_card(&pdev->dev, kabylake_audio_card); }
On 8/7/22 22:18, 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.
Remove this special case and use dev_err_probe() to simplify code. It will also be less verbose if the clk is really deferred.
Fixes: f7f61e08fe58 ("ASoC: Intel: kbl: Enable mclk and ssp sclk early") Signed-off-by: Christophe JAILLET christophe.jaillet@wanadoo.fr
This is based on my understanding of clk_get(). Review with care.
Not sure the Fixes tag is needed. The patch does not fix anything. If devm_clk_get() returns -ENOENT, it will just loop several time until the framework gives up. If it returns -EPROBE_DEFER, this case is already handled by the "return ret;"
So this patch should be a no-op, just a clean-up.
I can't pretend understanding the clk framework in depth, but the only case where -ENOENT is returned seems to be this block in clk_hw_create_clk()
if (!try_module_get(core->owner)) { free_clk(clk); return ERR_PTR(-ENOENT); }
I have no idea why this would be converted to a -EPROBE_DEFER. May to account for module loading?
sound/soc/intel/boards/kbl_rt5663_max98927.c | 31 ++++---------------- 1 file changed, 6 insertions(+), 25 deletions(-)
diff --git a/sound/soc/intel/boards/kbl_rt5663_max98927.c b/sound/soc/intel/boards/kbl_rt5663_max98927.c index 2d4224c5b152..07b00af2fa3c 100644 --- a/sound/soc/intel/boards/kbl_rt5663_max98927.c +++ b/sound/soc/intel/boards/kbl_rt5663_max98927.c @@ -989,7 +989,6 @@ static int kabylake_audio_probe(struct platform_device *pdev) { struct kbl_rt5663_private *ctx; struct snd_soc_acpi_mach *mach;
int ret;
ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_KERNEL); if (!ctx)
@@ -1009,32 +1008,14 @@ static int kabylake_audio_probe(struct platform_device *pdev) &constraints_dmic_2ch : &constraints_dmic_channels;
ctx->mclk = devm_clk_get(&pdev->dev, "ssp1_mclk");
- if (IS_ERR(ctx->mclk)) {
ret = PTR_ERR(ctx->mclk);
if (ret == -ENOENT) {
dev_info(&pdev->dev,
"Failed to get ssp1_sclk, defer probe\n");
return -EPROBE_DEFER;
}
dev_err(&pdev->dev, "Failed to get ssp1_mclk with err:%d\n",
ret);
return ret;
- }
if (IS_ERR(ctx->mclk))
return dev_err_probe(&pdev->dev, PTR_ERR(ctx->mclk),
"Failed to get ssp1_mclk\n");
ctx->sclk = devm_clk_get(&pdev->dev, "ssp1_sclk");
- if (IS_ERR(ctx->sclk)) {
ret = PTR_ERR(ctx->sclk);
if (ret == -ENOENT) {
dev_info(&pdev->dev,
"Failed to get ssp1_sclk, defer probe\n");
return -EPROBE_DEFER;
}
dev_err(&pdev->dev, "Failed to get ssp1_sclk with err:%d\n",
ret);
return ret;
- }
if (IS_ERR(ctx->sclk))
return dev_err_probe(&pdev->dev, PTR_ERR(ctx->sclk),
"Failed to get ssp1_sclk\n");
return devm_snd_soc_register_card(&pdev->dev, kabylake_audio_card);
}
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.
Le 10/08/2022 à 15:50, Mark Brown a écrit :
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.
No, I'm *not* sure.
This looked odd enough to deserve a patch proposal, that's all. (based on my grep and coccinelle scripts, this is the only place in the kernel where the result of a clk_get() is handled that way)
There are many intel.com in cc:. Would be nice if s.o. could confirm if the patch is valid or not.
CJ
participants (3)
-
Christophe JAILLET
-
Mark Brown
-
Pierre-Louis Bossart