From: Dan Carpenter <error27@gmail.com>
To: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Cc: linux-media@vger.kernel.org
Subject: Re: [bug report] media: i2c: ov5670: Use common clock framework
Date: Wed, 8 Feb 2023 18:02:12 +0300 [thread overview]
Message-ID: <Y+O5dKQAXD+GqpbZ@kadam> (raw)
In-Reply-To: <20230208142340.pmg337xngo2qv7jk@uno.localdomain>
On Wed, Feb 08, 2023 at 03:23:40PM +0100, Jacopo Mondi wrote:
> > 2663 ov5670->xvclk = devm_clk_get(&client->dev, NULL);
> > 2664 if (!IS_ERR_OR_NULL(ov5670->xvclk))
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > Imagine CONFIG_HAVE_CLK is not enabled so now devm_clk_get() returns
> > NULL.
> >
> > 2665 input_clk = clk_get_rate(ov5670->xvclk);
> > 2666 else if (PTR_ERR(ov5670->xvclk) == -ENOENT)
> > 2667 device_property_read_u32(&client->dev, "clock-frequency",
> > 2668 &input_clk);
> > 2669 else
> > --> 2670 return dev_err_probe(&client->dev, PTR_ERR(ov5670->xvclk),
> > 2671 "error getting clock\n");
> >
> > A NULL is zero and zero is success.
> >
>
> Ouch! Quite a subtle bug!
>
> > That means this code returns success without doing anything. Perhaps
> > the right thing is to use use Kconfig to ensure that this cannot be
> > build without CONFIG_HAVE_CLK. The other solution is to write the
> > driver with a bunch of NULL checks so that it still runs without a clk.
> >
> > The IS_ERR_OR_NULL() check should be changed to if (IS_ERR()).
>
> >From a very quick lookup at how that symbol is used it seems it is
> selected both by COMMON_CLOCK and HAVE_LEGACY_CLOCK, however I'm not
> sure I know enough to consider safe depending on that symbol.
>
> When it comes to sensor-driver specific issues, I see CCS (the
> reference i2c camera sensor driver) depending on it, so I guess it's
> fine (Sakari in cc), but no other sensor driver does that (actually no
> driver in drivers/linux/media/ does that, not just i2c sensors!)
>
> When it comes to adding NULL checks, the common clock frameworks
> already protects against that, turning the usual
> clock_prepare_enable() and clock_disable_unprepare() calls into nop,
> so if we can't depend on CONFIG_HAVE_CLK I guess we can get away
> with some ugly:
>
> #if defined(CONFIG_HAVE_CLK)
> ov5670->xvclk = devm_clk_get(&client->dev, NULL);
> #else
> ov5670->xvclk = ERR_PTR(-ENOENT);
> #endif
> if (!IS_ERR_OR_NULL(ov5670->xvclk))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The static checker would still complain that we're passing NULL to
PTR_ERR() because of the IS_ERR_OR_NULL() check. It should just be
IS_ERR().
I wouldn't be surprised if the Kconfig ensures that a NULL return is
impossible in the original code. However in the proposed code, then
it's definitely impossible.
> input_clk = clk_get_rate(ov5670->xvclk);
> else if (PTR_ERR(ov5670->xvclk) == -ENOENT)
> device_property_read_u32(&client->dev, "clock-frequency",
> &input_clk);
> else
> return dev_err_probe(&client->dev, PTR_ERR(ov5670->xvclk),
> "error getting clock\n");
>
> Not super nice though :/
Why not just add the NULL path to the check for -ENOENT?
ov5670->xvclk = devm_clk_get(&client->dev, NULL);
if (!IS_ERR_OR_NULL(ov5670->xvclk))
input_clk = clk_get_rate(ov5670->xvclk);
else if (!ov5670->xvclk || PTR_ERR(ov5670->xvclk) == -ENOENT)
device_property_read_u32(&client->dev, "clock-frequency",
&input_clk);
else
return dev_err_probe(&client->dev, PTR_ERR(ov5670->xvclk),
"error getting clock\n");
regards,
dan carpenter
next prev parent reply other threads:[~2023-02-08 15:02 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-08 13:37 [bug report] media: i2c: ov5670: Use common clock framework Dan Carpenter
2023-02-08 14:23 ` Jacopo Mondi
2023-02-08 14:30 ` Jacopo Mondi
2023-02-08 15:02 ` Dan Carpenter [this message]
2023-02-08 15:47 ` Jacopo Mondi
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=Y+O5dKQAXD+GqpbZ@kadam \
--to=error27@gmail.com \
--cc=jacopo.mondi@ideasonboard.com \
--cc=linux-media@vger.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 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.