Re: [PATCH v4 3/7] can: rcar_canfd: Allow the CAN FD clock to be sourced from fck
From: claudiu beznea
Date: Fri Nov 06 2026 - 03:04:26 EST
Hi, Marc,
On 10/19/26 13:42, Marc Kleine-Budde wrote:
On 19.10.2026 13:36:49, claudiu beznea wrote:I've addressed the concerns raised in this discussion at [1]. Could you please let me know if there is anything else to address for this series and [1] to go forward?
Based on the comment on this code "If not available fallback to CANFD clock"
I think the intention with IS_ERR() is to allow probing go forward,
falling back to CANFD clock, in case of any error of devm_clk_get().
The device trees that I've checked sets the can_clk to a fixed clock
with rate = 0 or have the clock provided directly by the SoC clock
provider. I think the intention with IS_ERR() was not only for -ENOENT
but for any other kind of errors. We can return in case of
-EPROBE_DEFER, to ensure the expected clock is used, when it's available
and sane.
I'll switch to something like:
gpriv->can_clk = devm_clk_get(&pdev->dev, "can_clk");
+if (ERR_PTR(gpriv->can_clk) == -EPROBE_DEFER)
+ return dev_err_ptr(dev, ...);
On the other hand, returning -EPROBE_DEFER here means the driver may never
probe if the can_clk provider fails to probe, even though the fallback clock
is available. That would go against what I understand to be the intent of
the IS_ERR() check: letting the probe continue when can_clk can't be
obtained.
Please let me know how you would like me to proceed.
If the clock continuously fails with the error -EPROBE_DEFER, your
.config/DT/system is broken. I don't think it's a good idea to ignore
these errors.
Thank you,
Claudiu
[1] https://lore.kernel.org/all/20261019121356.2421761-1-claudiu.beznea@xxxxxxxxxx