* [PATCH] ASoC: Intel: kbl_rt5663_max98927: Simplify clk_get() usage
@ 2022-08-07 20:18 ` Christophe JAILLET
0 siblings, 0 replies; 10+ messages in thread
From: Christophe JAILLET @ 2022-08-07 20:18 UTC (permalink / raw)
To: Cezary Rojewski, Pierre-Louis Bossart, Liam Girdwood,
Peter Ujfalusi, Bard Liao, Ranjani Sridharan, Kai Vehmanen,
Mark Brown, Jaroslav Kysela, Takashi Iwai, Harsha Priya,
Subhransu S. Prusty, Vinod Koul, Sriram Periyasamy
Cc: linux-kernel, kernel-janitors, Christophe JAILLET, alsa-devel
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);
}
--
2.34.1
^ permalink raw reply related [flat|nested] 10+ messages in thread
* [PATCH] ASoC: Intel: kbl_rt5663_max98927: Simplify clk_get() usage
@ 2022-08-07 20:18 ` Christophe JAILLET
0 siblings, 0 replies; 10+ messages in thread
From: Christophe JAILLET @ 2022-08-07 20:18 UTC (permalink / raw)
To: Cezary Rojewski, Pierre-Louis Bossart, Liam Girdwood,
Peter Ujfalusi, Bard Liao, Ranjani Sridharan, Kai Vehmanen,
Mark Brown, Jaroslav Kysela, Takashi Iwai, Harsha Priya,
Subhransu S. Prusty, Vinod Koul, Sriram Periyasamy
Cc: Christophe JAILLET, alsa-devel, kernel-janitors, linux-kernel
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);
}
--
2.34.1
^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH] ASoC: Intel: kbl_rt5663_max98927: Simplify clk_get() usage
2022-08-07 20:18 ` Christophe JAILLET
@ 2022-08-08 7:34 ` Pierre-Louis Bossart
-1 siblings, 0 replies; 10+ messages in thread
From: Pierre-Louis Bossart @ 2022-08-08 7:34 UTC (permalink / raw)
To: Christophe JAILLET, Cezary Rojewski, Liam Girdwood,
Peter Ujfalusi, Bard Liao, Ranjani Sridharan, Kai Vehmanen,
Mark Brown, Jaroslav Kysela, Takashi Iwai, Harsha Priya,
Subhransu S. Prusty, Vinod Koul, Sriram Periyasamy
Cc: linux-kernel, kernel-janitors, alsa-devel
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);
> }
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] ASoC: Intel: kbl_rt5663_max98927: Simplify clk_get() usage
@ 2022-08-08 7:34 ` Pierre-Louis Bossart
0 siblings, 0 replies; 10+ messages in thread
From: Pierre-Louis Bossart @ 2022-08-08 7:34 UTC (permalink / raw)
To: Christophe JAILLET, Cezary Rojewski, Liam Girdwood,
Peter Ujfalusi, Bard Liao, Ranjani Sridharan, Kai Vehmanen,
Mark Brown, Jaroslav Kysela, Takashi Iwai, Harsha Priya,
Subhransu S. Prusty, Vinod Koul, Sriram Periyasamy
Cc: alsa-devel, kernel-janitors, linux-kernel
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);
> }
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] ASoC: Intel: kbl_rt5663_max98927: Simplify clk_get() usage
2022-08-07 20:18 ` Christophe JAILLET
@ 2022-08-08 13:19 ` Mark Brown
-1 siblings, 0 replies; 10+ messages in thread
From: Mark Brown @ 2022-08-08 13:19 UTC (permalink / raw)
To: Christophe JAILLET
Cc: Cezary Rojewski, Pierre-Louis Bossart, Liam Girdwood,
Peter Ujfalusi, Bard Liao, Ranjani Sridharan, Kai Vehmanen,
Jaroslav Kysela, Takashi Iwai, Harsha Priya, Subhransu S. Prusty,
Vinod Koul, Sriram Periyasamy, linux-kernel, kernel-janitors,
alsa-devel
[-- Attachment #1: Type: text/plain, Size: 184 bytes --]
On Sun, Aug 07, 2022 at 10:18:54PM +0200, Christophe JAILLET wrote:
> Not sure the Fixes tag is needed. The patch does not fix anything.
You just answered your own question there...
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] ASoC: Intel: kbl_rt5663_max98927: Simplify clk_get() usage
@ 2022-08-08 13:19 ` Mark Brown
0 siblings, 0 replies; 10+ messages in thread
From: Mark Brown @ 2022-08-08 13:19 UTC (permalink / raw)
To: Christophe JAILLET
Cc: alsa-devel, Cezary Rojewski, Kai Vehmanen, Harsha Priya,
Peter Ujfalusi, Takashi Iwai, kernel-janitors,
Pierre-Louis Bossart, Ranjani Sridharan, Liam Girdwood,
Vinod Koul, Subhransu S. Prusty, Bard Liao, Sriram Periyasamy,
linux-kernel
[-- Attachment #1: Type: text/plain, Size: 184 bytes --]
On Sun, Aug 07, 2022 at 10:18:54PM +0200, Christophe JAILLET wrote:
> Not sure the Fixes tag is needed. The patch does not fix anything.
You just answered your own question there...
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] ASoC: Intel: kbl_rt5663_max98927: Simplify clk_get() usage
2022-08-07 20:18 ` Christophe JAILLET
@ 2022-08-10 13:50 ` Mark Brown
-1 siblings, 0 replies; 10+ messages in thread
From: Mark Brown @ 2022-08-10 13:50 UTC (permalink / raw)
To: Christophe JAILLET
Cc: Cezary Rojewski, Pierre-Louis Bossart, Liam Girdwood,
Peter Ujfalusi, Bard Liao, Ranjani Sridharan, Kai Vehmanen,
Jaroslav Kysela, Takashi Iwai, Harsha Priya, Subhransu S. Prusty,
Vinod Koul, Sriram Periyasamy, linux-kernel, kernel-janitors,
alsa-devel
[-- Attachment #1: Type: text/plain, Size: 468 bytes --]
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.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] ASoC: Intel: kbl_rt5663_max98927: Simplify clk_get() usage
@ 2022-08-10 13:50 ` Mark Brown
0 siblings, 0 replies; 10+ messages in thread
From: Mark Brown @ 2022-08-10 13:50 UTC (permalink / raw)
To: Christophe JAILLET
Cc: alsa-devel, Cezary Rojewski, Kai Vehmanen, Harsha Priya,
Peter Ujfalusi, Takashi Iwai, kernel-janitors,
Pierre-Louis Bossart, Ranjani Sridharan, Liam Girdwood,
Vinod Koul, Subhransu S. Prusty, Bard Liao, Sriram Periyasamy,
linux-kernel
[-- Attachment #1: Type: text/plain, Size: 468 bytes --]
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.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] ASoC: Intel: kbl_rt5663_max98927: Simplify clk_get() usage
2022-08-10 13:50 ` Mark Brown
@ 2022-08-10 19:06 ` Christophe JAILLET
-1 siblings, 0 replies; 10+ messages in thread
From: Christophe JAILLET @ 2022-08-10 19:06 UTC (permalink / raw)
To: Mark Brown
Cc: Cezary Rojewski, Pierre-Louis Bossart, Liam Girdwood,
Peter Ujfalusi, Bard Liao, Ranjani Sridharan, Kai Vehmanen,
Jaroslav Kysela, Takashi Iwai, Harsha Priya, Subhransu S. Prusty,
Vinod Koul, Sriram Periyasamy, linux-kernel, kernel-janitors,
alsa-devel
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] ASoC: Intel: kbl_rt5663_max98927: Simplify clk_get() usage
@ 2022-08-10 19:06 ` Christophe JAILLET
0 siblings, 0 replies; 10+ messages in thread
From: Christophe JAILLET @ 2022-08-10 19:06 UTC (permalink / raw)
To: Mark Brown
Cc: alsa-devel, Cezary Rojewski, Kai Vehmanen, Harsha Priya,
Peter Ujfalusi, Takashi Iwai, kernel-janitors,
Pierre-Louis Bossart, Ranjani Sridharan, Liam Girdwood,
Vinod Koul, Subhransu S. Prusty, Bard Liao, Sriram Periyasamy,
linux-kernel
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
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2022-08-10 19:07 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-08-07 20:18 [PATCH] ASoC: Intel: kbl_rt5663_max98927: Simplify clk_get() usage Christophe JAILLET
2022-08-07 20:18 ` Christophe JAILLET
2022-08-08 7:34 ` Pierre-Louis Bossart
2022-08-08 7:34 ` Pierre-Louis Bossart
2022-08-08 13:19 ` Mark Brown
2022-08-08 13:19 ` Mark Brown
2022-08-10 13:50 ` Mark Brown
2022-08-10 13:50 ` Mark Brown
2022-08-10 19:06 ` Christophe JAILLET
2022-08-10 19:06 ` Christophe JAILLET
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.