All of lore.kernel.org
 help / color / mirror / Atom feed
* [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.