From a7d2373cd07f9148c57ba66b4ef5ef4de7e0671e Mon Sep 17 00:00:00 2001 From: Oliver Hartkopp Date: Fri, 17 Jan 2025 18:07:06 +0100 Subject: [PATCH] Update LINKTYPE_CAN_SOCKETCAN - point out that CAN CC and CAN FD are only distinguished by their length - fix the description of the CANFD_FDF meaning - introduce the Len 8 DLC value for CAN CC - make clear that RTR and error message frames are only CAN CC frames - fix typos: Classical CAN and CANXL_SEC Signed-off-by: Oliver Hartkopp --- htmlsrc/linktypes/LINKTYPE_CAN_SOCKETCAN.html | 82 +++++++++---------- linktypes/LINKTYPE_CAN_SOCKETCAN.html | 82 +++++++++---------- 2 files changed, 74 insertions(+), 90 deletions(-) diff --git a/htmlsrc/linktypes/LINKTYPE_CAN_SOCKETCAN.html b/htmlsrc/linktypes/LINKTYPE_CAN_SOCKETCAN.html index 7ddc2a0..6f61483 100644 --- a/htmlsrc/linktypes/LINKTYPE_CAN_SOCKETCAN.html +++ b/htmlsrc/linktypes/LINKTYPE_CAN_SOCKETCAN.html @@ -5,7 +5,7 @@

-This format supports CAN CC (classic CAN), CAN FD, and CAN XL frames. +This format supports CAN CC (Classical CAN), CAN FD, and CAN XL frames. The same header is used for CAN CC and CAN FD frames; a different header is used for CAN XL frames.

@@ -25,13 +25,13 @@

Packet structure

| Payload length | | (1 Octet) | +---------------------------+ -| FD flags | +| FD flags (CAN FD) | | (1 Octet) | +---------------------------+ | Reserved/Padding | | (1 Octet) | +---------------------------+ -| Reserved/Padding | +| Len 8 DLC (CAN CC) | | (1 Octet) | +---------------------------+ | Payload | @@ -53,8 +53,8 @@

Description

The remaining bits are:

@@ -65,63 +65,48 @@

Description

-The FD flags field contains CAN FD specific flags; for CAN CC frames, -this field is 0. The bits are: -

+The CAN frame types CAN CC and CAN FD can be distinguished by the frame length: +

-Older software and firmware writing packets with this link type did not -use the CANFD_FDF flag for CAN FD frames, so if the -CANFD_FDF flag is not set, the frame is not guaranteed to -be a CAN CC frame. If that flag is not set: +The FD flags field contains CAN FD specific flags; for CAN CC frames, this +field is 0. The bits are:

-In addition, older software and firmware may not have explicitly set -that field, so that the bit corresponding to the CANFD_FDF -flag might be set even for CAN CC frames. Therefore, code that reads -LINKTYPE_CAN_SOCKETCAN frames must perform some heuristic -checks to make sure that it doesn't incorrectly interpret a CAN CC frame -as a CAN FD frame, and code that generates -LINKTYPE_CAN_SOCKETCAN frames must follow certain rules to -make sure that those checks don't cause software that reads those fromes -to treat a CAN FD frame as a CAN CC frame. +As the CANFD_FDF flag for CAN FD frames is not set reliably by the Linux kernel, +this flag can be used to identify CAN FD frames when using the struct canfd_frame as a container +for CAN FD and CAN CC frames in user space applications.

-Software that reads LINKTYPE_CAN_SOCKETCAN frames must not -treat a frame with the CANFD_FDF bit set as a CAN FD frame -if any bits other than CANFD_BRS and CANFD_ESI -are set in that field, or if either of the Reserved/Padding fields are -non-zero, as that is an indication that the header fields might not have -been explicitly set, and the CANFD_FDF flag might happen to -be set even thugh the frame is not a CAN FD frame. +Software that reads LINKTYPE_CAN_SOCKETCAN frames must distinguish between CAN CC and CAN FD +ONLY by the frame length (16 or 72). Additionally the 0x80 bit of the fifth octet of the +header has to be clear for CAN CC and CAN FD frames.

-Software that generates LINKTYPE_CAN_SOCKETCAN frames: +Software that generates LINKTYPE_CAN_SOCKETCAN CAN CC and CAN FD frames:

@@ -131,8 +116,15 @@

Description

