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@xxxxxxxxxx>
> ---
> 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@xxxxxxxxxx to
> mailhol@xxxxxxxxxx. 

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,