If both 'clk_ipg' and 'clk_per' are NULL, we return an un-init value.
So set 'err' to 0, to return success in such a case.
Fixes: d9cead75b1c6 ("can: flexcan: add mcf5441x support")
Signed-off-by: Christophe JAILLET <[email protected]>
---
Another way to fix it is to remove the NULL checks for 'clk_ipg' and
'clk_per' that been added in commit d9cead75b1c6.
They look useless to me because 'clk_prepare_enable()' returns 0 if it is
passed a NULL pointer.
Having these explicit tests is maybe informational (i.e. these pointers
can really be NULL) or have been added to silent a compiler or a static
checker.
So, in case, I've left the tests and just fixed the un-init 'err' variable
issue.
---
drivers/net/can/flexcan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
index 54ffb796a320..7734229aa078 100644
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -649,7 +649,7 @@ static inline void flexcan_error_irq_disable(const struct flexcan_priv *priv)
static int flexcan_clks_enable(const struct flexcan_priv *priv)
{
- int err;
+ int err = 0;
if (priv->clk_ipg) {
err = clk_prepare_enable(priv->clk_ipg);
--
2.30.2
On 29.07.2021 13:27:42, Christophe JAILLET wrote:
> If both 'clk_ipg' and 'clk_per' are NULL, we return an un-init value.
> So set 'err' to 0, to return success in such a case.
Thanks for the patch, a similar one has been posted before:
https://lore.kernel.org/linux-can/[email protected]/
> Fixes: d9cead75b1c6 ("can: flexcan: add mcf5441x support")
> Signed-off-by: Christophe JAILLET <[email protected]>
> ---
> Another way to fix it is to remove the NULL checks for 'clk_ipg' and
> 'clk_per' that been added in commit d9cead75b1c6.
>
> They look useless to me because 'clk_prepare_enable()' returns 0 if it is
> passed a NULL pointer.
ACK, while the common clock framework's clk_prepare_enable() can handle
NULL pointers, the clock framework used on the mcf5441x doesn't.
> Having these explicit tests is maybe informational (i.e. these pointers
> can really be NULL) or have been added to silent a compiler or a static
> checker.
>
> So, in case, I've left the tests and just fixed the un-init 'err' variable
> issue.
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
On Thu, Jul 29, 2021 at 01:31:01PM +0200, Marc Kleine-Budde wrote:
> On 29.07.2021 13:27:42, Christophe JAILLET wrote:
> > If both 'clk_ipg' and 'clk_per' are NULL, we return an un-init value.
> > So set 'err' to 0, to return success in such a case.
>
> Thanks for the patch, a similar one has been posted before:
> https://lore.kernel.org/linux-can/[email protected]/
>
> > Fixes: d9cead75b1c6 ("can: flexcan: add mcf5441x support")
> > Signed-off-by: Christophe JAILLET <[email protected]>
> > ---
> > Another way to fix it is to remove the NULL checks for 'clk_ipg' and
> > 'clk_per' that been added in commit d9cead75b1c6.
> >
> > They look useless to me because 'clk_prepare_enable()' returns 0 if it is
> > passed a NULL pointer.
>
> ACK, while the common clock framework's clk_prepare_enable() can handle
> NULL pointers, the clock framework used on the mcf5441x doesn't.
Huh? It looks like it just uses the regular stuff?
regards,
dan carpenter
On 29.07.2021 14:44:42, Dan Carpenter wrote:
> On Thu, Jul 29, 2021 at 01:31:01PM +0200, Marc Kleine-Budde wrote:
> > On 29.07.2021 13:27:42, Christophe JAILLET wrote:
> > > If both 'clk_ipg' and 'clk_per' are NULL, we return an un-init value.
> > > So set 'err' to 0, to return success in such a case.
> >
> > Thanks for the patch, a similar one has been posted before:
> > https://lore.kernel.org/linux-can/[email protected]/
> >
> > > Fixes: d9cead75b1c6 ("can: flexcan: add mcf5441x support")
> > > Signed-off-by: Christophe JAILLET <[email protected]>
> > > ---
> > > Another way to fix it is to remove the NULL checks for 'clk_ipg' and
> > > 'clk_per' that been added in commit d9cead75b1c6.
> > >
> > > They look useless to me because 'clk_prepare_enable()' returns 0 if it is
> > > passed a NULL pointer.
> >
> > ACK, while the common clock framework's clk_prepare_enable() can handle
> > NULL pointers, the clock framework used on the mcf5441x doesn't.
>
> Huh? It looks like it just uses the regular stuff?
https://lore.kernel.org/linux-can/CAMuHMdUeeH2BWgVRoVX7yfckY=wi8X3qkaH0THhVF_3FpZsbqg@mail.gmail.com/
Geert Uytterhoeven said:
>> Except that the non-CCF implementation of clk_enable() in
>> arch/m68k/coldfire/clk.c still returns -EINVAL instead of NULL.
>> Any plans to move to CCF? Or at least fix legacy clk_enable().
https://lore.kernel.org/linux-can/[email protected]/
Angelo Dureghello said:
>> as Geert pointed out, right now without this protection
>> (that shouldn't anyway harm), probe fails:
>>
>> [ 1.680000] flexcan: probe of flexcan.0 failed with error -22
Maybe it's time to fix the mcf5441x's clk_enable() as Geert pointed out.
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
On Thu, Jul 29, 2021 at 01:57:44PM +0200, Marc Kleine-Budde wrote:
> Maybe it's time to fix the mcf5441x's clk_enable() as Geert pointed out.
Ah. Thanks! I'll send a patch for that. In the mean time your patch
which sets "ret = 0;" is the correct fix.
regards,
dan carpenter