public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: "Michal Suchánek" <msuchanek@suse.de>
To: Samuel Holland <samuel@sholland.org>
Cc: Lukasz Majewski <lukma@denx.de>,
	Sean Anderson <seanga2@gmail.com>, Simon Glass <sjg@chromium.org>,
	Dario Binacchi <dario.binacchi@amarulasolutions.com>,
	Jean-Jacques Hiblot <jjhiblot@ti.com>,
	Neil Armstrong <neil.armstrong@linaro.org>,
	Peng Fan <peng.fan@nxp.com>,
	u-boot@lists.denx.de
Subject: Re: [PATCH 2/6] clk: Fix error handling in clk_get_rate()
Date: Mon, 20 Feb 2023 11:37:44 +0100	[thread overview]
Message-ID: <20230220103744.GH19419@kitsune.suse.cz> (raw)
In-Reply-To: <20230220055940.41890-3-samuel@sholland.org>

Hello,

On Sun, Feb 19, 2023 at 11:59:35PM -0600, Samuel Holland wrote:
> log_ret() cannot work with unsigned values, and the assignment to 'ret'
> incorrectly truncates the rate from long to int.
> 
> Fixes: 5c5992cb90cf ("clk: Add debugging for return values")
> Signed-off-by: Samuel Holland <samuel@sholland.org>
> ---
> 
>  drivers/clk/clk-uclass.c | 7 +------
>  1 file changed, 1 insertion(+), 6 deletions(-)
> 
> diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
> index dc3e9d6a261..78299dbceb2 100644
> --- a/drivers/clk/clk-uclass.c
> +++ b/drivers/clk/clk-uclass.c
> @@ -471,7 +471,6 @@ void clk_free(struct clk *clk)
>  ulong clk_get_rate(struct clk *clk)
>  {
>  	const struct clk_ops *ops;
> -	int ret;
>  
>  	debug("%s(clk=%p)\n", __func__, clk);
>  	if (!clk_valid(clk))
> @@ -481,11 +480,7 @@ ulong clk_get_rate(struct clk *clk)
>  	if (!ops->get_rate)
>  		return -ENOSYS;
>  
> -	ret = ops->get_rate(clk);
> -	if (ret)
> -		return log_ret(ret);
> -
> -	return 0;
> +	return ops->get_rate(clk);
>  }

This is generally poor design of the clock stuff in u-boot.

It returns -ERROR for many error conditions, but also 0 for other error
conditions.

Some error handling checks for 0, some for errval, some casts to int and
checks for <= 0.

I think that using -ERROR for clocks does not make much sense in u-boot.

Even in the kernel the errval checks are pretty much limited to places
where integers are used to store page frame numbers or pointers, that is
errptr stored in an integer. For adresses it is pretty easy to make sure
that the last page is not mapped making the error pointers invalid
(although bugs in that part happened too).

For clocks no such guarantee exists. The only apparently invalid clock
is 0, and the correct fix is to fix up the clock code to return 0 on
error, always. It's a lot of code to fix, though.

If you do not want to fix everything then the correct thing to do is
make ret ulong, and check for errval *and* 0.

There is not much point in returning detailed error codes in u-boot,
anyway. It's not like there is some userspace that could interpret them.
Most errors are logged when they happen if ever, and callers only check
if error happened or not.

Thanks

Michal

  reply	other threads:[~2023-02-20 10:38 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-20  5:59 [PATCH 0/6] clk: uclass fixes and improvements Samuel Holland
2023-02-20  5:59 ` [PATCH 1/6] clk: Handle error pointers in clk_valid() Samuel Holland
2023-02-20 10:46   ` Michal Suchánek
2023-02-20 15:57     ` Sean Anderson
2023-02-20 19:42       ` Michal Suchánek
2023-03-04 19:54         ` Samuel Holland
2023-03-04 20:43           ` Michal Suchánek
2023-02-20  5:59 ` [PATCH 2/6] clk: Fix error handling in clk_get_rate() Samuel Holland
2023-02-20 10:37   ` Michal Suchánek [this message]
2023-02-20 16:08     ` Sean Anderson
2023-02-20 17:27       ` Michal Suchánek
2023-02-20 17:58         ` Sean Anderson
2023-02-20  5:59 ` [PATCH 3/6] clk: Fix error handling in clk_get_parent() Samuel Holland
2023-02-20 10:39   ` Michal Suchánek
2023-03-04 19:58     ` Samuel Holland
2023-03-04 20:46       ` Michal Suchánek
2023-03-04 21:25         ` Sean Anderson
2023-02-20  5:59 ` [PATCH 4/6] clk: Fix rate caching in clk_get_parent_rate() Samuel Holland
2023-02-20 10:41   ` Michal Suchánek
2023-02-20 16:11   ` Sean Anderson
2023-03-04 20:01     ` Samuel Holland
2023-02-20  5:59 ` [PATCH 5/6] clk: Remove an unneeded check from clk_get_parent_rate() Samuel Holland
2023-02-20 10:49   ` Michal Suchánek
2023-02-20 16:12   ` Sean Anderson
2023-02-20  5:59 ` [PATCH 6/6] clk: Add a .get_parent operation Samuel Holland
2023-02-20 16:13   ` Sean Anderson
2023-02-20 16:21   ` Simon Glass

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=20230220103744.GH19419@kitsune.suse.cz \
    --to=msuchanek@suse.de \
    --cc=dario.binacchi@amarulasolutions.com \
    --cc=jjhiblot@ti.com \
    --cc=lukma@denx.de \
    --cc=neil.armstrong@linaro.org \
    --cc=peng.fan@nxp.com \
    --cc=samuel@sholland.org \
    --cc=seanga2@gmail.com \
    --cc=sjg@chromium.org \
    --cc=u-boot@lists.denx.de \
    /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