Linux clock framework development
 help / color / mirror / Atom feed
From: ALOK TIWARI <alok.a.tiwari@oracle.com>
To: Conor Dooley <conor@kernel.org>
Cc: conor.dooley@microchip.com, daire.mcnamara@microchip.com,
	mturquette@baylibre.com, sboyd@kernel.org,
	linux-riscv@lists.infradead.org, linux-clk@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [External] : Re: [PATCH] clk: microchip: mpfs: Fix incorrect MSSPLL ID in error message
Date: Tue, 24 Jun 2025 22:39:16 +0530	[thread overview]
Message-ID: <cf197270-bdca-4624-a2ad-9bb56429b5b7@oracle.com> (raw)
In-Reply-To: <20250624-monotype-disorder-aedee5ef7cfa@spud>



On 6/24/2025 9:29 PM, Conor Dooley wrote:
> On Sun, Jun 22, 2025 at 11:03:49AM -0700, Alok Tiwari wrote:
>> The error message in mpfs_clk_register_mssplls() incorrectly
>> printed a constant CLK_MSSPLL_INTERNAL instead of the actual
>> PLL ID that failed to register.
> Huh, that's weird. Did you actually encounter this happening, or is this
> some sort of patch based on the output from a tool?
> I ask because I don't see how this could ever actually report a
> constant, when the array it loops over only has a single element.
> Feels like we should just do something like the following (if we do
> anything at all)
> 
> Cheers,
> Conor.
> 
> diff --git a/drivers/clk/microchip/clk-mpfs.c b/drivers/clk/microchip/clk-mpfs.c
> index c22632a7439c5..ed6d5e6ff98ec 100644
> --- a/drivers/clk/microchip/clk-mpfs.c
> +++ b/drivers/clk/microchip/clk-mpfs.c
> @@ -148,22 +148,18 @@ static struct mpfs_msspll_hw_clock mpfs_msspll_clks[] = {
>   };
>   
>   static int mpfs_clk_register_mssplls(struct device *dev, struct mpfs_msspll_hw_clock *msspll_hws,
> -				     unsigned int num_clks, struct mpfs_clock_data *data)
> +				     struct mpfs_clock_data *data)
>   {
> -	unsigned int i;
> +	struct mpfs_msspll_hw_clock *msspll_hw = &msspll_hws[0];
>   	int ret;
>   
> -	for (i = 0; i < num_clks; i++) {
> -		struct mpfs_msspll_hw_clock *msspll_hw = &msspll_hws[i];
> +	msspll_hw->base = data->msspll_base;
> +	ret = devm_clk_hw_register(dev, &msspll_hw->hw);
> +	if (ret)
> +		return dev_err_probe(dev, ret, "failed to register msspll id: %d\n",
> +				     CLK_MSSPLL_INTERNAL);
>   
> -		msspll_hw->base = data->msspll_base;
> -		ret = devm_clk_hw_register(dev, &msspll_hw->hw);
> -		if (ret)
> -			return dev_err_probe(dev, ret, "failed to register msspll id: %d\n",
> -					     CLK_MSSPLL_INTERNAL);
> -
> -		data->hw_data.hws[msspll_hw->id] = &msspll_hw->hw;
> -	}
> +	data->hw_data.hws[msspll_hw->id] = &msspll_hw->hw;
>   
>   	return 0;
>   }
> @@ -386,8 +382,7 @@ static int mpfs_clk_probe(struct platform_device *pdev)
>   	clk_data->dev = dev;
>   	dev_set_drvdata(dev, clk_data);
>   
> -	ret = mpfs_clk_register_mssplls(dev, mpfs_msspll_clks, ARRAY_SIZE(mpfs_msspll_clks),
> -					clk_data);
> +	ret = mpfs_clk_register_mssplls(dev, mpfs_msspll_clks, clk_data);
>   	if (ret)
>   		return ret;


Thanks Conor. This patch based on static tool.

You are right, there is only a single MSSPLL internal clock, so the loop 
isn't strictly necessary.
We could either remove the loop entirely (as you suggested),
or alternatively, just tweak the error message to something like:
"failed to register MSSPLL internal id: %d\n"

This would help distinguish it from the error messages used for the 
MSSPLL output and cfg clocks.


I also noticed that similar generic messages are used elsewhere, like:
"failed to register clock id: %d\n" in mpfs_clk_register_cfgs()
"failed to register clock id: %d\n" in mpfs_clk_register_periphs()

Would it make sense to update those as well for clarity, or do you think 
it's better to keep the patch minimal and leave them as is?


Thanks,
Alok

  reply	other threads:[~2025-06-24 17:09 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-22 18:03 [PATCH] clk: microchip: mpfs: Fix incorrect MSSPLL ID in error message Alok Tiwari
2025-06-24 15:59 ` Conor Dooley
2025-06-24 17:09   ` ALOK TIWARI [this message]
2025-06-25 13:00     ` [External] : " Conor Dooley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cf197270-bdca-4624-a2ad-9bb56429b5b7@oracle.com \
    --to=alok.a.tiwari@oracle.com \
    --cc=conor.dooley@microchip.com \
    --cc=conor@kernel.org \
    --cc=daire.mcnamara@microchip.com \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=mturquette@baylibre.com \
    --cc=sboyd@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox