[PATCH net-next 0/12] pull-request: can-next 2026-11-10

[PATCH net-next 0/12] pull-request: can-next 2026-11-10

[Marc Kleine-Budde]

Hello netdev-team,

this is a pull request of 12 patches for net-next/main.

Claudiu Beznea contributes 7 patches for the rcar_canfd driver to add
support for Renesas RZ/G3S.

Krzysztof Kozlowski's patch updates the renesas,rcar-canfd DT bindings
to restrict the resets in top-level.

Biju Das's series of 4 patches add support for Renesas RZ/G3L CANFD to
the rcar_canfd driver.

regards,
Marc

---

The following changes since commit d26955e57475434b59d43ba372b2a50d33d5e0ed:

  net: mvpp2: fix double free of the replaced rule in mvpp2_ethtool_cls_rule_ins() (2026-11-09 17:38:20 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git tags/linux-can-next-for-7.5-20261110

for you to fetch changes up to ae842166410d5f42ed3257c735dd2ea3de931f5c:

  Merge patch series "Add support for Renesas RZ/G3L CANFD" (2026-11-10 12:21:16 +0100)

----------------------------------------------------------------
linux-can-next-for-7.5-20261110

----------------------------------------------------------------
Biju Das (4):
      dt-bindings: can: renesas,rcar-canfd: Simplify renesas,no-can-fd description
      can: rcar_canfd: Document that RZ/G3S has no Classical CAN mode
      dt-bindings: can: renesas,rcar-canfd: Document RZ/G3L SoC
      can: rcar_canfd: Add support for Renesas RZ/G3L

Claudiu Beznea (7):
      dt-bindings: can: renesas,rcar-canfd: Document RZ/G3S SoC
      can: rcar_canfd: Fix typos in macro names
      can: rcar_canfd: Allow the CAN FD clock to be sourced from fck
      can: rcar_canfd: Do not set registers selecting the CAN mode
      can: rcar_canfd: Add support for Renesas RZ/G3S
      can: rcar_canfd: Check can_clk request for errors
      can: rcar_canfd: Use DT clock names in the probe message

Krzysztof Kozlowski (1):
      dt-bindings: can: renesas,rcar-canfd: Restrict resets in top-level

Marc Kleine-Budde (3):
      Merge patch series "can: rcar_canfd: Add support for Renesas RZ/G3S"
      Merge patch series "can: rcar_canfd: Follow-up patches for RZ/G3S"
      Merge patch series "Add support for Renesas RZ/G3L CANFD"

 .../bindings/net/can/renesas,rcar-canfd.yaml       |  57 +++++++++--
 drivers/net/can/rcar/rcar_canfd.c                  | 109 +++++++++++++++++----
 2 files changed, 137 insertions(+), 29 deletions(-)

[PATCH net-next 01/12] dt-bindings: can: renesas,rcar-canfd: Document RZ/G3S SoC

[Marc Kleine-Budde]

From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>

The CAN FD controller found on the Renesas RZ/G3S SoC is largely compatible
with the variant present on the RZ/G3E SoC. The main differences are:
- the RZ/G3S provides only two CAN FD channels
- the RZ/G3S supports only CAN FD operation; the Channel n CAN FD
  Configuration Register does not implement the bits used to select
  classical CAN-only mode (bit 30) or CAN FD-only mode (bit 28);
  consequently, bit 31 (CAN FD Frame Distinction Enable) of the same
  register is also not implemented
- some bits in several registers (mainly reserved or status bits) are
  read-write on the RZ/G3S but read-only on the RZ/G3E; their behavior is
  otherwise identical: the bits read back as 0 on both SoCs and software
  is allowed to write only 0 to them on the RZ/G3S
- the RZ/G3S provides 256 acceptance filters, compared to 768 on the
  RZ/G3E
- the RZ/G3S can use PCLK clock as the CAN FD clock source through an
  internal clock divider, while also supporting an external CAN FD clock
  source

Since:
- the SoC clock generator provides to the CAN IP only the peripheral and
  the RAM clocks
- when sourced from the peripheral clock, the CAN-FD clock is obtained
  inside the IP itself by dividing the peripheral clock
- the assigned-clocks and assigned-clock-rates properties are specific to
  the CAN-FD clock
the assigned-clocks and assigned-clock-rates properties were dropped from
the required properties list of the Renesas RZ/G3S SoC.

Add documentation for the Renesas RZ/G3S SoC.

Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Link: https://patch.msgid.link/20260902141544.565763-2-claudiu.beznea+renesas@tuxon.dev
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
 .../bindings/net/can/renesas,rcar-canfd.yaml  | 20 +++++++++++++++++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
index b9d9dd7a7967..bbaaef8f4282 100644
--- a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
+++ b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
@@ -13,6 +13,7 @@ properties:
   compatible:
     oneOf:
       - enum:
+          - renesas,r9a08g045-canfd        # RZ/G3S
           - renesas,r9a09g047-canfd        # RZ/G3E
           - renesas,r9a09g077-canfd        # RZ/T2H
 
@@ -185,8 +186,6 @@ required:
   - clocks
   - clock-names
   - power-domains
-  - assigned-clocks
-  - assigned-clock-rates
   - channel0
   - channel1
 
@@ -198,6 +197,7 @@ allOf:
         compatible:
           contains:
             enum:
+              - renesas,r9a08g045-canfd
               - renesas,rzg2l-canfd
     then:
       properties:
@@ -266,6 +266,7 @@ allOf:
         compatible:
           contains:
             enum:
+              - renesas,r9a08g045-canfd
               - renesas,r9a09g077-canfd
               - renesas,rcar-gen3-canfd
               - renesas,rzg2l-canfd
@@ -330,6 +331,7 @@ allOf:
         compatible:
           contains:
             enum:
+              - renesas,r9a08g045-canfd
               - renesas,r9a09g047-canfd
               - renesas,rzg2l-canfd
     then:
@@ -350,6 +352,20 @@ allOf:
       properties:
         reset-names: false
 
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: renesas,r9a08g045-canfd
+    then:
+      properties:
+        renesas,no-can-fd: false
+        renesas,fd-only: false
+    else:
+      required:
+        - assigned-clocks
+        - assigned-clock-rates
+
 unevaluatedProperties: false
 
 examples:

base-commit: d26955e57475434b59d43ba372b2a50d33d5e0ed
-- 
2.53.0

Re: [PATCH net-next 01/12] dt-bindings: can: renesas,rcar-canfd: Document RZ/G3S SoC

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Low] dt-bindings: can: renesas,rcar-canfd: unwieldy per-compatible
  conditionals
--

commit 5428d12c7ddcccf614fa8a3231cb0f54fd8f9de0
Author: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>

dt-bindings: can: renesas,rcar-canfd: Document RZ/G3S SoC

This commit adds the renesas,r9a08g045-canfd compatible string for the
Renesas RZ/G3S SoC and updates the conditional schema constraints for its
channel, reset, operating mode, and clock differences.

Link: https://patch.msgid.link/20260902141544.565763-2-claudiu.beznea+renesas@tuxon.dev

> diff --git a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
> index b9d9dd7a79676..bbaaef8f4282e 100644
> --- a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
> +++ b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml

[ ... ]

> @@ -185,8 +186,6 @@ required:
>    - clocks
>    - clock-names
>    - power-domains
> -  - assigned-clocks
> -  - assigned-clock-rates
>    - channel0
>    - channel1
>  
> @@ -198,6 +197,7 @@ allOf:
>          compatible:
>            contains:
>              enum:
> +              - renesas,r9a08g045-canfd
>                - renesas,rzg2l-canfd
>      then:
>        properties:
> @@ -266,6 +266,7 @@ allOf:
>          compatible:
>            contains:
>              enum:
> +              - renesas,r9a08g045-canfd
>                - renesas,r9a09g077-canfd
>                - renesas,rcar-gen3-canfd
>                - renesas,rzg2l-canfd
> @@ -330,6 +331,7 @@ allOf:
>          compatible:
>            contains:
>              enum:
> +              - renesas,r9a08g045-canfd
>                - renesas,r9a09g047-canfd
>                - renesas,rzg2l-canfd
>      then:
> @@ -350,6 +352,20 @@ allOf:
>        properties:
>          reset-names: false
>  
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            const: renesas,r9a08g045-canfd
> +    then:
> +      properties:
> +        renesas,no-can-fd: false
> +        renesas,fd-only: false
> +    else:
> +      required:
> +        - assigned-clocks
> +        - assigned-clock-rates
> +
>  unevaluatedProperties: false
>  
>  examples:

[Severity: Low]
This isn't a bug, but adding renesas,r9a08g045-canfd requires touching
three separate if-then blocks in allOf and adding a 14th conditional block
with an else branch to move assigned-clocks and assigned-clock-rates out of
the top-level required list.  With allOf now spanning 14 per-compatible
conditional blocks to toggle interrupts, resets, channels, operating modes,
and clock properties across variants, would it be cleaner to split the
diverging variants into a separate binding schema document instead of
adding more conditionals here?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261110115112.3807247-1-mkl@pengutronix.de?part=1

Re: [PATCH net-next 01/12] dt-bindings: can: renesas,rcar-canfd: Document RZ/G3S SoC

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found more severe
issue(s) in other patches of this series. This mail is only an FYI, in case
you want to address the nit picks below when you respin.

Low priority / nit picks for your consideration:

- [Low] In this patch's tree state, the binding documents
  `renesas,r9a08g045-canfd` as a standalone compatible with no fallback,…

Pre-existing issues:
- [Low] The concern says the RZ/G3S compatible `renesas,r9a08g045-canfd`
  gets the unchanged top-level `clocks`/`clock-names` schema, and that…

--

dt-bindings: can: renesas,rcar-canfd: Document RZ/G3S SoC

This adds the renesas,r9a08g045-canfd compatible for the RZ/G3S CAN FD
controller and adds it to the existing allOf conditional blocks. It also
moves the assigned-clocks/assigned-clock-rates requirement into a new
conditional that exempts RZ/G3S, and disallows renesas,no-can-fd and
renesas,fd-only for RZ/G3S.

