[PATCH] can: canxl: add CANXL_PMS flag

[PATCH] can: canxl: add CANXL_PMS flag

[Vincent Mailhol]

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@kernel.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@wanadoo.fr to
mailhol@kernel.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@kernel.org>

Re: [PATCH] can: canxl: add CANXL_PMS flag

[Oliver Hartkopp]

Hi Vincent,

On 28.07.25 18:23, Vincent Mailhol wrote:
> 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@kernel.org>
> ---
> The CAN XL did not make it on time for the 6.17 merge windows, sorry
> for that.

Yes. I'm a bit sad about 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)?

You can take a look at the XCAN manual 
https://github.com/linux-can/can-doc/blob/master/x_can/xcan_user_manual_v350.pdf

And I have a XCANB specification which is a simple (non-DMA) CAN XL 
controller.

The TMS switching is only possible in netlink level and there's no 
TMS-style bit in the CAN XL frame layout that is pushed into the 
controller to send a CAN XL frame => there is not TMS-bit analogue to 
the BRS-bit your were searching for.

Therefore this patch is obsolete.

Btw. while we are at it: I would suggest for a name change of

CAN_CTRLMODE_XL_TRX

to

CAN_CTRLMODE_XL_TMS

as it makes clear how the controller should manage the PWM mode.

"CAN_CTRLMODE_XL_TRX" would mean "there is a CAN XL PWM enabled 
transceiver" available which tells nothing about whether the PWM mode is 
used or not.

Best regards,
Oliver

> 
> Finally, on a side not, now that I have my kernel.org account, I am
> changing my e-mail address from mailhol.vincent@wanadoo.fr to
> mailhol@kernel.org. 

Nice!

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

Re: [PATCH] can: canxl: add CANXL_PMS flag

[Vincent Mailhol]

On Tue. 29 Jul. 2025 at 03:20, Oliver Hartkopp <socketcan@hartkopp.net> wrote:

(...)

>> 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)?
> 
> You can take a look at the XCAN manual https://github.com/linux-can/can-doc/
> blob/master/x_can/xcan_user_manual_v350.pdf
> 
> And I have a XCANB specification which is a simple (non-DMA) CAN XL controller.
> 
> The TMS switching is only possible in netlink level and there's no TMS-style bit
> in the CAN XL frame layout that is pushed into the controller to send a CAN XL
> frame => there is not TMS-bit analogue to the BRS-bit your were searching for.
> 
> Therefore this patch is obsolete.

OK. I re-re-read the standard. It turns out that the CAN XL SIC is only able to
differentiate between the *nominal* NRZ and the PWM on the fly. The frequency of
data bitrate NRZ is already too high to differentiate using the 200 ns threshold.

So indeed the PMS is set once for all when the bus is inactive. And that switch
tells the controller whether it should use NRZ or PWM for the data phase. That
on the fly detection logic really confused me, but now I finally understand.

Thanks for the explanations!

> Btw. while we are at it: I would suggest for a name change of
> 
> CAN_CTRLMODE_XL_TRX
> 
> to
> 
> CAN_CTRLMODE_XL_TMS
> 
> as it makes clear how the controller should manage the PWM mode.
> 
> "CAN_CTRLMODE_XL_TRX" would mean "there is a CAN XL PWM enabled transceiver"
> available which tells nothing about whether the PWM mode is used or not.

Ack. I have the same opinion.


Yours sincerely,
Vincent Mailhol