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--