Link: https://patch.msgid.link/20260902141544.565763-2-claudiu.beznea+renesas@tuxon.dev

> diff --git a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
> index b9d9dd7a79676..bbaaef8f4282e 100644
> --- a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
> +++ b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
> @@ -13,6 +13,7 @@ properties:
>    compatible:
>      oneOf:
>        - enum:
> +          - renesas,r9a08g045-canfd        # RZ/G3S
>            - renesas,r9a09g047-canfd        # RZ/G3E
>            - renesas,r9a09g077-canfd        # RZ/T2H

[Severity: Low]
At this point in the series, does anything bind to this compatible?

The patch adds it as a standalone string with no fallback. However,
rcar_canfd_of_table[] in drivers/net/can/rcar/rcar_canfd.c has no
renesas,r9a08g045-canfd entry yet. An RZ/G3S node that passes validation
would therefore not probe.

A later patch in the series, "can: rcar_canfd: Add support for Renesas
RZ/G3S", appears to fix this by adding:

    { .compatible = "renesas,r9a08g045-canfd", .data = &r9a08g045_hw_info },

[ ... ]

> @@ -350,6 +352,20 @@ allOf:
>        properties:
>          reset-names: false
>  
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            const: renesas,r9a08g045-canfd
> +    then:
> +      properties:
> +        renesas,no-can-fd: false
> +        renesas,fd-only: false
> +    else:
> +      required:
> +        - assigned-clocks
> +        - assigned-clock-rates

[Severity: Low]
This is a pre-existing issue, but should this block also narrow
clock-names for RZ/G3S? The top-level clock-names still accepts both
forms:

  clock-names:
    oneOf:
      - items:
          - const: fck
          - const: canfd
          - const: can_clk
      - items:
          - const: fck
          - const: ram_clk
          - const: can_clk

No allOf entry picks one of these forms per compatible.

The RZ/G3S CPG only supplies the peripheral and RAM clocks. Even so, an
RZ/G3S node that uses the canfd form would still pass dt_binding_check.
The driver would then get a NULL clk_ram from devm_clk_get_optional(),
and the RAM clock would never be enabled.

The renesas,rzg2l-canfd and renesas,r9a09g047-canfd compatibles already
have the same gap.

Requiring the third can_clk entry looks fine, though. The internal
divider setup can be described with a 0 Hz can_clk fixed-clock, as in
r9a07g044.dtsi. The fck fallback that "can: rcar_canfd: Allow the CAN FD
clock to be sourced from fck" adds to rcar_canfd_probe() then handles
that case.

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261110115112.3807247-2-mkl%40pengutronix.de

[PATCH net-next 02/12] can: rcar_canfd: Fix typos in macro names

[Marc Kleine-Budde]

From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>

The bits 1..0 of the Channel n Control Register are named CHMDC (Channel
Mode select). Fix typos in macro names by replacing DMC with MDC.

Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Link: https://patch.msgid.link/20260902141544.565763-3-claudiu.beznea+renesas@tuxon.dev
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
 drivers/net/can/rcar/rcar_canfd.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/net/can/rcar/rcar_canfd.c b/drivers/net/can/rcar/rcar_canfd.c
index fcc37b73ed43..b7c4fe3477ac 100644
--- a/drivers/net/can/rcar/rcar_canfd.c
+++ b/drivers/net/can/rcar/rcar_canfd.c
@@ -132,9 +132,9 @@
 #define RCANFD_CCTR_BEIE		BIT(8)
 #define RCANFD_CCTR_CSLPR		BIT(2)
 #define RCANFD_CCTR_CHMDC_MASK		(0x3)
-#define RCANFD_CCTR_CHDMC_COPM		(0x0)
-#define RCANFD_CCTR_CHDMC_CRESET	(0x1)
-#define RCANFD_CCTR_CHDMC_CHLT		(0x2)
+#define RCANFD_CCTR_CHMDC_COPM		(0x0)
+#define RCANFD_CCTR_CHMDC_CRESET	(0x1)
+#define RCANFD_CCTR_CHMDC_CHLT		(0x2)
 
 /* RSCFDnCFDCmSTS / RSCFDnCmSTS */
 #define RCANFD_CSTS_COMSTS		BIT(7)