-For a remote retransmission request, the payload length must be 0, so -the payload is empty. +A remote retransmission request (RTR) is only possible with CAN CC frames and the +(real) payload length on the CAN bus is always 0. +But as the 4-bit DLC value is always send inside a CAN CC frame all possible values (0 .. 15) +can be defined by the Linktype protocol. +

+The Len 8 DLC value is applicable to CAN CC data frames and CAN CC RTR frames.

@@ -209,7 +201,7 @@

Description

The flags field contains CAN XL specific flags. The bits are:

diff --git a/linktypes/LINKTYPE_CAN_SOCKETCAN.html b/linktypes/LINKTYPE_CAN_SOCKETCAN.html index a2cb982..cdee12a 100644 --- a/linktypes/LINKTYPE_CAN_SOCKETCAN.html +++ b/linktypes/LINKTYPE_CAN_SOCKETCAN.html @@ -49,7 +49,7 @@

-This format supports CAN CC (classic CAN), CAN FD, and CAN XL frames. +This format supports CAN CC (Classical CAN), CAN FD, and CAN XL frames. The same header is used for CAN CC and CAN FD frames; a different header is used for CAN XL frames.

@@ -69,13 +69,13 @@

Packet structure

| Payload length | | (1 Octet) | +---------------------------+ -| FD flags | +| FD flags (CAN FD) | | (1 Octet) | +---------------------------+ | Reserved/Padding | | (1 Octet) | +---------------------------+ -| Reserved/Padding | +| Len 8 DLC (CAN CC) | | (1 Octet) | +---------------------------+ | Payload | @@ -97,8 +97,8 @@

Description

The remaining bits are:

@@ -109,63 +109,48 @@

Description

-The FD flags field contains CAN FD specific flags; for CAN CC frames, -this field is 0. The bits are: -

+The CAN frame types CAN CC and CAN FD can be distinguished by the frame length: +

-Older software and firmware writing packets with this link type did not -use the CANFD_FDF flag for CAN FD frames, so if the -CANFD_FDF flag is not set, the frame is not guaranteed to -be a CAN CC frame. If that flag is not set: +The FD flags field contains CAN FD specific flags; for CAN CC frames, this +field is 0. The bits are:

-In addition, older software and firmware may not have explicitly set -that field, so that the bit corresponding to the CANFD_FDF -flag might be set even for CAN CC frames. Therefore, code that reads -LINKTYPE_CAN_SOCKETCAN frames must perform some heuristic -checks to make sure that it doesn't incorrectly interpret a CAN CC frame -as a CAN FD frame, and code that generates -LINKTYPE_CAN_SOCKETCAN frames must follow certain rules to -make sure that those checks don't cause software that reads those fromes -to treat a CAN FD frame as a CAN CC frame. +As the CANFD_FDF flag for CAN FD frames is not set reliably by the Linux kernel, +this flag can be used to identify CAN FD frames when using the struct canfd_frame as a container +for CAN FD and CAN CC frames in user space applications.

-Software that reads LINKTYPE_CAN_SOCKETCAN frames must not -treat a frame with the CANFD_FDF bit set as a CAN FD frame -if any bits other than CANFD_BRS and CANFD_ESI -are set in that field, or if either of the Reserved/Padding fields are -non-zero, as that is an indication that the header fields might not have -been explicitly set, and the CANFD_FDF flag might happen to -be set even thugh the frame is not a CAN FD frame. +Software that reads LINKTYPE_CAN_SOCKETCAN frames must distinguish between CAN CC and CAN FD +ONLY by the frame length (16 or 72). Additionally the 0x80 bit of the fifth octet of the +header has to be clear for CAN CC and CAN FD frames.

-Software that generates LINKTYPE_CAN_SOCKETCAN frames: +Software that generates LINKTYPE_CAN_SOCKETCAN CAN CC and CAN FD frames:

@@ -175,8 +160,15 @@

Description

-For a remote retransmission request, the payload length must be 0, so -the payload is empty. +A remote retransmission request (RTR) is only possible with CAN CC frames and the +(real) payload length on the CAN bus is always 0. +But as the 4-bit DLC value is always send inside a CAN CC frame all possible values (0 .. 15) +can be defined by the Linktype protocol. +

+The Len 8 DLC value is applicable to CAN CC data frames and CAN CC RTR frames.

@@ -253,7 +245,7 @@

Description

The flags field contains CAN XL specific flags. The bits are: