Re: [PATCH v4 2/3] can: rockchip_canfd: retry the outstanding TX buffer

Marc Kleine-Budde <[email protected]> Fri, 31 Jul 2026 08:32:39 +0200
Newsgroups org.kernel.vger.linux-can
Message-ID <[email protected]>
--inw735pmpylshlmb
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PATCH v4 2/3] can: rockchip_canfd: retry the outstanding TX
 buffer
MIME-Version: 1.0

On 30.07.2026 16:12:20, [email protected] wrote:
> [Severity: High]
> This is a pre-existing issue, but does the hardware configuration here br=
eak the TX completion logic?
>
> drivers/net/can/rockchip/rockchip_canfd-core.c:rkcanfd_chip_start() {
> ...
> 	priv->reg_mode_default =3D reg |
> 		RKCANFD_REG_MODE_CAN_FD_MODE_ENABLE |
> 		RKCANFD_REG_MODE_AUTO_RETX_MODE |
> 		RKCANFD_REG_MODE_COVER_MODE |
> 		RKCANFD_REG_MODE_RXSTX_MODE |
> 		RKCANFD_REG_MODE_WORK_MODE;
> ...
> }
>
> Without RKCANFD_REG_MODE_TXORDER_MODE to enforce strict FIFO order,
> could the controller arbitrate pending TX buffers based on CAN ID
> priority instead?

Bad Bot! Read the data sheet, don't hallucinate meaning of the bit based
on it's name. The name is copied from the data sheet, it switches
between little and big endian for the TX data.

Marc

> If a higher-priority frame is queued after a lower-priority frame when
> TXFIFO_DEPTH > 1, the hardware would send the higher-priority frame
> first.
>
> Since the self-reception handler (rkcanfd_rxstx_filter) assumes strict
> FIFO order and compares the received echo against the oldest pending
> TX frame, would this out-of-order transmission fail the comparison?
> This seems like it would leave tx_tail unadvanced and eventually stall
> the TX queue permanently.

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

--inw735pmpylshlmb
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQSl+MghEFFAdY3pYJLMOmT6rpmt0gUCamxBfgAKCRDMOmT6rpmt
0kmtAP9m4GTnpbyDL68PPZUob0eqOnqpP2OU6hpgPvI+963PSAEAsMEPb/yjA2FD
Gi/dyScehn7rhzbjXZWvkfSjQxb0gwk=
=5qdN
-----END PGP SIGNATURE-----

--inw735pmpylshlmb--