linux-kernel - Re: [PATCH v2 05/10] can: netlink: add CAN_CTRLMODE_XL

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1154dfe5-1529-48d5-bfe9-bf77b6a4604b@hartkopp.net>
Date: Sun, 9 Nov 2025 18:40:42 +0100
From: Oliver Hartkopp <socketcan@...tkopp.net>
To: Vincent Mailhol <mailhol@...nel.org>,
 Marc Kleine-Budde <mkl@...gutronix.de>
Cc: Stéphane Grosjean <stephane.grosjean@...-networks.com>,
 Robert Nawrath <mbro1689@...il.com>, Minh Le <minh.le.aj@...esas.com>,
 Duy Nguyen <duy.nguyen.rh@...esas.com>, linux-can@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 05/10] can: netlink: add CAN_CTRLMODE_XL_TMS flag

Hi Vincent,

On 09.11.25 15:28, Vincent Mailhol wrote:
> Hello Oliver,
> 
> On 06/11/2025 at 09:42, Oliver Hartkopp wrote:
>> Hello Vincent,
>>
>> On 21.10.25 17:47, 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.
>>>
>>> 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 CAN_CTRLMODE_XL_TMS flag to the list of the CAN control modes.
>>>
>>> In the netlink interface, each boolean option is in reality a tristate
>>> in disguise: on, off or omitted. For the moment, TMS is implemented as
>>> below:
>>>
>>>     - CAN_CTRLMODE_XL_TMS is set to false: TMS is disabled.
>>>     - CAN_CTRLMODE_XL_TMS is set to true: TMS is enabled.
>>>     - CAN_CTRLMODE_XL_TMS is omitted: return -EOPNOTSUPP.
>>
>> I would propose to follow the usual pattern:
>>
>> - TMS off (default)
>> - TMS on (when selected on the command line)
> 
> OK. "TMS omitted" will be interpreted as "TMS off" in v2.
> 

Thx!

>>> For most of the other control modes, omitting a flag default to the
>>> option turned off. It could also be possible to provide a default
>>> behaviour if the TMS flag is omitted (i.e. either default to TMS off
>>> or on). However, it is not clear for the moment which default
>>> behaviour is preferable. If the usage shows a clear trend (for example
>>> if the vast majority of the users want TMS on by default), it is still
>>> possible to revisit that choice in the future. Whereas once a default
>>> option is provided, we can not change it back without breaking the
>>> interface.
>>>
>>> As a corollary, for the moment, the users will be forced to specify
>>> the TMS in the ip tool when using CAN XL.
>>>
>>> Add can_validate_xl_flags() to check the coherency of the TMS flag.
>>> That function will be reused in upcoming changes to validate the other
>>> CAN XL flags.
>>>
>>> Signed-off-by: Vincent Mailhol <mailhol@...nel.org>
>>> ---
>>> Question:
>>>
>>> Is it still possible to send Classical CAN frames when TMS is on? If
>>> not, we need to also add this filter in can_dev_dropped_skb():
>>
>> No.
>>
>> I've now learned there are two "CANXL-only" modes:
>>
>> 1. TMS on -> no CC/FD traffic
>> 2. TMS off and ERR_SIG off -> no CC/FD traffic, because CC/FD require ERR_SIG on
>> for a compliant transmission
> 
> I see. I was under the assumption that CC and FD could be used with error
> signalling off in mixed mode. Thanks!
> 
>> And there is a "mixed-mode" with CC/FD/XL with TMS off ('ERR_SIG on' is default
>> anyway).
>>
>> This "mixed-mode" requires all bitrates for CC/FD/XL to be set and all these CAN
>> protocols can be sent.
> 
> Why? Will your device reject the configuration if you omit the FD bitrate? I did
> not see anything in this direction in the ISO standard.
> 
> Did you have any source for this? Maybe the CiA provided some clarification
> which I am not aware of?

It wasn't clear to me either.

Please take a look into the X_CAN user manual here:

https://github.com/linux-can/can-doc/blob/master/x_can/xcan_user_manual_v350.pdf

1.5.5.3 Operating Mode

There you can see the valid (and invalid) modes & combinations.

When XL is on, FD also has to be on. Of course this is Bosch specific in 
the first place. But there are two modes (ERR_SIGNAL off either with TMS 
on or off) that are "CANXL-Only" which means no CC and no FD traffic as 
those need error-signalling. CAN XL is using the (CC) arbitration 
bitrate in this XL-only mode but CAN CC frames can not be sent.

I would recommend this CAN CiA Webinar from Dr. Arthur Mutter:
https://www.youtube.com/watch?v=OSEj6ISJKAM

As (only!) the CAN FD controllers are CAN XL tolerant (see video 
timestamp 18:53) the "mixed-mode" basically means "a mix of XL and FD 
controllers and protocols".

The fact that FD&XL controllers then can also send CC frames in this 
mixed-mode is just a side-effect IMO. The idea is FD & XL.

Therefore the two XL modes "XL-Only" and "mixed-mode" leads to FD on in 
the mixed-mode IMO. And this finally can be used in my "[PATCH 
b4/canxl-netlink v2] can: drop unsupported CAN frames on socket
and netdev level" patch.

Best regards,
Oliver