Re: [PATCH v4 3/7] can: rcar_canfd: Allow the CAN FD clock to be sourced from fck

[claudiu beznea <claudiu.beznea@tuxon.dev>]

Hi, Marc,

On 10/19/26 13:42, Marc Kleine-Budde wrote:
> On 19.10.2026 13:36:49, claudiu beznea wrote:
>>> 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.
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?

Thank you,
Claudiu

[1] https://lore.kernel.org/all/20261019121356.2421761-1-claudiu.beznea@kernel.org