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@xxxxxxxxxxxxxx/ > > > > > Fixes: d9cead75b1c6 ("can: flexcan: add mcf5441x support") > > > Signed-off-by: Christophe JAILLET <christophe.jaillet@xxxxxxxxxx> > > > --- > > > 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@xxxxxxxxxxxxxx/ 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@xxxxxxxxxxxxxxxx/ 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 |
Attachment:
signature.asc
Description: PGP signature
