mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: claudiu beznea <claudiu.beznea@tuxon.dev>
To: Marc Kleine-Budde <mkl@pengutronix.de>
Cc: mailhol@kernel.org, robh@kernel.org, krzk+dt@kernel.org,
	conor+dt@kernel.org, geert+renesas@glider.be,
	magnus.damm@gmail.com, biju.das.jz@bp.renesas.com,
	fabrizio.castro.jz@renesas.com, linux-can@vger.kernel.org,
	devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Subject: Re: [PATCH v4 3/7] can: rcar_canfd: Allow the CAN FD clock to be sourced from fck
Date: Mon, 19 Oct 2026 12:58:24 +0300	[thread overview]
Message-ID: <4a9e32a8-8a2e-4b70-8057-2d51e6d38b98@tuxon.dev> (raw)
In-Reply-To: <20261017-weightless-poetic-mayfly-bbdf75-mkl@pengutronix.de>

Hi, Mark,

On 10/17/26 23:01, Marc Kleine-Budde wrote:
>>>>    /* Helper functions */
>>>> @@ -2190,13 +2196,20 @@ static int rcar_canfd_probe(struct platform_device *pdev)
>>>>    	 */
>>>>    	gpriv->can_clk = devm_clk_get(dev, "can_clk");
>>>>    	if (IS_ERR(gpriv->can_clk) || (clk_get_rate(gpriv->can_clk) == 0)) {
>>>               ^^^^^^^^^^^^^^^^^^^^^
>>>
>>> As sashiko.dev [1] pointed out here's no check for -EPROBE_DEFER.
>> This looks to me a pre-existing issue.
>>
>> The newly added support does:
>>
>> fcan_freq = clk_get_rate(gpriv->clkp);
>>
>> At the time this is executed the clkp was already checked against any errors
>                                     ^^^^
>> (above) including -EPROBE_DEFER.
> It's not about "clkp".
> 
> What's missing is, that "gpriv->can_clk" is checked against IS_ERR():
> 
>>>>    	gpriv->can_clk = devm_clk_get(dev, "can_clk");
>>>>    	if (IS_ERR(gpriv->can_clk) || (clk_get_rate(gpriv->can_clk) == 0)) {
> but if it's a -EPROBE_DEFER, IS_ERR() returns true. I think in this case
> you want to return with dev_err_probe().
> 
> There's also a difference between "can_clk" not found (e.g. not
> configured in DT), and there was a problem with "can_clk". I don't know
> if this is important for this driver, but if you want to distinguish
> between those, you can use devm_clk_get_optional(). I will return NULL
> if the clock is not found, -EPROBE_DEFER if not available yet, the clock
> or, in case of an error -errno.
> 
> Thinking about it: if "can_clk" is not available, I would consider it
> intentional, so the driver should use the other clock. If the clock has
> an error, the driver should not fallback to a probably untested clock
> configuration.

         /* fCAN clock: Pick External clock. If not available fallback to
          * CANFD clock
          */
         gpriv->can_clk = devm_clk_get(dev, "can_clk");
         if (IS_ERR(gpriv->can_clk) || (clk_get_rate(gpriv->can_clk) == 0)) {

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, ...);

The devm_clk_get_optional() would involve changing more lines:

-       gpriv->can_clk = devm_clk_get(dev, "can_clk");
-       if (IS_ERR(gpriv->can_clk) || (clk_get_rate(gpriv->can_clk) == 0)) {
+       gpriv->can_clk = devm_clk_get_optional(dev, "can_clk");
+       if (ERR_PTR(gpriv->can_clk) == -EPROBE_DEFER)
+               return dev_err_probe(dev, -EPROBE_DEFER, "cannot get can_clk");
+
+       if (IS_ERR_OR_NULL(gpriv->can_clk) || (clk_get_rate(gpriv->can_clk) == 0)) {
                 gpriv->can_clk = devm_clk_get(dev, "canfd");
                 if (IS_ERR(gpriv->can_clk))
                         return dev_err_probe(dev, PTR_ERR(gpriv->can_clk),

Please let me know otherwise.

Thank you,
Claudiu

  reply	other threads:[~2026-10-19  9:58 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-02 14:15 [PATCH v4 0/7] can: rcar_canfd: Add support for Renesas RZ/G3S Claudiu Beznea
2026-09-02 14:15 ` [PATCH v4 1/7] dt-bindings: can: renesas,rcar-canfd: Document RZ/G3S SoC Claudiu Beznea
2026-10-16 13:34   ` Marc Kleine-Budde
2026-10-19  7:24     ` Biju Das
2026-10-19  8:01       ` Claudiu Beznea
2026-10-19  8:26         ` Biju Das
2026-09-02 14:15 ` [PATCH v4 2/7] can: rcar_canfd: Fix typos in macro names Claudiu Beznea
2026-09-02 14:15 ` [PATCH v4 3/7] can: rcar_canfd: Allow the CAN FD clock to be sourced from fck Claudiu Beznea
2026-10-16 13:39   ` Marc Kleine-Budde
2026-10-16 18:07     ` Claudiu Beznea
2026-10-17 20:01       ` Marc Kleine-Budde
2026-10-19  9:58         ` claudiu beznea [this message]
2026-10-19 10:21           ` Marc Kleine-Budde
2026-10-19 10:36           ` claudiu beznea
2026-10-19 10:42             ` Marc Kleine-Budde
2026-09-02 14:15 ` [PATCH v4 4/7] can: rcar_canfd: Do not set registers selecting the CAN mode Claudiu Beznea
2026-09-02 14:15 ` [PATCH v4 5/7] can: rcar_canfd: Add support for Renesas RZ/G3S Claudiu Beznea
2026-09-02 14:15 ` [PATCH v4 6/7] arm64: dts: renesas: r9a08g045: Add CAN-FD node Claudiu Beznea
2026-09-02 14:15 ` [PATCH v4 7/7] arm64: dts: renesas: rzg3s-smarc: Enable CAN-FD Claudiu Beznea
2026-09-29 14:19 ` [PATCH v4 0/7] can: rcar_canfd: Add support for Renesas RZ/G3S Marc Kleine-Budde

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4a9e32a8-8a2e-4b70-8057-2d51e6d38b98@tuxon.dev \
    --to=claudiu.beznea@tuxon.dev \
    --cc=biju.das.jz@bp.renesas.com \
    --cc=claudiu.beznea.uj@bp.renesas.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=fabrizio.castro.jz@renesas.com \
    --cc=geert+renesas@glider.be \
    --cc=krzk+dt@kernel.org \
    --cc=linux-can@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=magnus.damm@gmail.com \
    --cc=mailhol@kernel.org \
    --cc=mkl@pengutronix.de \
    --cc=robh@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®