public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: "Michal Suchánek" <msuchanek@suse.de>
To: Sean Anderson <seanga2@gmail.com>
Cc: Samuel Holland <samuel@sholland.org>,
	Lukasz Majewski <lukma@denx.de>, 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 1/6] clk: Handle error pointers in clk_valid()
Date: Mon, 20 Feb 2023 20:42:39 +0100	[thread overview]
Message-ID: <20230220194239.GN19419@kitsune.suse.cz> (raw)
In-Reply-To: <cc00b398-2490-1373-775b-2281c0984e79@gmail.com>

On Mon, Feb 20, 2023 at 10:57:17AM -0500, Sean Anderson wrote:
> 
> On 2/20/23 05:46, Michal Suchánek wrote:
> > On Sun, Feb 19, 2023 at 11:59:34PM -0600, Samuel Holland wrote:
> > > Some clk uclass functions, such as devm_clk_get() and clk_get_parent(),
> > > return error pointers. clk_valid() should not consider these pointers
> > > to be valid.
> > > 
> > > Fixes: 8a1661f20e6c ("drivers: clk: Handle gracefully NULL pointers")
> > > Signed-off-by: Samuel Holland <samuel@sholland.org>
> > > ---
> > > 
> > >   include/clk.h | 2 +-
> > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/include/clk.h b/include/clk.h
> > > index d91285235f7..4acb878ec6d 100644
> > > --- a/include/clk.h
> > > +++ b/include/clk.h
> > > @@ -671,7 +671,7 @@ static inline bool clk_dev_binded(struct clk *clk)
> > >    */
> > >   static inline bool clk_valid(struct clk *clk)
> > >   {
> > > -	return clk && !!clk->dev;
> > > +	return clk && !IS_ERR(clk) && !!clk->dev;
> > >   }
> > >   int soc_clk_dump(void);
> > 
> > Maybe it would be better to avoid the error pointers instead, there
> > should not be that many places where they are returned.
> 
> This not quite the right way to phrase this. Instead, I would ask: where
> are places where the return value is not checked correctly? It's perfectly

Pretty much everywhere where clk_get_parent is used outside of core code
absolutely no error checking is done.

> fine to pass NULL or uninitialized clocks to other clock functions, but it's
> not OK to ignore errors.

Is there some documentation on what is the distinction, specifically?

If there isn't it's meaningless and NULL can be returned on error
simplifying the code, thinking about the code, debugging, pretty much
everything.

Thanks

Michal





  reply	other threads:[~2023-02-20 19:42 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 [this message]
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
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=20230220194239.GN19419@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