Re: [canxl v7 00/17] can: netlink: add CAN XL support

[Rakuram Eswaran <rakuram.e96@gmail.com>]

On Tue, 25 Nov 2025 at 18:09, Oliver Hartkopp <socketcan@hartkopp.net> wrote:
>
> Similarly to how CAN FD reuses the bittiming logic of Classical CAN,
> CAN XL also reuses the entirety of CAN FD features, and, on top of
> that, adds new features which are specific to CAN XL.
>
> A so-called 'mixed-mode' is intended to have (XL-tolerant) CAN FD nodes
> and CAN XL nodes on one CAN segment, where the FD-controllers can talk
> CC/FD and the XL-controllers can talk CC/FD/XL. This mixed-mode
> utilizes the known error-signalling (ES) for sending CC/FD/XL frames.
> For CAN FD and CAN XL the tranceiver delay compensation (TDC) is
> supported to use common CAN and CAN-SIG transceivers.
>
> The CANXL-only mode disables the error-signalling in the CAN XL
> controller. This mode does not allow CC/FD frames to be sent but
> additionally offers a CAN XL transceiver mode switching (TMS) to send
> CAN XL frames with up to 20Mbit/s data rate. The TMS utilizes a PWM
> configuration which is added to the netlink interface.
>
> Configured with CAN_CTRLMODE_FD and CAN_CTRLMODE_XL this leads to:
>
> FD=0 XL=0 CC-only mode         (ES=1)
> FD=1 XL=0 FD/CC mixed-mode     (ES=1)
> FD=1 XL=1 XL/FD/CC mixed-mode  (ES=1)
> FD=0 XL=1 XL-only mode         (ES=0, TMS optional)
>
> Patch #1 print defined ctrlmode strings capitalized to increase the
> readability and to be in line with the 'ip' tool (iproute2).
>
> Patch #2 is a small clean-up which makes can_calc_bittiming() use
> NL_SET_ERR_MSG() instead of netdev_err().
>
> Patch #3 adds a check in can_dev_dropped_skb() to drop CAN FD frames
> when CAN FD is turned off.
>
> Patch #4 adds CAN_CTRLMODE_RESTRICTED. Note that contrary to the other
> CAN_CTRL_MODE_XL_* that are introduced in the later patches, this
> control mode is not specific to CAN XL. The nuance is that because
> this restricted mode was only added in ISO 11898-1:2024, it is made
> mandatory for CAN XL devices but optional for other protocols. This is
> why this patch is added as a preparation before introducing the core
> CAN XL logic.
>
> Patch #5 adds all the CAN XL features which are inherited from CAN FD:
> the nominal bittiming, the data bittiming and the TDC.
>
> Patch #6 add a new CAN_CTRLMODE_XL_TMS control mode which is specific
> to CAN XL to enable the transceiver mode switching (TMS) in XL-only mode.
>
> Patch #7 adds a check in can_dev_dropped_skb() to drop CAN CC/FD frames
> when the CAN XL controller is in CAN XL-only mode. The introduced
> can_dev_in_xl_only_mode() function also determines the error-signalling
> configuration for the CAN XL controllers.
>
> Patch #8 to #11 add the PWM logic for the CAN XL TMS mode.
>
> Patch #12 to #14 add different default sample-points for standard CAN and
> CAN SIG transceivers (with TDC) and CAN XL transceivers using PWM in the
> CAN XL TMS mode.
>
> Patch #15 add a dummy_can driver for netlink testing and debugging.
>
> Patch #16 check CAN frame type (CC/FD/XL) when writing those frames to the
> CAN_RAW socket and reject them if it's not supported by the CAN interface.
>
> Patch #17 increase the resolution when printing the bitrate error and
> round-up the value to 0.01% in the case the resolution would still provide
> values which would lead to 0.00%.
>

Hi Oliver,

I tested the v7 branch and below are my observations.

Static analysis: Smatch reports no warnings.

I also executed the sequence mentioned in (1). I had one question regarding
the XL data-phase bitrate: Does the ISO specification define a minimum
bit rate for CAN XL? When I set an xbitrate of 1230, the command was accepted
without any warning or error:

./iproute2-next/ip/ip link set can0 type can bitrate 1000000 xbitrate 1230 xl on tms on fd off

This value probably doesn't make sense in practice, so would it be useful to
enforce a default or minimum bitrate in the kernel or iproute2?

I have another question regarding Documentation updates for the recent CAN XL
changes. Would updating only Documentation/networking/can.rst be sufficient,
or are there other places that should be updated?
I'd be happy to help with improving the CAN documentation if needed.

(1) https://lore.kernel.org/linux-can/20251122093602.1660-1-socketcan@hartkopp.net/T/#maab93b52afce096b03c2cefd955795d43ce810ff

Best Regards,
Rakuram