@@ -828,7 +828,7 @@ static int rcar_canfd_reset_controller(struct rcar_canfd_global *gpriv)
 
 		rcar_canfd_update_bit(gpriv->base, RCANFD_CCTR(ch),
 				      RCANFD_CCTR_CHMDC_MASK,
-				      RCANFD_CCTR_CHDMC_CRESET);
+				      RCANFD_CCTR_CHMDC_CRESET);
 
 		/* Ensure Channel reset mode */
 		err = readl_poll_timeout((gpriv->base + RCANFD_CSTS(ch)), sts,
@@ -1504,7 +1504,7 @@ static int rcar_canfd_start(struct net_device *ndev)
 
 	/* Set channel to Operational mode */
 	rcar_canfd_update_bit(priv->base, RCANFD_CCTR(ch),
-			      RCANFD_CCTR_CHMDC_MASK, RCANFD_CCTR_CHDMC_COPM);
+			      RCANFD_CCTR_CHMDC_MASK, RCANFD_CCTR_CHMDC_COPM);
 
 	/* Verify channel mode change */
 	err = readl_poll_timeout((priv->base + RCANFD_CSTS(ch)), sts,
@@ -1578,7 +1578,7 @@ static void rcar_canfd_stop(struct net_device *ndev)
 
 	/* Transition to channel reset mode  */
 	rcar_canfd_update_bit(priv->base, RCANFD_CCTR(ch),
-			      RCANFD_CCTR_CHMDC_MASK, RCANFD_CCTR_CHDMC_CRESET);
+			      RCANFD_CCTR_CHMDC_MASK, RCANFD_CCTR_CHMDC_CRESET);
 
 	/* Check Channel reset mode */
 	err = readl_poll_timeout((priv->base + RCANFD_CSTS(ch)), sts,
-- 
2.53.0

Re: [PATCH net-next 02/12] can: rcar_canfd: Fix typos in macro names

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found no new issues
in this patch, but noticed 1 related pre-existing issue it does not
introduce:
- [Medium] can: rcar_canfd: missing hardware reset on rcar_canfd_start()
  timeout [1]
--

commit 683df0154ce2ae541ee019a38062ac1a2b103eac
Author: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>

can: rcar_canfd: Fix typos in macro names

This commit renames the RCANFD_CCTR_CHDMC_* channel mode macros to
RCANFD_CCTR_CHMDC_* to match the hardware register documentation.

Link: https://patch.msgid.link/20260902141544.565763-3-claudiu.beznea+renesas@tuxon.dev

> diff --git a/drivers/net/can/rcar/rcar_canfd.c b/drivers/net/can/rcar/rcar_canfd.c
> index fcc37b73ed436..b7c4fe3477ac5 100644
> --- a/drivers/net/can/rcar/rcar_canfd.c
> +++ b/drivers/net/can/rcar/rcar_canfd.c

[ ... ]

> @@ -1504,7 +1504,7 @@ static int rcar_canfd_start(struct net_device *ndev)
>  
>  	/* Set channel to Operational mode */
>  	rcar_canfd_update_bit(priv->base, RCANFD_CCTR(ch),
> -			      RCANFD_CCTR_CHMDC_MASK, RCANFD_CCTR_CHDMC_COPM);
> +			      RCANFD_CCTR_CHMDC_MASK, RCANFD_CCTR_CHMDC_COPM);
>  
>  	/* Verify channel mode change */
>  	err = readl_poll_timeout((priv->base + RCANFD_CSTS(ch)), sts,

[Severity: Medium]
This problem wasn't introduced by this patch, but does the error path in
rcar_canfd_start() [1] leave RCANFD_CCTR_CHMDC_COPM pending in
hardware if readl_poll_timeout() times out?

Neither the fail_mode_change path in rcar_canfd_start() nor the out_close
unwind path in rcar_canfd_open() transitions the channel back to
RCANFD_CCTR_CHMDC_CRESET:

drivers/net/can/rcar/rcar_canfd.c:rcar_canfd_start() {
	...
	err = readl_poll_timeout((priv->base + RCANFD_CSTS(ch)), sts,
				 (sts & RCANFD_CSTS_COMSTS), 2, 500000);
	if (err) {
		netdev_err(ndev, "channel %u communication state failed\n", ch);
		goto fail_mode_change;
	}
	...
fail_mode_change:
	rcar_canfd_disable_channel_interrupts(priv);
	return err;
}

On a later open attempt, rcar_canfd_set_bittiming() runs while the channel
is no longer in reset mode, so the hardware ignores the bit-timing
configuration writes.

[1] https://sashiko.dev/#/bug/linux-f4b05dc8-33ba-4ce4-8f99-3c391b0fc79a

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261110115112.3807247-1-mkl@pengutronix.de?part=2

[PATCH net-next 03/12] can: rcar_canfd: Allow the CAN FD clock to be sourced from fck

[Marc Kleine-Budde]

From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>

On the Renesas RZ/G3S, the CAN FD clock can be sourced either from fck
(the peripheral clock) or from an external clock (can_clk). When fck is
used, it is divided internally by the CAN FD controller.

Adjust the existing canfd clock handling code to support the RZ/G3S CAN.

The existing struct rcar_canfd_hw_info instances were updated to address
the request in the Link discussion.

Link: https://lore.kernel.org/all/1d9719e3-10ff-4cd8-b729-55fea93c37ce@wanadoo.fr
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Link: https://patch.msgid.link/20260902141544.565763-4-claudiu.beznea+renesas@tuxon.dev
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
 drivers/net/can/rcar/rcar_canfd.c | 23 ++++++++++++++++++-----
 1 file changed, 18 insertions(+), 5 deletions(-)

diff --git a/drivers/net/can/rcar/rcar_canfd.c b/drivers/net/can/rcar/rcar_canfd.c
index b7c4fe3477ac..f9173774387f 100644
--- a/drivers/net/can/rcar/rcar_canfd.c
+++ b/drivers/net/can/rcar/rcar_canfd.c
@@ -444,6 +444,7 @@ struct rcar_canfd_hw_info {
 	unsigned ch_interface_mode:1;	/* Has channel interface mode */
 	unsigned shared_can_regs:1;	/* Has shared classical can registers */
 	unsigned external_clk:1;	/* Has external clock */
+	unsigned fcan_pclk:1;		/* Has fcan sourced from pclk. */
 };
 
 /* Channel priv data */
@@ -617,6 +618,7 @@ static const struct rcar_canfd_hw_info rcar_gen3_hw_info = {
 	.ch_interface_mode = 0,
 	.shared_can_regs = 0,
 	.external_clk = 1,
+	.fcan_pclk = 0,
 };
 
 static const struct rcar_canfd_hw_info rcar_gen4_hw_info = {
@@ -634,6 +636,7 @@ static const struct rcar_canfd_hw_info rcar_gen4_hw_info = {
 	.ch_interface_mode = 1,
 	.shared_can_regs = 1,
 	.external_clk = 1,
+	.fcan_pclk = 0,
 };
 
 static const struct rcar_canfd_hw_info rzg2l_hw_info = {
@@ -651,6 +654,7 @@ static const struct rcar_canfd_hw_info rzg2l_hw_info = {
 	.ch_interface_mode = 0,
 	.shared_can_regs = 0,
 	.external_clk = 1,
+	.fcan_pclk = 0,
 };
 
 static const struct rcar_canfd_hw_info r9a09g047_hw_info = {
@@ -668,6 +672,7 @@ static const struct rcar_canfd_hw_info r9a09g047_hw_info = {
 	.ch_interface_mode = 1,
 	.shared_can_regs = 1,
 	.external_clk = 0,
+	.fcan_pclk = 0,
 };
 
 static const struct rcar_canfd_hw_info r9a09g077_hw_info = {
@@ -685,6 +690,7 @@ static const struct rcar_canfd_hw_info r9a09g077_hw_info = {
 	.ch_interface_mode = 1,
 	.shared_can_regs = 1,
 	.external_clk = 1,
+	.fcan_pclk = 0,
 };
 
 /* 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)) {
-		gpriv->can_clk = devm_clk_get(dev, "canfd");
-		if (IS_ERR(gpriv->can_clk))
-			return dev_err_probe(dev, PTR_ERR(gpriv->can_clk),
-					     "cannot get canfd clock\n");
+		if (info->fcan_pclk) {
+			fcan_freq = clk_get_rate(gpriv->clkp);
+			gpriv->can_clk = NULL;
+		} else {
+			gpriv->can_clk = devm_clk_get(dev, "canfd");
+			if (IS_ERR(gpriv->can_clk))
+				return dev_err_probe(dev, PTR_ERR(gpriv->can_clk),
+						     "cannot get canfd clock\n");
+
+			fcan_freq = clk_get_rate(gpriv->can_clk);
+		}
 
 		/* CANFD clock may be further divided within the IP */
-		fcan_freq = clk_get_rate(gpriv->can_clk) / info->postdiv;
+		fcan_freq /= info->postdiv;
 	} else {
 		fcan_freq = clk_get_rate(gpriv->can_clk);
 		gpriv->extclk = gpriv->info->external_clk;
-- 
2.53.0

Re: [PATCH net-next 03/12] can: rcar_canfd: Allow the CAN FD clock to be sourced from fck

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found no new issues
in this patch, but noticed 1 related pre-existing issue it does not
introduce:
- [Critical] can: rcar_canfd: use-after-free in
  rcar_canfd_channel_remove() [1]
--

commit 1df4cf4f9a1348dd6433254810179fc111ec5e51
Author: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>

can: rcar_canfd: Allow the CAN FD clock to be sourced from fck

This commit adds a struct rcar_canfd_hw_info flag to allow sourcing the
CAN FD clock from the peripheral clock (fck) on Renesas RZ/G3S.

Link: https://lore.kernel.org/all/1d9719e3-10ff-4cd8-b729-55fea93c37ce@wanadoo.fr
Link: https://patch.msgid.link/20260902141544.565763-4-claudiu.beznea+renesas@tuxon.dev

> diff --git a/drivers/net/can/rcar/rcar_canfd.c b/drivers/net/can/rcar/rcar_canfd.c
> index b7c4fe3477ac5..f9173774387fa 100644
> --- a/drivers/net/can/rcar/rcar_canfd.c
> +++ b/drivers/net/can/rcar/rcar_canfd.c

[ ... ]

> @@ -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)) {
> -		gpriv->can_clk = devm_clk_get(dev, "canfd");
> -		if (IS_ERR(gpriv->can_clk))
> -			return dev_err_probe(dev, PTR_ERR(gpriv->can_clk),
> -					     "cannot get canfd clock\n");
> +		if (info->fcan_pclk) {
> +			fcan_freq = clk_get_rate(gpriv->clkp);
> +			gpriv->can_clk = NULL;
> +		} else {
> +			gpriv->can_clk = devm_clk_get(dev, "canfd");
> +			if (IS_ERR(gpriv->can_clk))
> +				return dev_err_probe(dev, PTR_ERR(gpriv->can_clk),
> +						     "cannot get canfd clock\n");
> +
> +			fcan_freq = clk_get_rate(gpriv->can_clk);
> +		}
>  
>  		/* CANFD clock may be further divided within the IP */
> -		fcan_freq = clk_get_rate(gpriv->can_clk) / info->postdiv;
> +		fcan_freq /= info->postdiv;
>  	} else {
>  		fcan_freq = clk_get_rate(gpriv->can_clk);
>  		gpriv->extclk = gpriv->info->external_clk;

[Severity: Critical]
This problem wasn't introduced by this patch, but can a failure in
rcar_canfd_channel_probe() lead to a use-after-free and double free of ndev
[1] during fail_channel cleanup in rcar_canfd_probe()?

drivers/net/can/rcar/rcar_canfd.c:rcar_canfd_channel_probe() {
    ...
	gpriv->ch[priv->channel] = priv;
	err = register_candev(ndev);
	if (err) {
		dev_err(dev, "register_candev() failed: %pe\n", ERR_PTR(err));
		goto fail_candev;
	}
    ...
fail_candev:
	netif_napi_del(&priv->napi);
fail:
	free_candev(ndev);
	return err;
}

When register_candev() fails, rcar_canfd_channel_probe() frees ndev (which
contains priv) without clearing gpriv->ch[priv->channel].  rcar_canfd_probe()
then jumps to fail_channel and calls rcar_canfd_channel_remove(), which sees
the dangling gpriv->ch[ch] pointer and passes priv->ndev to
unregister_candev() and free_candev() a second time.

[1] https://sashiko.dev/#/bug/linux-5ba990d8-8cef-4735-85ff-107958a3daf2

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261110115112.3807247-1-mkl@pengutronix.de?part=3

Re: [PATCH net-next 03/12] can: rcar_canfd: Allow the CAN FD clock to be sourced from fck

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found more severe
issue(s) in other patches of this series. This mail is only an FYI, in case
you want to address the nit picks below when you respin.

Low priority / nit picks for your consideration:

- [Low] This patch adds a third fCAN clock source in rcar_canfd_probe().

--

can: rcar_canfd: Allow the CAN FD clock to be sourced from fck

This commit adds a new fcan_pclk hardware feature bit to struct
rcar_canfd_hw_info. On the RZ/G3S, fCAN can then come from the peripheral
clock (fck) when no usable external can_clk is present. Existing hw_info
instances are updated to set fcan_pclk = 0 explicitly.

Link: https://lore.kernel.org/all/1d9719e3-10ff-4cd8-b729-55fea93c37ce@wanadoo.fr
Link: https://patch.msgid.link/20260902141544.565763-4-claudiu.beznea+renesas@tuxon.dev

> diff --git a/drivers/net/can/rcar/rcar_canfd.c b/drivers/net/can/rcar/rcar_canfd.c
> index b7c4fe3477ac5..f9173774387fa 100644
> --- a/drivers/net/can/rcar/rcar_canfd.c
> +++ b/drivers/net/can/rcar/rcar_canfd.c

[ ... ]

> @@ -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)) {
> -		gpriv->can_clk = devm_clk_get(dev, "canfd");
> -		if (IS_ERR(gpriv->can_clk))
> -			return dev_err_probe(dev, PTR_ERR(gpriv->can_clk),
> -					     "cannot get canfd clock\n");
> +		if (info->fcan_pclk) {
> +			fcan_freq = clk_get_rate(gpriv->clkp);
> +			gpriv->can_clk = NULL;

[Severity: Low]
This isn't a bug, but should the comment on the extclk field in struct
rcar_canfd_global be updated as well? It still describes a two-way choice:

    bool extclk;			/* CANFD or Ext clock */

With this new branch, extclk stays false while the fCAN source is fck,
not the "canfd" clock. So on fcan_pclk SoCs, extclk == false no longer
means "CANFD clock".

Later patches in the series update the fallback comment above this block
in rcar_canfd_probe(). The commit "can: rcar_canfd: Use DT clock names in
the probe message" also updates the dev_info() string to report "fck".
The extclk field comment is still unchanged at the end of the series,
though.

> +		} else {
> +			gpriv->can_clk = devm_clk_get(dev, "canfd");
> +			if (IS_ERR(gpriv->can_clk))
> +				return dev_err_probe(dev, PTR_ERR(gpriv->can_clk),
> +						     "cannot get canfd clock\n");
> +
> +			fcan_freq = clk_get_rate(gpriv->can_clk);
> +		}
>  
>  		/* CANFD clock may be further divided within the IP */
> -		fcan_freq = clk_get_rate(gpriv->can_clk) / info->postdiv;
> +		fcan_freq /= info->postdiv;
>  	} else {
>  		fcan_freq = clk_get_rate(gpriv->can_clk);
>  		gpriv->extclk = gpriv->info->external_clk;

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261110115112.3807247-2-mkl%40pengutronix.de

[PATCH net-next 04/12] can: rcar_canfd: Do not set registers selecting the CAN mode

[Marc Kleine-Budde]

From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>

The bits 30 (classical CAN-only mode) and 28 (FD-only enable) of the
Channel n CAN-FD Configuration Register of the Renesas RZ/G3S SoC are not
available. The IP supports only CAN-FD mode. RZ/G3S HW manual (revision
1.30) specify the bits are read as zero and the write value should always
be zero.

Add the fixed_canfd flag in struct rcar_canfd_hw_info to cover RZ/G3S
and avoid writing to unavailable bits.

The existing struct rcar_canfd_hw_info instances were updated to address
the request in the Link discussion.

Commit prepares for the addition of the Renesas RZ/G3S SoC.

Link: https://lore.kernel.org/all/1d9719e3-10ff-4cd8-b729-55fea93c37ce@wanadoo.fr
Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Link: https://patch.msgid.link/20260902141544.565763-5-claudiu.beznea+renesas@tuxon.dev
[mkl: update flag name in patch description]
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
 drivers/net/can/rcar/rcar_canfd.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/net/can/rcar/rcar_canfd.c b/drivers/net/can/rcar/rcar_canfd.c
index f9173774387f..ac5d5959d8e4 100644
--- a/drivers/net/can/rcar/rcar_canfd.c
+++ b/drivers/net/can/rcar/rcar_canfd.c
@@ -445,6 +445,7 @@ struct rcar_canfd_hw_info {
 	unsigned shared_can_regs:1;	/* Has shared classical can registers */
 	unsigned external_clk:1;	/* Has external clock */
 	unsigned fcan_pclk:1;		/* Has fcan sourced from pclk. */
+	unsigned fixed_canfd:1;		/* Has mode fixed to canfd. */
 };
 
 /* Channel priv data */
@@ -619,6 +620,7 @@ static const struct rcar_canfd_hw_info rcar_gen3_hw_info = {
 	.shared_can_regs = 0,
 	.external_clk = 1,
 	.fcan_pclk = 0,
+	.fixed_canfd = 0,
 };
 
 static const struct rcar_canfd_hw_info rcar_gen4_hw_info = {
@@ -637,6 +639,7 @@ static const struct rcar_canfd_hw_info rcar_gen4_hw_info = {
 	.shared_can_regs = 1,
 	.external_clk = 1,
 	.fcan_pclk = 0,
+	.fixed_canfd = 0,
 };
 
 static const struct rcar_canfd_hw_info rzg2l_hw_info = {
@@ -655,6 +658,7 @@ static const struct rcar_canfd_hw_info rzg2l_hw_info = {
 	.shared_can_regs = 0,
 	.external_clk = 1,
 	.fcan_pclk = 0,
+	.fixed_canfd = 0,
 };
 
 static const struct rcar_canfd_hw_info r9a09g047_hw_info = {
@@ -673,6 +677,7 @@ static const struct rcar_canfd_hw_info r9a09g047_hw_info = {
 	.shared_can_regs = 1,
 	.external_clk = 0,
 	.fcan_pclk = 0,
+	.fixed_canfd = 0,
 };
 
 static const struct rcar_canfd_hw_info r9a09g077_hw_info = {
@@ -691,6 +696,7 @@ static const struct rcar_canfd_hw_info r9a09g077_hw_info = {
 	.shared_can_regs = 1,
 	.external_clk = 1,
 	.fcan_pclk = 0,
+	.fixed_canfd = 0,
 };
 
 /* Helper functions */
@@ -846,6 +852,9 @@ static int rcar_canfd_reset_controller(struct rcar_canfd_global *gpriv)
 		}
 
 		/* Set the controller into appropriate mode */
+		if (gpriv->info->fixed_canfd)
+			continue;
+
 		if (gpriv->info->ch_interface_mode) {
 			/* Do not set CLOE and FDOE simultaneously */
 			if (!gpriv->fdmode) {
-- 
2.53.0

[PATCH net-next 05/12] can: rcar_canfd: Add support for Renesas RZ/G3S

[Marc Kleine-Budde]

From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>

Add support for Renesas RZ/G3S

The Renesas RZ/G3S CAN-FD controller is largely compatible with the
variant found on the Renesas RZ/G3E. The main differences are:
- the RZ/G3S provides 16 AFL pages
- the RZ/G3S supports only two channels
- the RZ/G3S supports only CAN-FD operation and does not implement the
  bits used to select between classical CAN-only and CAN FD-only modes.
- the RZ/G3S includes an internal divider that allows the peripheral
  clock to be used as the CAN FD clock source.

Add support for the Renesas RZ/G3S.

Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Link: https://patch.msgid.link/20260902141544.565763-6-claudiu.beznea+renesas@tuxon.dev
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
 drivers/net/can/rcar/rcar_canfd.c | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/drivers/net/can/rcar/rcar_canfd.c b/drivers/net/can/rcar/rcar_canfd.c
index ac5d5959d8e4..74c3c3f20991 100644
--- a/drivers/net/can/rcar/rcar_canfd.c
+++ b/drivers/net/can/rcar/rcar_canfd.c
@@ -661,6 +661,26 @@ static const struct rcar_canfd_hw_info rzg2l_hw_info = {
 	.fixed_canfd = 0,
 };
 
+static const struct rcar_canfd_hw_info r9a08g045_hw_info = {
+	.nom_bittiming = &rcar_canfd_gen4_nom_bittiming_const,
+	.data_bittiming = &rcar_canfd_gen4_data_bittiming_const,
+	.tdc_const = &rcar_canfd_gen4_tdc_const,
+	.regs = &rcar_gen4_regs,
+	.sh = &rcar_gen4_shift_data,
+	.rnc_field_width = 16,
+	.max_aflpn = 15,
+	.max_cftml = 31,
+	.max_channels = 2,
+	.postdiv = 2,
+	.shared_global_irqs = 0,
+	.multi_channel_irqs = 1,
+	.ch_interface_mode = 1,
+	.shared_can_regs = 1,
+	.external_clk = 1,
+	.fcan_pclk = 1,
+	.fixed_canfd = 1,
+};
+
 static const struct rcar_canfd_hw_info r9a09g047_hw_info = {
 	.nom_bittiming = &rcar_canfd_gen4_nom_bittiming_const,
 	.data_bittiming = &rcar_canfd_gen4_data_bittiming_const,
@@ -2383,6 +2403,7 @@ static DEFINE_SIMPLE_DEV_PM_OPS(rcar_canfd_pm_ops, rcar_canfd_suspend,
 
 static const __maybe_unused struct of_device_id rcar_canfd_of_table[] = {
 	{ .compatible = "renesas,r8a779a0-canfd", .data = &rcar_gen4_hw_info },
+	{ .compatible = "renesas,r9a08g045-canfd", .data = &r9a08g045_hw_info },
 	{ .compatible = "renesas,r9a09g047-canfd", .data = &r9a09g047_hw_info },
 	{ .compatible = "renesas,r9a09g077-canfd", .data = &r9a09g077_hw_info },
 	{ .compatible = "renesas,rcar-gen3-canfd", .data = &rcar_gen3_hw_info },
-- 
2.53.0

Re: [PATCH net-next 05/12] can: rcar_canfd: Add support for Renesas RZ/G3S

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found more severe
issue(s) in other patches of this series. This mail is only an FYI, in case
you want to address the nit picks below when you respin.

Low priority / nit picks for your consideration:

- [Low] Concern: r9a08g045_hw_info sets .fixed_canfd = 1, but
  rcar_canfd_probe() still reads "renesas,no-can-fd" (fdmode = false,…

--

can: rcar_canfd: Add support for Renesas RZ/G3S

This patch adds an r9a08g045_hw_info entry for the RZ/G3S CAN-FD
controller and binds it to the "renesas,r9a08g045-canfd" compatible. The
variant is gen4-like, with two channels, 16 AFL pages, an fcan clock
sourced from pclk, and the operating mode fixed to CAN FD.

Link: https://patch.msgid.link/20260902141544.565763-6-claudiu.beznea+renesas@tuxon.dev

> diff --git a/drivers/net/can/rcar/rcar_canfd.c b/drivers/net/can/rcar/rcar_canfd.c
> index ac5d5959d8e4c..74c3c3f20991f 100644
> --- a/drivers/net/can/rcar/rcar_canfd.c
> +++ b/drivers/net/can/rcar/rcar_canfd.c
> @@ -661,6 +661,26 @@ static const struct rcar_canfd_hw_info rzg2l_hw_info = {
>  	.fixed_canfd = 0,
>  };
>  
> +static const struct rcar_canfd_hw_info r9a08g045_hw_info = {
> +	.nom_bittiming = &rcar_canfd_gen4_nom_bittiming_const,
> +	.data_bittiming = &rcar_canfd_gen4_data_bittiming_const,

[ ... ]

> +	.ch_interface_mode = 1,
> +	.shared_can_regs = 1,
> +	.external_clk = 1,
> +	.fcan_pclk = 1,
> +	.fixed_canfd = 1,
> +};

[Severity: Low]
This isn't a bug as long as the DT follows the binding, but should
rcar_canfd_probe() ignore or reject "renesas,no-can-fd" and
"renesas,fd-only" when info->fixed_canfd is set?

This is the first hw_info with fixed_canfd = 1. Both properties are still
read without checking that flag:

drivers/net/can/rcar/rcar_canfd.c:rcar_canfd_probe() {
    ...
	if (of_property_read_bool(dev->of_node, "renesas,no-can-fd"))
		fdmode = false;			/* Classical CAN only mode */
    ...
	if (of_property_read_bool(dev->of_node, "renesas,fd-only"))
		gpriv->fd_only_mode = true; /* FD-Only mode for CAN-FD */
    ...
}

Meanwhile rcar_canfd_reset_controller() skips the CLOE/FDOE writes, so
the controller stays in CAN FD mode:

	/* Set the controller into appropriate mode */
	if (gpriv->info->fixed_canfd)
		continue;

With "renesas,no-can-fd", fdmode == false makes the rest of the driver
set up classical CAN while the controller is still in CAN FD mode:

  - 8 byte RFPLS/CFPLS in rcar_canfd_configure_rx() and
    rcar_canfd_configure_tx()
  - no RCANFD_GCFG_CMPOC in rcar_canfd_configure_controller()
  - no RCANFD_GCTR_CFMPOFIE in rcar_canfd_enable_global_interrupts()
  - only nominal bit timing in rcar_canfd_channel_probe()

FD frames on the bus would then be dropped silently instead of being
reported as errors.

With "renesas,fd-only", the probe message reports "fd-only" mode, but the
hardware cannot enter that mode.

The binding change for this compatible sets "renesas,no-can-fd: false"
and "renesas,fd-only: false". Only a DT that fails schema validation can
hit this, and the compatible is new, so no existing DTs carry these
properties.

As hardening, could probe force fdmode = true and clear fd_only_mode when
fixed_canfd is set, or fail probe instead?

> +
>  static const struct rcar_canfd_hw_info r9a09g047_hw_info = {
>  	.nom_bittiming = &rcar_canfd_gen4_nom_bittiming_const,
>  	.data_bittiming = &rcar_canfd_gen4_data_bittiming_const,

[ ... ]

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261110115112.3807247-2-mkl%40pengutronix.de

[PATCH net-next 06/12] can: rcar_canfd: Check can_clk request for errors

[Marc Kleine-Budde]

From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>

If the provider of can_clk is not yet probed, devm_clk_get() returns
-EPROBE_DEFER. The driver treats any error as can_clk being absent and
falls back to the other clocking options, so the wrong clock may be
selected instead of deferring the probe.

Request can_clk with devm_clk_get_optional() and propagate its errors.
While at it, add a comment mentioning that the canfd or fck clocks are
used as a fallbacks when the external clock is not available or it is
described in device tree with a rate of 0.

Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Link: https://patch.msgid.link/20261019121356.2421761-2-claudiu.beznea@kernel.org
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
 drivers/net/can/rcar/rcar_canfd.c | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/net/can/rcar/rcar_canfd.c b/drivers/net/can/rcar/rcar_canfd.c
index 74c3c3f20991..bb2d03b75142 100644
--- a/drivers/net/can/rcar/rcar_canfd.c
+++ b/drivers/net/can/rcar/rcar_canfd.c
@@ -2220,11 +2220,14 @@ static int rcar_canfd_probe(struct platform_device *pdev)
 		return dev_err_probe(dev, PTR_ERR(gpriv->clkp),
 				     "cannot get peripheral clock\n");
 
-	/* fCAN clock: Pick External clock. If not available fallback to
-	 * CANFD clock
+	/* fCAN clock: Pick External clock. If not available or its rate is
+	 * zero fallback to CANFD clock or fck (when info->fcan_pclk = 1).
 	 */
-	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 (IS_ERR(gpriv->can_clk))
+		return dev_err_probe(dev, PTR_ERR(gpriv->can_clk), "cannot get can_clk");
+
+	if (!gpriv->can_clk || (clk_get_rate(gpriv->can_clk) == 0)) {
 		if (info->fcan_pclk) {
 			fcan_freq = clk_get_rate(gpriv->clkp);
 			gpriv->can_clk = NULL;
-- 
2.53.0

Re: [PATCH net-next 06/12] can: rcar_canfd: Check can_clk request for errors

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found more severe
issue(s) in other patches of this series. This mail is only an FYI, in case
you want to address the nit picks below when you respin.

Low priority / nit picks for your consideration:

- [Low] The patch adds a dev_err_probe() call in rcar_canfd_probe()
  (drivers/net/can/rcar/rcar_canfd.c:2228) whose format string, "cannot…

--

can: rcar_canfd: Check can_clk request for errors

This commit switches the can_clk request in rcar_canfd_probe() from
devm_clk_get() to devm_clk_get_optional(). Errors such as -EPROBE_DEFER
are now passed back to the caller. Before this, the driver silently fell
back to the canfd or fck clock. The comment describing the fallback is
also updated.

Link: https://patch.msgid.link/20261019121356.2421761-2-claudiu.beznea@kernel.org

> diff --git a/drivers/net/can/rcar/rcar_canfd.c b/drivers/net/can/rcar/rcar_canfd.c
> index 74c3c3f20991f..bb2d03b75142a 100644
> --- a/drivers/net/can/rcar/rcar_canfd.c
> +++ b/drivers/net/can/rcar/rcar_canfd.c
> @@ -2220,11 +2220,14 @@ 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)) {
> +	gpriv->can_clk = devm_clk_get_optional(dev, "can_clk");
> +	if (IS_ERR(gpriv->can_clk))
> +		return dev_err_probe(dev, PTR_ERR(gpriv->can_clk), "cannot get can_clk");

[Severity: Low]
This isn't a bug, but should this format string end with "\n"? All the
other dev_err_probe() calls in rcar_canfd_probe() have one ("cannot get
peripheral clock\n", "cannot get canfd clock\n", "cannot get ram
clock\n", and so on).

With -EPROBE_DEFER, the case this patch is about, __dev_probe_failed()
does not print the message. It stores it as-is through
device_set_deferred_probe_reason().

The stored string is then printed with no newline added. One place is
deferred_devs_show() in drivers/base/dd.c:

    seq_printf(s, "%s\t%s", dev_name(curr->device),
               curr->deferred_probe_reason ?: "\n");

The other is deferred_probe_timeout_work_func():

    dev_warn(p->device, "deferred probe pending: %s",
             p->deferred_probe_reason ?: "(reason unknown)\n");

So when can_clk defers, the next entry in
/sys/kernel/debug/devices_deferred would run onto the same line. The
deferred probe timeout warning would also have no line ending.

> +
> +	if (!gpriv->can_clk || (clk_get_rate(gpriv->can_clk) == 0)) {
>  		if (info->fcan_pclk) {
>  			fcan_freq = clk_get_rate(gpriv->clkp);
>  			gpriv->can_clk = NULL;

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261110115112.3807247-2-mkl%40pengutronix.de

[PATCH net-next 07/12] can: rcar_canfd: Use DT clock names in the probe message

[Marc Kleine-Budde]

From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>

Print the DT binding clock names when reporting the selected clock at the
end of probe. These names are part of the DT ABI, so they are stable and
match what users see in the device tree.

Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Link: https://patch.msgid.link/20261019121356.2421761-3-claudiu.beznea@kernel.org
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
 drivers/net/can/rcar/rcar_canfd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/can/rcar/rcar_canfd.c b/drivers/net/can/rcar/rcar_canfd.c
index bb2d03b75142..4f5cdfa8211d 100644
--- a/drivers/net/can/rcar/rcar_canfd.c
+++ b/drivers/net/can/rcar/rcar_canfd.c
@@ -2312,7 +2312,7 @@ static int rcar_canfd_probe(struct platform_device *pdev)
 
 	platform_set_drvdata(pdev, gpriv);
 	dev_info(dev, "global operational state (%s clk, %s mode)\n",
-		 gpriv->extclk ? "ext" : "canfd",
+		 gpriv->extclk ? "can_clk" : (info->fcan_pclk ? "fck" : "canfd"),
 		 gpriv->fdmode ? (gpriv->fd_only_mode ? "fd-only" : "fd") : "classical");
 	return 0;
 
-- 
2.53.0

Re: [PATCH net-next 07/12] can: rcar_canfd: Use DT clock names in the probe message

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Low] can: rcar_canfd: wrong DT clock name logged in
  rcar_canfd_probe()
--

commit 465506d0bf0262439ace49568aa154d5d5ff9172
Author: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>

can: rcar_canfd: Use DT clock names in the probe message

This commit updates the probe log message in rcar_canfd_probe() to report
the DT binding clock names ("can_clk", "fck", or "canfd") for the selected
clock.

Link: https://patch.msgid.link/20261019121356.2421761-3-claudiu.beznea@kernel.org

> diff --git a/drivers/net/can/rcar/rcar_canfd.c b/drivers/net/can/rcar/rcar_canfd.c
> index bb2d03b75142a..4f5cdfa8211da 100644
> --- a/drivers/net/can/rcar/rcar_canfd.c
> +++ b/drivers/net/can/rcar/rcar_canfd.c
> @@ -2312,7 +2312,7 @@ static int rcar_canfd_probe(struct platform_device *pdev)
>  
>  	platform_set_drvdata(pdev, gpriv);
>  	dev_info(dev, "global operational state (%s clk, %s mode)\n",
> -		 gpriv->extclk ? "ext" : "canfd",
> +		 gpriv->extclk ? "can_clk" : (info->fcan_pclk ? "fck" : "canfd"),
>  		 gpriv->fdmode ? (gpriv->fd_only_mode ? "fd-only" : "fd") : "classical");

[Severity: Low]
Does checking gpriv->extclk here log "canfd" instead of "can_clk" on SoCs
using r9a09g047_hw_info (such as RZ/G3E, RZ/V2N, and RZ/V2H)?

Those SoCs define their fCAN clock under the DT name "can_clk", so
devm_clk_get_optional(dev, "can_clk") succeeds with a non-zero rate and
rcar_canfd_probe() sets:

drivers/net/can/rcar/rcar_canfd.c:rcar_canfd_probe() {
	...
	} else {
		fcan_freq = clk_get_rate(gpriv->can_clk);
		gpriv->extclk = gpriv->info->external_clk;
	}
}

Because r9a09g047_hw_info has both .external_clk = 0 and .fcan_pclk = 0,
gpriv->extclk is false even though the "can_clk" DT clock was selected,
causing dev_info() to report "canfd clk".

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261110115112.3807247-1-mkl@pengutronix.de?part=7

Re: [PATCH net-next 07/12] can: rcar_canfd: Use DT clock names in the probe message

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 3575 bytes --]

On 10.11.2026 12:41:30, Marc Kleine-Budde wrote:
> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>
> Print the DT binding clock names when reporting the selected clock at the
> end of probe. These names are part of the DT ABI, so they are stable and
> match what users see in the device tree.
>
> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> Link: https://patch.msgid.link/20261019121356.2421761-3-claudiu.beznea@kernel.org
> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>


The netdev sashiko/clashiko found a medium issue. Can you comment on it?

If you re-spin the series, take a look at the low issues, too:

https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261110115112.3807247-1-mkl@pengutronix.de

regards,
Marc

--- Patch [7]: [PATCH net-next 07/12] can: rcar_canfd: Use DT clock names in the probe message ---
commit d7a69a85fec4c0746ff8cbfad2799f58cd2059c3
Author: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>

can: rcar_canfd: Use DT clock names in the probe message

This commit changes the clock name in the final dev_info() of
rcar_canfd_probe(). It now prints DT binding clock names ("can_clk",
"fck" or "canfd") instead of "ext" or "canfd".

Link: https://patch.msgid.link/20261019121356.2421761-3-claudiu.beznea@kernel.org

> diff --git a/drivers/net/can/rcar/rcar_canfd.c b/drivers/net/can/rcar/rcar_canfd.c
> index bb2d03b75142a..4f5cdfa8211da 100644
> --- a/drivers/net/can/rcar/rcar_canfd.c
> +++ b/drivers/net/can/rcar/rcar_canfd.c
> @@ -2312,7 +2312,7 @@ static int rcar_canfd_probe(struct platform_device *pdev)
>
>  	platform_set_drvdata(pdev, gpriv);
>  	dev_info(dev, "global operational state (%s clk, %s mode)\n",
> -		 gpriv->extclk ? "ext" : "canfd",
> +		 gpriv->extclk ? "can_clk" : (info->fcan_pclk ? "fck" : "canfd"),

Is the right name printed when can_clk is in use on hardware where
external_clk is 0?

gpriv->extclk does not record which DT clock was picked. In the branch
that uses "can_clk", it is copied from the hw_info flag that controls
the GCFG DCS bit:

drivers/net/can/rcar/rcar_canfd.c:rcar_canfd_probe() {
    ...
	} else {
		fcan_freq = clk_get_rate(gpriv->can_clk);
		gpriv->extclk = gpriv->info->external_clk;
	}
    ...
}

r9a09g047_hw_info has:

	.external_clk = 0,
	.fcan_pclk = 0,

RZ/G3E uses this hw_info, and so do RZ/V2N and RZ/V2H through the
r9a09g047 fallback compatible. Their device trees (r9a09g047.dtsi,
r9a09g056.dtsi and r9a09g057.dtsi) only list:

	clock-names = "fck", "ram_clk", "can_clk";

On these SoCs, devm_clk_get_optional(dev, "can_clk") returns a clock
with a non-zero rate, so the else branch runs. extclk then ends up
false, and the message prints "canfd clk".

None of those device trees has a "canfd" clock, so a successful probe on
these SoCs can only have used "can_clk".

The commit message says the names "match what users see in the device
tree". That does not seem to hold on these platforms. The same ternary
is also still there at the end of the series.

Could each branch that gets the clock set a const char * clock name
instead, rather than working it out from extclk and fcan_pclk?

>  		 gpriv->fdmode ? (gpriv->fd_only_mode ? "fd-only" : "fd") : "classical");
>  	return 0;

--
Pengutronix e.K.                 | Marc Kleine-Budde          |
Embedded Linux                   | https://www.pengutronix.de |
Vertretung Nürnberg              | Phone: +49-5121-206917-129 |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-9   |

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH net-next 07/12] can: rcar_canfd: Use DT clock names in the probe message

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found 1 potential
issue(s) to consider.

Critical: 0 · High: 0 · Medium: 1 · Low: 0

If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).

- [Medium] In rcar_canfd_probe() (drivers/net/can/rcar/rcar_canfd.c), the
  new probe message works out the DT clock name from gpriv->extclk and…

--

can: rcar_canfd: Use DT clock names in the probe message

This commit changes the clock name in the final dev_info() of
rcar_canfd_probe(). It now prints DT binding clock names ("can_clk",
"fck" or "canfd") instead of "ext" or "canfd".

Link: https://patch.msgid.link/20261019121356.2421761-3-claudiu.beznea@kernel.org

> diff --git a/drivers/net/can/rcar/rcar_canfd.c b/drivers/net/can/rcar/rcar_canfd.c
> index bb2d03b75142a..4f5cdfa8211da 100644
> --- a/drivers/net/can/rcar/rcar_canfd.c
> +++ b/drivers/net/can/rcar/rcar_canfd.c
> @@ -2312,7 +2312,7 @@ static int rcar_canfd_probe(struct platform_device *pdev)
>  
>  	platform_set_drvdata(pdev, gpriv);
>  	dev_info(dev, "global operational state (%s clk, %s mode)\n",
> -		 gpriv->extclk ? "ext" : "canfd",
> +		 gpriv->extclk ? "can_clk" : (info->fcan_pclk ? "fck" : "canfd"),

[Severity: Medium]
Is the right name printed when can_clk is in use on hardware where
external_clk is 0?

gpriv->extclk does not record which DT clock was picked. In the branch
that uses "can_clk", it is copied from the hw_info flag that controls
the GCFG DCS bit:

drivers/net/can/rcar/rcar_canfd.c:rcar_canfd_probe() {
    ...
	} else {
		fcan_freq = clk_get_rate(gpriv->can_clk);
		gpriv->extclk = gpriv->info->external_clk;
	}
    ...
}

r9a09g047_hw_info has:

	.external_clk = 0,
	.fcan_pclk = 0,

RZ/G3E uses this hw_info, and so do RZ/V2N and RZ/V2H through the
r9a09g047 fallback compatible. Their device trees (r9a09g047.dtsi,
r9a09g056.dtsi and r9a09g057.dtsi) only list:

	clock-names = "fck", "ram_clk", "can_clk";

On these SoCs, devm_clk_get_optional(dev, "can_clk") returns a clock
with a non-zero rate, so the else branch runs. extclk then ends up
false, and the message prints "canfd clk".

None of those device trees has a "canfd" clock, so a successful probe on
these SoCs can only have used "can_clk".

The commit message says the names "match what users see in the device
tree". That does not seem to hold on these platforms. The same ternary
is also still there at the end of the series.

Could each branch that gets the clock set a const char * clock name
instead, rather than working it out from extclk and fcan_pclk?

>  		 gpriv->fdmode ? (gpriv->fd_only_mode ? "fd-only" : "fd") : "classical");
>  	return 0;

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261110115112.3807247-2-mkl%40pengutronix.de

[PATCH net-next 08/12] dt-bindings: can: renesas,rcar-canfd: Restrict resets in top-level

[Marc Kleine-Budde]

From: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

Properties varying per variant of the device should still have the
broadest constraints set in the top level, so add such for the "resets".
Since top-level part says "reset-names" cannot accept one item, disallow
it for the two variants which do not use it in practice.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>
Link: https://patch.msgid.link/20261001060825.53335-2-krzysztof.kozlowski@oss.qualcomm.com
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
 .../devicetree/bindings/net/can/renesas,rcar-canfd.yaml   | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
index bbaaef8f4282..1a7a9ce45e97 100644
--- a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
+++ b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
@@ -133,7 +133,9 @@ properties:
   power-domains:
     maxItems: 1
 
-  resets: true
+  resets:
+    minItems: 1
+    maxItems: 2
 
   reset-names:
     items:
@@ -209,7 +211,6 @@ allOf:
 
         resets:
           minItems: 2
-          maxItems: 2
 
   - if:
       properties:
@@ -231,6 +232,8 @@ allOf:
         resets:
           maxItems: 1
 
+        reset-names: false
+
   - if:
       properties:
         compatible:
@@ -246,7 +249,6 @@ allOf:
 
         resets:
           minItems: 2
-          maxItems: 2
 
   - if:
       properties:
-- 
2.53.0

Re: [PATCH net-next 08/12] dt-bindings: can: renesas,rcar-canfd: Restrict resets in top-level

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Low] dt-bindings: can: renesas,rcar-canfd: duplicate reset-names:
  false in allOf
--

commit 673edc90f4112a3f288e1450d2ac3c1b416dd41b
Author: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

dt-bindings: can: renesas,rcar-canfd: Restrict resets in top-level

This commit constrains the top-level resets property to 1 or 2 items,
removes redundant maxItems: 2 entries in per-variant conditionals, and adds
reset-names: false to the renesas,rcar-gen3-canfd and
renesas,rcar-gen4-canfd conditional block.

Link: https://patch.msgid.link/20261001060825.53335-2-krzysztof.kozlowski@oss.qualcomm.com

> diff --git a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
> index bbaaef8f4282e..1a7a9ce45e977 100644
> --- a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
> +++ b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
[ ... ]
> @@ -231,6 +232,8 @@ allOf:
>          resets:
>            maxItems: 1
>  
> +        reset-names: false

[Severity: Low]
Does this duplicate the reset-names: false constraint already present in a
second if-then block for the same compatible strings further down in allOf?

Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml:
  - if:
      properties:
        compatible:
          contains:
            enum:
              - renesas,rcar-gen3-canfd
              - renesas,rcar-gen4-canfd
    then:
      required:
        - resets
      properties:
        reset-names: false

These two identical if conditions for renesas,rcar-gen3-canfd and
renesas,rcar-gen4-canfd could be merged, or the binding could be split into
separate schema documents to avoid accumulating fragmented per-compatible
conditionals.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261110115112.3807247-1-mkl@pengutronix.de?part=8

Re: [PATCH net-next 08/12] dt-bindings: can: renesas,rcar-canfd: Restrict resets in top-level

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found more severe
issue(s) in other patches of this series. This mail is only an FYI, in case
you want to address the nit picks below when you respin.

Low priority / nit picks for your consideration:

- [Low] In Documentation/devicetree/bindings/net/can/renesas,rcar-
  canfd.yaml, this patch adds `reset-names: false` (line 235) to the…

--

dt-bindings: can: renesas,rcar-canfd: Restrict resets in top-level

This commit moves the broadest constraint for resets (minItems 1,
maxItems 2) to the top level and drops the per-variant maxItems 2. It
also adds reset-names: false for the rcar-gen3-canfd and rcar-gen4-canfd
variants.

Link: https://patch.msgid.link/20261001060825.53335-2-krzysztof.kozlowski@oss.qualcomm.com

> diff --git a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
> index bbaaef8f4282e..1a7a9ce45e977 100644
> --- a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
> +++ b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml

[ ... ]

> @@ -231,6 +232,8 @@ allOf:
>          resets:
>            maxItems: 1
>  
> +        reset-names: false
> +

[Severity: Low]
This isn't a bug, but isn't this rule already in the binding?

Further down in the same allOf list there is a separate block for the
same two compatibles. It already disallows reset-names:

  - if:
      properties:
        compatible:
          contains:
            enum:
              - renesas,rcar-gen3-canfd
              - renesas,rcar-gen4-canfd
    then:
      required:
        - resets
      properties:
        reset-names: false

So the new line duplicates that rule, and validation results for gen3
and gen4 device trees are the same before and after this hunk.

The commit message says:

  Since top-level part says "reset-names" cannot accept one item, disallow
  it for the two variants which do not use it in practice.

That reads as if this patch adds a new restriction. Could the extra line
be dropped, or the two gen3/gen4 blocks be merged into one, and the
commit message updated to match?

>    - if:
>        properties:
>          compatible:

[ ... ]

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261110115112.3807247-2-mkl%40pengutronix.de

[PATCH net-next 09/12] dt-bindings: can: renesas,rcar-canfd: Simplify renesas,no-can-fd description

[Marc Kleine-Budde]

From: Biju Das <biju.das.au@gmail.com>

The description of renesas,no-can-fd lists the operating modes
(CAN-FD, FD-Only and Classical CAN) and which SoCs support each one.
This is not accurate for every supported SoC, for example RZ/G3S, whose
CAN-FD controller has no Classical CAN mode.

Drop the mode list and keep only the statement of what the property
does, so the description no longer implies that all SoCs can operate in
Classical CAN mode.

Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://patch.msgid.link/20261021-canfd_rzg3l-v6-1-b4abfdba8e70@bp.renesas.com
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
 .../devicetree/bindings/net/can/renesas,rcar-canfd.yaml       | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
index 1a7a9ce45e97..81674ea4bef4 100644
--- a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
+++ b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
@@ -145,9 +145,7 @@ properties:
   renesas,no-can-fd:
     $ref: /schemas/types.yaml#/definitions/flag
     description:
-      The controller can operate in either CAN-FD mode (default) or FD-Only
-      mode (RZ/{G2L,G3E} and R-Car Gen4) or Classical CAN mode. Specify this
-      property to put the controller in Classical CAN mode.
+      Specify this property to put the controller in Classical CAN mode.
 
   renesas,fd-only:
     $ref: /schemas/types.yaml#/definitions/flag
-- 
2.53.0

[PATCH net-next 10/12] can: rcar_canfd: Document that RZ/G3S has no Classical CAN mode

[Marc Kleine-Budde]

From: Biju Das <biju.das.au@gmail.com>

The header comments in the driver describe Classical CAN (CAN 2.0)
only mode as a mode the controller can operate in, without saying that
this does not apply to every supported SoC. RZ/G3S does not support
Classical CAN mode.

Update the comments to note the RZ/G3S exception, so that readers of
the driver are not misled about which SoCs can use that mode. This
matches the corresponding dt-bindings update.

No functional change.

Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Link: https://patch.msgid.link/20261021-canfd_rzg3l-v6-2-b4abfdba8e70@bp.renesas.com
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
 drivers/net/can/rcar/rcar_canfd.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/net/can/rcar/rcar_canfd.c b/drivers/net/can/rcar/rcar_canfd.c
index 4f5cdfa8211d..072987316cc7 100644
--- a/drivers/net/can/rcar/rcar_canfd.c
+++ b/drivers/net/can/rcar/rcar_canfd.c
@@ -6,7 +6,7 @@
 
 /* The R-Car CAN FD controller can operate in either one of the below two modes
  *  - CAN FD only mode
- *  - Classical CAN (CAN 2.0) only mode
+ *  - Classical CAN (CAN 2.0) only mode (Except RZ/G3S)
  *
  * This driver puts the controller in CAN FD only mode by default. In this
  * mode, the controller acts as a CAN FD node that can also interoperate with
@@ -247,10 +247,10 @@
 #define RCANFD_CFFDCSTS_CFBRS		BIT(1)
 #define RCANFD_CFFDCSTS_CFESI		BIT(0)
 
-/* This controller supports either Classical CAN only mode or CAN FD only mode.
- * These modes are supported in two separate set of register maps & names.
- * However, some of the register offsets are common for both modes. Those
- * offsets are listed below as Common registers.
+/* This controller supports either Classical CAN only mode(Except RZ/G3S) or
+ * CAN FD only mode. These modes are supported in two separate set of register
+ * maps & names. However, some of the register offsets are common for both
+ * modes. Those offsets are listed below as Common registers.
  *
  * The CAN FD only mode specific registers & Classical CAN only mode specific
  * registers are listed separately. Their register names starts with
-- 
2.53.0

Re: [PATCH net-next 10/12] can: rcar_canfd: Document that RZ/G3S has no Classical CAN mode

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found more severe
issue(s) in other patches of this series. This mail is only an FYI, in case
you want to address the nit picks below when you respin.

Low priority / nit picks for your consideration:

- [Low] The patch fixes only half of the header comment in
  drivers/net/can/rcar/rcar_canfd.c.

--

can: rcar_canfd: Document that RZ/G3S has no Classical CAN mode

This patch changes the header comments in the R-Car CAN FD driver to say
that RZ/G3S does not support Classical CAN (CAN 2.0) only mode. It
matches the corresponding dt-bindings update. There is no functional
change.

Link: https://patch.msgid.link/20261021-canfd_rzg3l-v6-2-b4abfdba8e70@bp.renesas.com

> diff --git a/drivers/net/can/rcar/rcar_canfd.c b/drivers/net/can/rcar/rcar_canfd.c
> index 4f5cdfa8211da..072987316cc75 100644
> --- a/drivers/net/can/rcar/rcar_canfd.c
> +++ b/drivers/net/can/rcar/rcar_canfd.c
> @@ -6,7 +6,7 @@
>  
>  /* The R-Car CAN FD controller can operate in either one of the below two modes
>   *  - CAN FD only mode
> - *  - Classical CAN (CAN 2.0) only mode
> + *  - Classical CAN (CAN 2.0) only mode (Except RZ/G3S)
>   *
>   * This driver puts the controller in CAN FD only mode by default. In this
>   * mode, the controller acts as a CAN FD node that can also interoperate with

[Severity: Low]
This isn't a bug, but should the paragraph just below this one in the same
header comment get the RZ/G3S exception too? The patch leaves it as is:

drivers/net/can/rcar/rcar_canfd.c:
 * To switch the controller to Classical CAN (CAN 2.0) only mode, add
 * "renesas,no-can-fd" optional property to the device tree node. A h/w reset is
 * also required to switch modes.

The renesas,rcar-canfd.yaml binding does not allow this property on RZ/G3S.
The allOf branch for renesas,r9a08g045-canfd has:

    then:
      properties:
        renesas,no-can-fd: false
        renesas,fd-only: false

So the comment now says Classical CAN mode is not available on RZ/G3S, but
the next paragraph still tells readers to add renesas,no-can-fd, without
naming any SoC that cannot use it.

Later in the series, "can: rcar_canfd: Add support for Renesas RZ/G3L"
changes only the line above to "(Except RZ/G3{L,S})" and leaves this
paragraph as it is.

Could the instruction paragraph also say that renesas,no-can-fd must not
be used on RZ/G3S?

[ ... ]

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261110115112.3807247-2-mkl%40pengutronix.de

[PATCH net-next 11/12] dt-bindings: can: renesas,rcar-canfd: Document RZ/G3L SoC

[Marc Kleine-Budde]

From: Biju Das <biju.das.au@gmail.com>

Document the RZ/G3L (R9A08G046) SoC support.

RZ/G3L has 11 interrupts and 3 CANFD channels compared to 8 interrupts
and 2 CANFD channels on RZ/G3S. RZ/G3L has 288 buffers in total
compared to 192 buffers in RZ/G3S.

Like RZ/G3S, RZ/G3L supports only CAN-FD mode, so renesas,no-can-fd is
disallowed for it.

Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://patch.msgid.link/20261021-canfd_rzg3l-v6-3-b4abfdba8e70@bp.renesas.com
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
 .../bindings/net/can/renesas,rcar-canfd.yaml  | 27 ++++++++++++++++++-
 1 file changed, 26 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
index 81674ea4bef4..dc7437702120 100644
--- a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
+++ b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
@@ -14,6 +14,7 @@ properties:
     oneOf:
       - enum:
           - renesas,r9a08g045-canfd        # RZ/G3S
+          - renesas,r9a08g046-canfd        # RZ/G3L
           - renesas,r9a09g047-canfd        # RZ/G3E
           - renesas,r9a09g077-canfd        # RZ/T2H
 
@@ -292,6 +293,27 @@ allOf:
       patternProperties:
         "^channel[6-7]$": false
 
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: renesas,r9a08g046-canfd
+    then:
+      properties:
+        interrupts:
+          minItems: 11
+          maxItems: 11
+
+        interrupt-names:
+          minItems: 11
+          maxItems: 11
+
+        resets:
+          minItems: 2
+
+      patternProperties:
+        "^channel[3-7]$": false
+
   - if:
       properties:
         compatible:
@@ -332,6 +354,7 @@ allOf:
           contains:
             enum:
               - renesas,r9a08g045-canfd
+              - renesas,r9a08g046-canfd
               - renesas,r9a09g047-canfd
               - renesas,rzg2l-canfd
     then:
@@ -356,7 +379,9 @@ allOf:
       properties:
         compatible:
           contains:
-            const: renesas,r9a08g045-canfd
+            enum:
+              - renesas,r9a08g045-canfd
+              - renesas,r9a08g046-canfd
     then:
       properties:
         renesas,no-can-fd: false
-- 
2.53.0

Re: [PATCH net-next 11/12] dt-bindings: can: renesas,rcar-canfd: Document RZ/G3L SoC

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Low] dt-bindings: can: renesas,rcar-canfd: unwieldy per-compatible
  conditionals
--

commit b004ab68b21e93b39df6164d000c1b8ef430f90c
Author: Biju Das <biju.das.au@gmail.com>

dt-bindings: can: renesas,rcar-canfd: Document RZ/G3L SoC

This commit documents the Renesas RZ/G3L (R9A08G046) SoC in the
renesas,rcar-canfd device tree binding schema.

Link: https://patch.msgid.link/20261021-canfd_rzg3l-v6-3-b4abfdba8e70@bp.renesas.com

> diff --git a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
> index 81674ea4bef47..dc74377021207 100644
> --- a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
> +++ b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml

[ ... ]

> @@ -292,6 +293,27 @@ allOf:
>        patternProperties:
>          "^channel[6-7]$": false
>  
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            const: renesas,r9a08g046-canfd
> +    then:
> +      properties:
> +        interrupts:
> +          minItems: 11
> +          maxItems: 11
> +
> +        interrupt-names:
> +          minItems: 11
> +          maxItems: 11
> +
> +        resets:
> +          minItems: 2
> +
> +      patternProperties:
> +        "^channel[3-7]$": false
> +
>    - if:
>        properties:
>          compatible:
> @@ -332,6 +354,7 @@ allOf:
>            contains:
>              enum:
>                - renesas,r9a08g045-canfd
> +              - renesas,r9a08g046-canfd
>                - renesas,r9a09g047-canfd
>                - renesas,rzg2l-canfd
>      then:
> @@ -356,7 +379,9 @@ allOf:
>        properties:
>          compatible:
>            contains:
> -            const: renesas,r9a08g045-canfd
> +            enum:
> +              - renesas,r9a08g045-canfd
> +              - renesas,r9a08g046-canfd
>      then:
>        properties:
>          renesas,no-can-fd: false

[Severity: Low]
This isn't a bug, but allOf now has 15 if-then conditional blocks to handle
differences in interrupt counts, channel counts, resets, clocks, and CAN
modes across R-Car and RZ variants, with constraints for
renesas,r9a08g046-canfd split across three separate conditionals.  Would it
make sense to split the binding into separate schema documents instead of
adding more per-compatible conditionals to this file?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261110115112.3807247-1-mkl@pengutronix.de?part=11

Re: [PATCH net-next 11/12] dt-bindings: can: renesas,rcar-canfd: Document RZ/G3L SoC

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found more severe
issue(s) in other patches of this series. This mail is only an FYI, in case
you want to address the nit picks below when you respin.

Low priority / nit picks for your consideration:

- [Low] When this commit is applied, the driver header comment in
  drivers/net/can/rcar/rcar_canfd.c names only RZ/G3S as lacking…

--

dt-bindings: can: renesas,rcar-canfd: Document RZ/G3L SoC

This commit adds the RZ/G3L (R9A08G046) compatible to the R-Car CANFD
binding. It describes 11 interrupts, 3 channels and at least 2 resets for
the new SoC. Like RZ/G3S, it forbids renesas,no-can-fd and
renesas,fd-only for RZ/G3L.

Link: https://patch.msgid.link/20261021-canfd_rzg3l-v6-3-b4abfdba8e70@bp.renesas.com

> diff --git a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
> index 81674ea4bef47..dc74377021207 100644
> --- a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
> +++ b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml

[ ... ]

> @@ -356,7 +379,9 @@ allOf:
>        properties:
>          compatible:
>            contains:
> -            const: renesas,r9a08g045-canfd
> +            enum:
> +              - renesas,r9a08g045-canfd
> +              - renesas,r9a08g046-canfd
>      then:
>        properties:
>          renesas,no-can-fd: false

[Severity: Low]
This isn't a bug, but with this patch applied the binding and the driver
comments disagree about RZ/G3L.

The binding now treats RZ/G3L as having no Classical CAN mode. It forbids
both renesas,no-can-fd and renesas,fd-only for r9a08g045-canfd and
r9a08g046-canfd.

The header comment in drivers/net/can/rcar/rcar_canfd.c still lists only
RZ/G3S as the exception:

drivers/net/can/rcar/rcar_canfd.c:
 *  - Classical CAN (CAN 2.0) only mode (Except RZ/G3S)

The comment above the mode handling has the same wording:

/* This controller supports either Classical CAN only mode(Except RZ/G3S) or

The next patch in the series, "can: rcar_canfd: Add support for Renesas
RZ/G3L", changes both comments to "(Except RZ/G3{L,S})". So once the full
series is applied, the comments and the binding agree, and this only
affects this one commit.

Would it be worth updating those comments here, or noting in the commit
message that the driver side follows in the next patch?

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261110115112.3807247-2-mkl%40pengutronix.de

[PATCH net-next 12/12] can: rcar_canfd: Add support for Renesas RZ/G3L

[Marc Kleine-Budde]

From: Biju Das <biju.das.au@gmail.com>

Add support for Renesas RZ/G3L CANFD IP. RZ/G3L has 3 channels and
11 interrupts, compared 2 channels and 8 interrupts on RZ/G3S.
RZ/G3L has 288 buffers compared to 192 buffers on RZ/G3S.

Like RZ/G3S, the controller supports only CAN-FD mode and update
the comments to note that Classical CAN mode is not available on
RZ/G3L either.

Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Link: https://patch.msgid.link/20261021-canfd_rzg3l-v6-4-b4abfdba8e70@bp.renesas.com
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
 drivers/net/can/rcar/rcar_canfd.c | 31 ++++++++++++++++++++++++++-----
 1 file changed, 26 insertions(+), 5 deletions(-)

diff --git a/drivers/net/can/rcar/rcar_canfd.c b/drivers/net/can/rcar/rcar_canfd.c
index 072987316cc7..7333ee98aa92 100644
--- a/drivers/net/can/rcar/rcar_canfd.c
+++ b/drivers/net/can/rcar/rcar_canfd.c
@@ -6,7 +6,7 @@
 
 /* The R-Car CAN FD controller can operate in either one of the below two modes
  *  - CAN FD only mode
- *  - Classical CAN (CAN 2.0) only mode (Except RZ/G3S)
+ *  - Classical CAN (CAN 2.0) only mode (Except RZ/G3{L,S})
  *
  * This driver puts the controller in CAN FD only mode by default. In this
  * mode, the controller acts as a CAN FD node that can also interoperate with
@@ -247,10 +247,10 @@
 #define RCANFD_CFFDCSTS_CFBRS		BIT(1)
 #define RCANFD_CFFDCSTS_CFESI		BIT(0)
 
-/* This controller supports either Classical CAN only mode(Except RZ/G3S) or
- * CAN FD only mode. These modes are supported in two separate set of register
- * maps & names. However, some of the register offsets are common for both
- * modes. Those offsets are listed below as Common registers.
+/* This controller supports either Classical CAN only mode(Except RZ/G3{L,S})
+ * or CAN FD only mode. These modes are supported in two separate set of
+ * register maps & names. However, some of the register offsets are common for
+ * both modes. Those offsets are listed below as Common registers.
  *
  * The CAN FD only mode specific registers & Classical CAN only mode specific
  * registers are listed separately. Their register names starts with
@@ -681,6 +681,26 @@ static const struct rcar_canfd_hw_info r9a08g045_hw_info = {
 	.fixed_canfd = 1,
 };
 
+static const struct rcar_canfd_hw_info r9a08g046_hw_info = {
+	.nom_bittiming = &rcar_canfd_gen4_nom_bittiming_const,
+	.data_bittiming = &rcar_canfd_gen4_data_bittiming_const,
+	.tdc_const = &rcar_canfd_gen4_tdc_const,
+	.regs = &rcar_gen4_regs,
+	.sh = &rcar_gen4_shift_data,
+	.rnc_field_width = 16,
+	.max_aflpn = 15,
+	.max_cftml = 31,
+	.max_channels = 3,
+	.postdiv = 2,
+	.shared_global_irqs = 0,
+	.multi_channel_irqs = 1,
+	.ch_interface_mode = 1,
+	.shared_can_regs = 1,
+	.external_clk = 1,
+	.fcan_pclk = 1,
+	.fixed_canfd = 1,
+};
+
 static const struct rcar_canfd_hw_info r9a09g047_hw_info = {
 	.nom_bittiming = &rcar_canfd_gen4_nom_bittiming_const,
 	.data_bittiming = &rcar_canfd_gen4_data_bittiming_const,
@@ -2407,6 +2427,7 @@ static DEFINE_SIMPLE_DEV_PM_OPS(rcar_canfd_pm_ops, rcar_canfd_suspend,
 static const __maybe_unused struct of_device_id rcar_canfd_of_table[] = {
 	{ .compatible = "renesas,r8a779a0-canfd", .data = &rcar_gen4_hw_info },
 	{ .compatible = "renesas,r9a08g045-canfd", .data = &r9a08g045_hw_info },
+	{ .compatible = "renesas,r9a08g046-canfd", .data = &r9a08g046_hw_info },
 	{ .compatible = "renesas,r9a09g047-canfd", .data = &r9a09g047_hw_info },
 	{ .compatible = "renesas,r9a09g077-canfd", .data = &r9a09g077_hw_info },
 	{ .compatible = "renesas,rcar-gen3-canfd", .data = &rcar_gen3_hw_info },
-- 
2.53.0