Message-ID: <sashiko-outbox-208904@kernel.org>
From: sashiko-bot@kernel.org
Subject: Re: [PATCH net-next 02/12] can: rcar_canfd: Fix typos in macro
 names
Reply-To: sashiko-reviews@lists.linux.dev
To: "Marc Kleine-Budde" <mkl@pengutronix.de>
Cc: linux-can@vger.kernel.org, "Oliver Hartkopp" <socketcan@hartkopp.net>, "Vincent
 Mailhol" <mailhol@kernel.org>, "Oleksij Rempel" <o.rempel@pengutronix.de>
In-Reply-To: <20261110115112.3807247-3-mkl@pengutronix.de>
References: <20261110115112.3807247-1-mkl@pengutronix.de>
 <20261110115112.3807247-3-mkl@pengutronix.de>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Date: Wed, 11 Nov 2026 11:51:32 +0000
Precedence: list

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+renes=
as@tuxon.dev

> diff --git a/drivers/net/can/rcar/rcar_canfd.c b/drivers/net/can/rcar/rca=
r_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)
> =20
>  	/* 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);
> =20
>  	/* Verify channel mode change */
>  	err =3D 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 =3D 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

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20261110115112.3807=
247-1-mkl@pengutronix.de?part=3D2