[PATCH net] can: ctucanfd: use self-test mode for PRESUME_ACK

[PATCH net] can: ctucanfd: use self-test mode for PRESUME_ACK

[Avi Weiss]

Use self-test mode for CAN_CTRLMODE_PRESUME_ACK so transmitted
frames can complete without receiving an ACK.

ACK forbidden mode prevents the controller from acknowledging
received frames and does not implement the presume-ack behavior.

Fixes: 2dcb8e8782d8 ("can: ctucanfd: add support for CTU CAN FD open-source IP core - bus independent part.")
Signed-off-by: Avi Weiss <thnkslprpt@gmail.com>
---
 drivers/net/can/ctucanfd/ctucanfd_base.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/can/ctucanfd/ctucanfd_base.c b/drivers/net/can/ctucanfd/ctucanfd_base.c
index 0ea1ff28dfce..8e0a606f2c84 100644
--- a/drivers/net/can/ctucanfd/ctucanfd_base.c
+++ b/drivers/net/can/ctucanfd/ctucanfd_base.c
@@ -340,8 +340,8 @@ static void ctucan_set_mode(struct ctucan_priv *priv, const struct can_ctrlmode
 			(mode_reg & ~REG_MODE_FDE);
 
 	mode_reg = (mode->flags & CAN_CTRLMODE_PRESUME_ACK) ?
-			(mode_reg | REG_MODE_ACF) :
-			(mode_reg & ~REG_MODE_ACF);
+			(mode_reg | REG_MODE_STM) :
+			(mode_reg & ~REG_MODE_STM);
 
 	mode_reg = (mode->flags & CAN_CTRLMODE_FD_NON_ISO) ?
 			(mode_reg | REG_MODE_NISOFD) :
-- 
2.43.0

Re: [PATCH net] can: ctucanfd: use self-test mode for PRESUME_ACK

[Pavel Pisa]

Hello Avi,

that is good catch.

On Wednesday 22 of July 2026 21:27:26 Avi Weiss wrote:
> Use self-test mode for CAN_CTRLMODE_PRESUME_ACK so transmitted
> frames can complete without receiving an ACK.
>
> ACK forbidden mode prevents the controller from acknowledging
> received frames and does not implement the presume-ack behavior.
>
> Fixes: 2dcb8e8782d8 ("can: ctucanfd: add support for CTU CAN FD open-source
> IP core - bus independent part.") Signed-off-by: Avi Weiss
> <thnkslprpt@gmail.com>
> ---
>  drivers/net/can/ctucanfd/ctucanfd_base.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/can/ctucanfd/ctucanfd_base.c
> b/drivers/net/can/ctucanfd/ctucanfd_base.c index 0ea1ff28dfce..8e0a606f2c84
> 100644
> --- a/drivers/net/can/ctucanfd/ctucanfd_base.c
> +++ b/drivers/net/can/ctucanfd/ctucanfd_base.c
> @@ -340,8 +340,8 @@ static void ctucan_set_mode(struct ctucan_priv *priv,
> const struct can_ctrlmode (mode_reg & ~REG_MODE_FDE);
>
>  	mode_reg = (mode->flags & CAN_CTRLMODE_PRESUME_ACK) ?
> -			(mode_reg | REG_MODE_ACF) :
> -			(mode_reg & ~REG_MODE_ACF);
> +			(mode_reg | REG_MODE_STM) :
> +			(mode_reg & ~REG_MODE_STM);
>
>  	mode_reg = (mode->flags & CAN_CTRLMODE_FD_NON_ISO) ?
>  			(mode_reg | REG_MODE_NISOFD) :

Acked-by: Pavel Pisa <pisa@fel.cvut.cz>

It is interesting how long it got unnoticed form original version
of the the code probably written by Martin Jerabek in 2018 year.

When Michal Lenc worked on CTU CAN FD driver for RTEMS based on
my LinCAN from 2000, he has corrected this problem year ago

https://gitlab.fel.cvut.cz/otrees/rtems/rtems-canfd/-/commit/e0bd5db71683375e0962dd90314c7697db3f34f2
 
https://gitlab.rtems.org/rtems/rtos/rtems/-/blob/main/bsps/shared/dev/can/ctucanfd/ctucanfd.c?ref_type=heads#L554

The RTEMS CTU CAN FD driver and framework uses multiple priority queues
on Tx side which prevents head of line blocking caused low priority
message and its continuously unsuccessful arbitrations due to
higher/middle priority message send by other node. There is our
article for International CAN Conference

Scheduling of CAN frame transmission when multiple FIFOs with assigned 
priorities are used in RTOS 

https://www.can-cia.org/fileadmin/cia/documents/proceedings/2024_lenc_pisa.pdf

https://canbus.pages.fel.cvut.cz/files/scheduling_of_can_message_transmission_michal_lenc.pdf

It is based on control registers redesign comming from my plan
and project to advance original controller design intended only
for Skoda Auto testing into full featured CAN FD controller in 2017
and I have idea how to implement QoS classes for SolcketCAN
with HW that provides designed features. By the way, we have tested
and implemented CAN QoS classification for Oliver Hartkopp even
may years before that. But there had not been any controller
supporting that well and no support for multiple queues
in Linux SocketCAN. I have not checked recently, but I think
no other CAN controller uses multi-queue in Linux kernel yet.

There is very nice solution possible with CTU CAN FD, I have
it on my long term plan so it will be solved once in spare
time in frame of some thesis I mentor or by somebody else
or the priority can be increased by some funded project. 

But I suggest to look at our article and discuss such project
with me because I have though about it from the day one
of CTU CAN FD. The control principles of the most of
other controllers are hardly usable for this except some
most recent NXP controllers which seems to provide option
to change Tx message object local priority without stopping
Tx, I have not checked that myself yer, but Michal Lenc
has spotted this. 

If you want to use CTU CAN FD in listen only mode
CAN_CTRLMODE_LISTENONLY, then there is flaw in the
CTU CAN FD RTL design earlier than 2.5.2.

It can be solved in the most of earlier versions
by enabling of REG_MODE_ACF and REG_MODE_ROM together
with REG_MODE_BMM. Again there should be added
check for version and wokaround in the kernel
driver.

The CTU CAN FD kernel code needs to be updated
to support other number of Tx buffers than four.
It would stuck on eight in the current version.
Again I have it on my longer term list but priority
is even more lowered these days as the RTL project
is not coordinated with CTU these days and 
GitLab workflow has been removed.

There is significant work done on HW timestamping
for Rx which needs some polishing for Linux mainline
still and the additional bits proposed by me marking Tx
frames and originating Tx buffer when Tx is requested
to be looped into Rx FIFO allows implement even precise
Tx timestamping and exact echo order between link,
Tx and Rx frames. So there is lot of potential based
on my original plans.

But as you know I have lot of fun with RTEMS and NuttX
these days. I have tested LwIP from Armaan Chowfin GSoC
on TMS570LS3137 this evening with success. So may be our
contribution to RTEMS CAN and or LwIP can help another
target to be used in serious mission same as we helped
with our small contributions to Artemis II in the past.

Best wishes,

                Pavel Pisa
    phone:      +420 603531357
    e-mail:     pisa@cmp.felk.cvut.cz
    Department of Control Engineering FEE CVUT
    Karlovo namesti 13, 121 35, Prague 2
    university: http://control.fel.cvut.cz/
    personal:   http://cmp.felk.cvut.cz/~pisa
    social:     https://social.kernel.org/ppisa
    projects:   https://www.openhub.net/accounts/ppisa
    CAN related:http://canbus.pages.fel.cvut.cz/
    RISC-V education: https://comparch.edu.cvut.cz/
    Open Technologies Research Education and Exchange Services
    https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home