[PATCH] can: flexcan: Fix an uninitialized variable issue

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 <redacted>
---
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/20210728075428.1493568-1-mkl@pengutronix.de/

Fixes: d9cead75b1c6 ("can: flexcan: add mcf5441x support")
Signed-off-by: Christophe JAILLET <redacted>
---
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:

quoted

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/20210728075428.1493568-1-mkl@pengutronix.de/

quoted

Fixes: d9cead75b1c6 ("can: flexcan: add mcf5441x support")
Signed-off-by: Christophe JAILLET <redacted>
---
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:

quoted

On 29.07.2021 13:27:42, Christophe JAILLET wrote:

quoted

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/20210728075428.1493568-1-mkl@pengutronix.de/

quoted

Fixes: d9cead75b1c6 ("can: flexcan: add mcf5441x support")
Signed-off-by: Christophe JAILLET <redacted>
---
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:

quoted

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/7c1151fc-cc28-cbc0-c385-313428b32dd7@kernel-space.org/
Angelo Dureghello said:

quoted

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