Message-Id: <20250729-can_tms-v1-1-21d0195d1dd0@kernel.org>
Date: Tue, 29 Jul 2025 01:23:18 +0900
From: Vincent Mailhol <mailhol@...nel.org>
To: Marc Kleine-Budde <mkl@...gutronix.de>, 
 Oliver Hartkopp <socketcan@...tkopp.net>, 
 Stéphane Grosjean <stephane.grosjean@...-networks.com>
Cc: Vincent Mailhol <mailhol.vincent@...adoo.fr>, 
 Robert Nawrath <mbro1689@...il.com>, linux-can@...r.kernel.org, 
 linux-kernel@...r.kernel.org, Vincent Mailhol <mailhol@...nel.org>
Subject: [PATCH] can: canxl: add CANXL_PMS flag

The Transceiver Mode Switching (TMS) indicates whether the CAN XL
controller shall use the PWM or NRZ encoding during the data phase.

Contrarily to CAN FD's BRS flag, CAN XL does not have an explicit bit
on the bus to indicate the TMS. Instead, this is done implicitly: the
transceiver will automatically detect TMS on the fly if the frequency
on the ADH bit is higher than the nominal frequency and this until the
DAH bit on which the frequency returns to back normal. For this
reason, the TMS is something which, same as the BRS, should be
configurable at the frame level and not at the netlink level.

The term "transceiver mode switching" is used in both ISO 11898-1 and
CiA 612-2 (although only the latter one uses the abbreviation TMS). We
adopt the same naming convention here for consistency.

Add the CANXL_TMS flag to the canxl_frame->flags list.

Signed-off-by: Vincent Mailhol <mailhol@...nel.org>
---
The CAN XL did not make it on time for the 6.17 merge windows, sorry
for that. Regardless, I finally went through the CiA 612-2 document. I
have the PWM verification and automatic calculation working fine
locally.

But before that, I want to sort out this TMS thing. That is why I am
sending this unique patch. Once this discussion reaches an end, I will
fine tune my work-in-progress accordingly.

Looking at the past exchanges, this TMS was the missing piece. I was
already troubled by this when reading ISO 11898-1. That document makes
it clear that the TMS can be deactivated but does not clearly point
out at which level (netlink or frame). The CiA 612-2 clarified this.

So this CANXL_TMS flag partially replaces the CAN_CTRLMODE_XL_TRX. I
say partially because I still do not fully understand if there should
be an option to fully deactivate the TMS at the netlink level.

My gut felling is that the TMS is intended to work in a similar
fashion as the CAN FD's BRS. In CAN FD, we do not have a
CAN_CTRLMODE_FD_BRS to tell that FD should operate only using the
nominal bittiming. And so, I do not get why CAN XL should be different
and have a CAN_CTRLMODE_XL_TMS (or CAN_CTRLMODE_XL_TRX).

Stéphane and Oliver: maybe the datasheet of your CAN XL board have
some additional insights? Did you see a register allowing to globally
deactivate the TMS (i.e. not only at the frame level)?

Finally, on a side not, now that I have my kernel.org account, I am
changing my e-mail address from mailhol.vincent@...adoo.fr to
mailhol@...nel.org. The wanadoo.fr address was my first email which I
created when I was a kid and have a special meaning to me, but it is
restricted to maximum 50 messages per hour which starts to be
problematic on threads with many people CC-ed.
---
 include/uapi/linux/can.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/uapi/linux/can.h b/include/uapi/linux/can.h
index 42abf0679fb4854cfa4f29a575e49527461a20f3..4a81500c1a06a69707accbf66224da7285d9d282 100644
--- a/include/uapi/linux/can.h
+++ b/include/uapi/linux/can.h
@@ -193,6 +193,7 @@ struct canfd_frame {
 #define CANXL_XLF 0x80 /* mandatory CAN XL frame flag (must always be set!) */
 #define CANXL_SEC 0x01 /* Simple Extended Content (security/segmentation) */
 #define CANXL_RRS 0x02 /* Remote Request Substitution */
+#define CANXL_TMS 0x04 /* Transceiver Mode Switching (fast mode using PWM encoding) */
 
 /* the 8-bit VCID is optionally placed in the canxl_frame.prio element */
 #define CANXL_VCID_OFFSET 16 /* bit offset of VCID in prio element */

---
base-commit: fa582ca7e187a15e772e6a72fe035f649b387a60
change-id: 20250727-can_tms-4bd8510bc9ce

Best regards,
-- 
Vincent Mailhol <mailhol@...nel.org>

Powered by blists - more mailing lists