| Message ID | a55780a2f4c8f1895b6bcbac4d3f8312b2731079.1627557857.git.christophe.jaillet@wanadoo.fr (mailing list archive) |
|---|---|
| State | Awaiting Upstream |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | can: flexcan: Fix an uninitialized variable issue | expand |
| Context | Check | Description |
|---|---|---|
| netdev/tree_selection | success | Series ignored based on subject |
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 <christophe.jaillet@wanadoo.fr> > --- > 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
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/20210728075428.1493568-1-mkl@pengutronix.de/ > > > Fixes: d9cead75b1c6 ("can: flexcan: add mcf5441x support") > > Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> > > --- > > 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/20210728075428.1493568-1-mkl@pengutronix.de/ > > > > > Fixes: d9cead75b1c6 ("can: flexcan: add mcf5441x support") > > > Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> > > > --- > > > 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/7c1151fc-cc28-cbc0-c385-313428b32dd7@kernel-space.org/ 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
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
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);
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 <christophe.jaillet@wanadoo.fr> --- 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(-)