RFC remove CAN_CTRLMODE_XL_ERR_SIGNAL

RFC remove CAN_CTRLMODE_XL_ERR_SIGNAL

[Oliver Hartkopp]

Hi Vincent,

I've been playing with the PEAK CAN XL bitrate tool again and it gave me 
a new idea:

There were settings for different bitrates and the belonging/resulting 
flags for TMS and ES (error-signalling).

Staring at the options we have only three options for the CAN XL support 
aka "xl on":

1. Providing CC/FD/XL bitrates => ES on, TMS off (mixed-mode)

2. Providing only CC/XL bitrates => ES off, TMS off (CANXL-only)

3. Providing only CC/XL bitrates => ES off, TMS on (CANXL-only)

Therefore we only need "tms" as an additional option when xl is on.

The error signalling "on" automatically results from the availability of 
"fd on" and the FD bitrate.

Examples:

1. Providing CC/FD/XL bitrates => ES on, TMS off

ip link set can0 type can bitrate 500000 fd on dbitrate 2000000 xl on 
xbitrate 4000000

2. Providing only CC/XL bitrates => ES off, TMS off

ip link set can0 type can bitrate 500000 xl on xbitrate 4000000

3. Providing only CC/XL bitrates => ES off, TMS on

ip link set can0 type can bitrate 500000 xl on xbitrate 10000000 tms on

That's simple and provides only the needed switches, which makes 
CAN_CTRLMODE_XL_ERR_SIGNAL obsolete in the netlink API.

What do you think about this approach?

Best regards,
Oliver

Re: RFC remove CAN_CTRLMODE_XL_ERR_SIGNAL

[Vincent Mailhol]

Hi Oliver,

On 09/11/2025 at 22:07, Oliver Hartkopp wrote:
> Hi Vincent,
> 
> I've been playing with the PEAK CAN XL bitrate tool again and it gave me a new
> idea:
> 
> There were settings for different bitrates and the belonging/resulting flags for
> TMS and ES (error-signalling).
> 
> Staring at the options we have only three options for the CAN XL support aka "xl
> on":
> 
> 1. Providing CC/FD/XL bitrates => ES on, TMS off (mixed-mode)
> 
> 2. Providing only CC/XL bitrates => ES off, TMS off (CANXL-only)
> 
> 3. Providing only CC/XL bitrates => ES off, TMS on (CANXL-only)

Why isn't

  4. Providing only CC/XL bitrates => ES on, TMS off

a valid option?

> Therefore we only need "tms" as an additional option when xl is on.
> 
> The error signalling "on" automatically results from the availability of "fd on"
> and the FD bitrate.
> 
> Examples:
> 
> 1. Providing CC/FD/XL bitrates => ES on, TMS off
> 
> ip link set can0 type can bitrate 500000 fd on dbitrate 2000000 xl on xbitrate
> 4000000
> 
> 2. Providing only CC/XL bitrates => ES off, TMS off
> 
> ip link set can0 type can bitrate 500000 xl on xbitrate 4000000
> 
> 3. Providing only CC/XL bitrates => ES off, TMS on
> 
> ip link set can0 type can bitrate 500000 xl on xbitrate 10000000 tms on
> 
> That's simple and provides only the needed switches, which makes
> CAN_CTRLMODE_XL_ERR_SIGNAL obsolete in the netlink API.
> 
> What do you think about this approach?

What really bothers me here is that the ISO standard explicitly state that error
signaling is a configurable option. Making this an implicit option would result
in a somehow non-compliant implementation.

I appreciate that for most of the use cases the error signaling can be inferred
from the other values, and this is what I tried to implement (c.f. the table of
default values which I put in my patch).

But I want to leave room so that people who wants to push the standard to its
limits can.

I see this a bit like the can_frame->len8_dlc thing. Should you use DLCs greater
than 8 in production code? Hell no! But I still want the implementation to give
me this option so that I can do my weird tests.


Yours sincerely,
Vincent Mailhol

Re: RFC remove CAN_CTRLMODE_XL_ERR_SIGNAL

[Oliver Hartkopp]

Hi Vincent,

On 10.11.25 22:22, Vincent Mailhol wrote:
> On 09/11/2025 at 22:07, Oliver Hartkopp wrote:
>> I've been playing with the PEAK CAN XL bitrate tool again and it gave me a new
>> idea:
>>
>> There were settings for different bitrates and the belonging/resulting flags for
>> TMS and ES (error-signalling).
>>
>> Staring at the options we have only three options for the CAN XL support aka "xl
>> on":
>>
>> 1. Providing CC/FD/XL bitrates => ES on, TMS off (mixed-mode)
>>
>> 2. Providing only CC/XL bitrates => ES off, TMS off (CANXL-only)
>>
>> 3. Providing only CC/XL bitrates => ES off, TMS on (CANXL-only)
> 
> Why isn't
> 
>    4. Providing only CC/XL bitrates => ES on, TMS off
> 
> a valid option?

I had an off-list discussion with Stéphane and other PEAK System experts 
in June and the outcome was that CC/XL bitrates with ES on and TMS off 
is possible (only with the PEAK CAN XL IP core!) but will result in a 
nightmare for support teams.

The CAN bus will crash if it receives a CAN FD frame.

This is basically the same with the Bosch X_CAN IP core where you need 
to enable CAN FD for performing the mixed-mode. What would you set as a 
FD bitrate there? There is no "nothing" to be set into the registers. 
You might set 2MBit/s as default but that might crash either when it 
doesn't fit.

Looking back in our older discussions with Stéphane I found this:

https://lore.kernel.org/linux-can/DBAPR10MB41879125DC7369359E4AB256D467A@DBAPR10MB4187.EURPRD10.PROD.OUTLOOK.COM/#t

Stéphane wrote:

---

According to [3] lines 170-184, the CAN_CTRLMODE_FD and CAN_CTRLMODE_XL 
flags are not mutually exclusive, so why introduce 
CAN_CTRLMODE_XL_ERR_SIGNAL [2] when the combinations of CAN_CTRLMODE_FD 
and CAN_CTRLMODE_XL would allow us to deduce this?

Indeed:

can_priv->ctrlmode & (CAN_CTRLMODE_FD|CAN_CTRLMODE_XL) ==

CAN_CTRLMODE_FD                    CANFD mode (n/a)
CAN_CTRLMODE_XL|CAN_CTRLMODE_FD    mixed-CANXL => error_signaling=ON
CAN_CTRLMODE_XL                    pure-CANXL => error_signaling=OFF

---

With the CAN_CTRLMODE_XL (pure-CANXL) the ES is always off and the TMS 
becomes an option to be switched on (default off).

And the more I think about it, the more I would like to go for this 
solution.

This setup covers all Bosch use-case slides and Bosch CAN XL IP core 
documentations (e.g. with the 1.5.5.3 Operating Mode table).

And we can omit the introduction of the CAN_CTRLMODE_XL_ERR_SIGNAL flag 
as this can be retrieved internally from CTRLMODE_XL and CAN_CTRLMODE_FD 
to be set into the controller registers.

Not defining the FD bitrate in the mixed-mode causes more harm (to the 
system and the CAN bus itself) than urging the user to define it. Even 
if he doesn't use CAN FD frames.

In the (really unlikely) case that someone shows up with a valid 
use-case (like len8_dlc) and separately wants to fiddle with the ES 
flags, we might introduce such a flag later. But I bet this will not happen.

>> Therefore we only need "tms" as an additional option when xl is on.
>>
>> The error signalling "on" automatically results from the availability of "fd on"
>> and the FD bitrate.
>>
>> Examples:
>>
>> 1. Providing CC/FD/XL bitrates => ES on, TMS off
>>
>> ip link set can0 type can bitrate 500000 fd on dbitrate 2000000 xl on xbitrate
>> 4000000
>>
>> 2. Providing only CC/XL bitrates => ES off, TMS off
>>
>> ip link set can0 type can bitrate 500000 xl on xbitrate 4000000
>>
>> 3. Providing only CC/XL bitrates => ES off, TMS on
>>
>> ip link set can0 type can bitrate 500000 xl on xbitrate 10000000 tms on
>>
>> That's simple and provides only the needed switches, which makes
>> CAN_CTRLMODE_XL_ERR_SIGNAL obsolete in the netlink API.
>>
>> What do you think about this approach?
> 
> What really bothers me here is that the ISO standard explicitly state that error
> signaling is a configurable option. Making this an implicit option would result
> in a somehow non-compliant implementation.

Yes. According to all the Bosch slides ES=on results in mixed-mode and 
ES=off results in CANXL-only. You need this bit to distinguish these two 
operation modes when using CAN XL (mixed or pure).

The fact that we need an arbitration bitrate for the CANXL-only modes 
does not imply we can send or receive CC frames (with ES off).

> I appreciate that for most of the use cases the error signaling can be inferred
> from the other values, and this is what I tried to implement (c.f. the table of
> default values which I put in my patch).
> 
> But I want to leave room so that people who wants to push the standard to its
> limits can.

Either CAN CC or CAN FD with ES=off are marked as an "invalid 
configuration" in the 1.5.5.3 Operating Mode table. And I'm pretty sure 
the CAN XL inventor's implementation of the CAN XL IP core is compliant 
with the standard here. Maybe the standard is unclear in this topic or 
left some details.

What is your interpretation of the standard here?
What do you think has to be supported beyond the features that Stéphane 
and I suggest?

> I see this a bit like the can_frame->len8_dlc thing. Should you use DLCs greater
> than 8 in production code? Hell no! But I still want the implementation to give
> me this option so that I can do my weird tests.

Ack. But so far I do not see such weird options. And introducing code 
into the kernel there is no user for and that's potentially only adding 
complexity in the API that might lead to misconfiguration is not 
well-received.

Best regards,
Oliver

Re: RFC remove CAN_CTRLMODE_XL_ERR_SIGNAL

[Stéphane Grosjean]

Hi,

If I may say so:

>> Why isn't 
>> 
>> 4. Providing only CC/XL bitrates => ES on, TMS off 
>> 
>> a valid option? 

It works... But when only CANXL controllers (all configured in this way) are stuck to the wire! They communicate in a kind of CANFD++ protocol that allows the same (high) data rates but with 2KB frames.

When such 2KB CANXL frames are written to the bus, any CAN 2.0 controller will indicate frame errors, whereas a controller configured for CANFD will not be affected (no error or frames raised)

On the other hand, writing CANFD frames *without* BRS but DLC>8 is OK (the CANXL node reads them as CAN_CC frames of course) while writing CANFD frames with BRS obviously turns to error on the bus. CAN 2.0 node turns into error in every case.

Finally, writing CAN 2.0 frames is ok for everyone in that configuration.

I've tried to summarize all of this in the following tables:

CC/XL bitrates + ES=on TMS=off
                   
CANXL1             CANXL2            CANFD1             CANFD2             CANCC
writes 2KB frames  reads 2KB frames  no error/no frame  no error/no frame  frm errors
reads DLC>8        reads DLC>8       writes DLC>8       reads DLC>8        not connected
frm errors         frm errors        writes DLC>8       frm errors         frm errors
reads frames       reads frames      reads frames       reads frames       writes frames

Once ES is turned off, then you obviously enters a new protocol, so communication is less mixed:

CC/XL bitrates + ES=off TMS=off

CANXL1             CANXL2            CANFD1             CANFD2             CANCC
writes 2KB frames  reads 2KB frames  no error/no frame  no error/no frame  not connected
stuff error        stuff error       writes DLC>8       reads DLC>8        not connected
stuff error        stuff error       reads frames       reads frames       writes frames

CC/XL bitrates + ES=off TMS=on (aka pure CANXL)

CANXL1             CANXL2            CANFD1             CANFD2             CANCC
writes 2KB frames  reads 2KB frames  no error/no frame  no error/no frame  not connected
stuff error        stuff error       writes DLC>8       reads DLC>8        not connected
stuff error        stuff error       reads frames       reads frames       writes frames

Hope this helps,

-- Stéphane


----- Mail original ----- 

De: "Oliver Hartkopp" <socketcan@hartkopp.net> 
À: "Vincent Mailhol" <mailhol@kernel.org>, "Stéphane Grosjean" <stephane.grosjean@hms-networks.com> 
Cc: linux-can@vger.kernel.org 
Envoyé: Mardi 11 Novembre 2025 15:12:56 
Objet: Re: RFC remove CAN_CTRLMODE_XL_ERR_SIGNAL 

Hi Vincent, 

On 10.11.25 22:22, Vincent Mailhol wrote: 
> On 09/11/2025 at 22:07, Oliver Hartkopp wrote: 
>> I've been playing with the PEAK CAN XL bitrate tool again and it gave me a new 
>> idea: 
>> 
>> There were settings for different bitrates and the belonging/resulting flags for 
>> TMS and ES (error-signalling). 
>> 
>> Staring at the options we have only three options for the CAN XL support aka "xl 
>> on": 
>> 
>> 1. Providing CC/FD/XL bitrates => ES on, TMS off (mixed-mode) 
>> 
>> 2. Providing only CC/XL bitrates => ES off, TMS off (CANXL-only) 
>> 
>> 3. Providing only CC/XL bitrates => ES off, TMS on (CANXL-only) 
> 
> Why isn't 
> 
> 4. Providing only CC/XL bitrates => ES on, TMS off 
> 
> a valid option? 

I had an off-list discussion with Stéphane and other PEAK System experts 
in June and the outcome was that CC/XL bitrates with ES on and TMS off 
is possible (only with the PEAK CAN XL IP core!) but will result in a 
nightmare for support teams. 

The CAN bus will crash if it receives a CAN FD frame. 

This is basically the same with the Bosch X_CAN IP core where you need 
to enable CAN FD for performing the mixed-mode. What would you set as a 
FD bitrate there? There is no "nothing" to be set into the registers. 
You might set 2MBit/s as default but that might crash either when it 
doesn't fit. 

Looking back in our older discussions with Stéphane I found this: 

https://lore.kernel.org/linux-can/DBAPR10MB41879125DC7369359E4AB256D467A@DBAPR10MB4187.EURPRD10.PROD.OUTLOOK.COM/#t 

Stéphane wrote: 

--- 

According to [3] lines 170-184, the CAN_CTRLMODE_FD and CAN_CTRLMODE_XL 
flags are not mutually exclusive, so why introduce 
CAN_CTRLMODE_XL_ERR_SIGNAL [2] when the combinations of CAN_CTRLMODE_FD 
and CAN_CTRLMODE_XL would allow us to deduce this? 

Indeed: 

can_priv->ctrlmode & (CAN_CTRLMODE_FD|CAN_CTRLMODE_XL) == 

CAN_CTRLMODE_FD CANFD mode (n/a) 
CAN_CTRLMODE_XL|CAN_CTRLMODE_FD mixed-CANXL => error_signaling=ON 
CAN_CTRLMODE_XL pure-CANXL => error_signaling=OFF 

--- 

With the CAN_CTRLMODE_XL (pure-CANXL) the ES is always off and the TMS 
becomes an option to be switched on (default off). 

And the more I think about it, the more I would like to go for this 
solution. 

This setup covers all Bosch use-case slides and Bosch CAN XL IP core 
documentations (e.g. with the 1.5.5.3 Operating Mode table). 

And we can omit the introduction of the CAN_CTRLMODE_XL_ERR_SIGNAL flag 
as this can be retrieved internally from CTRLMODE_XL and CAN_CTRLMODE_FD 
to be set into the controller registers. 

Not defining the FD bitrate in the mixed-mode causes more harm (to the 
system and the CAN bus itself) than urging the user to define it. Even 
if he doesn't use CAN FD frames. 

In the (really unlikely) case that someone shows up with a valid 
use-case (like len8_dlc) and separately wants to fiddle with the ES 
flags, we might introduce such a flag later. But I bet this will not happen. 

>> Therefore we only need "tms" as an additional option when xl is on. 
>> 
>> The error signalling "on" automatically results from the availability of "fd on" 
>> and the FD bitrate. 
>> 
>> Examples: 
>> 
>> 1. Providing CC/FD/XL bitrates => ES on, TMS off 
>> 
>> ip link set can0 type can bitrate 500000 fd on dbitrate 2000000 xl on xbitrate 
>> 4000000 
>> 
>> 2. Providing only CC/XL bitrates => ES off, TMS off 
>> 
>> ip link set can0 type can bitrate 500000 xl on xbitrate 4000000 
>> 
>> 3. Providing only CC/XL bitrates => ES off, TMS on 
>> 
>> ip link set can0 type can bitrate 500000 xl on xbitrate 10000000 tms on 
>> 
>> That's simple and provides only the needed switches, which makes 
>> CAN_CTRLMODE_XL_ERR_SIGNAL obsolete in the netlink API. 
>> 
>> What do you think about this approach? 
> 
> What really bothers me here is that the ISO standard explicitly state that error 
> signaling is a configurable option. Making this an implicit option would result 
> in a somehow non-compliant implementation. 

Yes. According to all the Bosch slides ES=on results in mixed-mode and 
ES=off results in CANXL-only. You need this bit to distinguish these two 
operation modes when using CAN XL (mixed or pure). 

The fact that we need an arbitration bitrate for the CANXL-only modes 
does not imply we can send or receive CC frames (with ES off). 

> I appreciate that for most of the use cases the error signaling can be inferred 
> from the other values, and this is what I tried to implement (c.f. the table of 
> default values which I put in my patch). 
> 
> But I want to leave room so that people who wants to push the standard to its 
> limits can. 

Either CAN CC or CAN FD with ES=off are marked as an "invalid 
configuration" in the 1.5.5.3 Operating Mode table. And I'm pretty sure 
the CAN XL inventor's implementation of the CAN XL IP core is compliant 
with the standard here. Maybe the standard is unclear in this topic or 
left some details. 

What is your interpretation of the standard here? 
What do you think has to be supported beyond the features that Stéphane 
and I suggest? 

> I see this a bit like the can_frame->len8_dlc thing. Should you use DLCs greater 
> than 8 in production code? Hell no! But I still want the implementation to give 
> me this option so that I can do my weird tests. 

Ack. But so far I do not see such weird options. And introducing code 
into the kernel there is no user for and that's potentially only adding 
complexity in the API that might lead to misconfiguration is not 
well-received. 

Best regards, 
Oliver

Re: RFC remove CAN_CTRLMODE_XL_ERR_SIGNAL

[Oliver Hartkopp]

Hi Stéphane,

many thanks for your effort with the real-world measurements in your 
test setup!!

On 14.11.25 16:17, Stéphane Grosjean wrote:
> Hi,
> 
> If I may say so:
> 
>>> Why isn't
>>>
>>> 4. Providing only CC/XL bitrates => ES on, TMS off
>>>
>>> a valid option?
> 
> It works... But when only CANXL controllers (all configured in this way) are stuck to the wire! They communicate in a kind of CANFD++ protocol that allows the same (high) data rates but with 2KB frames.
> 
> When such 2KB CANXL frames are written to the bus, any CAN 2.0 controller will indicate frame errors, whereas a controller configured for CANFD will not be affected (no error or frames raised)

Yes. This is the mixed-mode (FD/XL) scenario. CAN CC controllers can not 
handle FD/XL frames. Therefore the mixed-mode examples on the Bosch 
slides only consist of XL and FD controllers where the latter are XL 
tolerant.

> On the other hand, writing CANFD frames *without* BRS but DLC>8 is OK (the CANXL node reads them as CAN_CC frames of course) while writing CANFD frames with BRS obviously turns to error on the bus. CAN 2.0 node turns into error in every case.

When BRS=on the FD data bitrate settings are needed, which have not been 
configured. Well this is then expected.

> Finally, writing CAN 2.0 frames is ok for everyone in that configuration.
> 
> I've tried to summarize all of this in the following tables:

> CC/XL bitrates + ES=on TMS=off
>                     
> CANXL1             CANXL2            CANFD1             CANFD2             CANCC
> writes 2KB frames  reads 2KB frames  no error/no frame  no error/no frame  frm errors
> reads DLC>8        reads DLC>8       writes DLC>8       reads DLC>8        not connected
(the above seems to be the BRS off case)> frm errors         frm errors 
       writes DLC>8       frm errors         frm errors
(the above seems to be the BRS on case)> reads frames       reads frames 
      reads frames       reads frames       writes frames

Summarizing this is the CC/FD/XL mixed mode (ES=on) which fails when the 
FD bitrates are unset.

> Once ES is turned off, then you obviously enters a new protocol, so communication is less mixed:> > CC/XL bitrates + ES=off TMS=off
> 
> CANXL1             CANXL2            CANFD1             CANFD2             CANCC
> writes 2KB frames  reads 2KB frames  no error/no frame  no error/no frame  not connected

CAN FD is CAN XL tolerant and creates no error when it sees a CAN XL frame.

> stuff error        stuff error       writes DLC>8       reads DLC>8        not connected
> stuff error        stuff error       reads frames       reads frames       writes frames

What would be the use-case here? Hiding XL from FD traffic without BRS 
on the same CAN segment? O_o

> CC/XL bitrates + ES=off TMS=on (aka pure CANXL)
> 
> CANXL1             CANXL2            CANFD1             CANFD2             CANCC
> writes 2KB frames  reads 2KB frames  no error/no frame  no error/no frame  not connected
> stuff error        stuff error       writes DLC>8       reads DLC>8        not connected
> stuff error        stuff error       reads frames       reads frames       writes frames

Same here.

> Hope this helps,

Yes. It proves that broken setups are broken.

ES=on is used for mixed-mode (FD/XL) which also can handle CC frames 
(but with FD/XL controllers only)
And omitting the FD bitrates in mixed-mode turns out to be broken too.

ES=off is used for CANXL-only modes which can have TMS=off or TMS=on

Turning it upside down (not from the ES perspective):

CAN_CTRLMODE_XL|CAN_CTRLMODE_FD    mixed-mode (CC/FD/XL)
CAN_CTRLMODE_XL                    CANXL-only (optional TMS on)

And the error signalling state to be set into the CAN XL controllers 
configuration registers can be calculated by this function:

+static inline bool can_dev_err_signal_is_disabled(struct can_priv *priv)
+{
+    const u32 mixed_mode = CAN_CTRLMODE_FD | CAN_CTRLMODE_XL;
+
+    /* When CAN XL is enabled but FD is disabled we are running in
+     * the so-called 'XL-only mode' where the error signalling is
+     * disabled.
+     * The so-called CC/FD/XL 'mixed mode' requires error signalling.
+     */
+    return ((priv->ctrlmode & mixed_mode) == CAN_CTRLMODE_XL);
+}

The requirements and prerequisites are simple:

1. CAN_CTRLMODE_XL|CAN_CTRLMODE_FD -> needs CC/FD/XL bitrates and offers 
(X)TDC handling

2. CAN_CTRLMODE_XL -> needs CC/XL bitrates and offers

2a. TMS off (default) with XTDC handling

2b. TMS on with PWM handling

IMO the CAN_CTRLMODE_XL_ERR_SIGNAL patch should be completely omitted.

The valid/working use-cases can be completely met with the outlined 
simple CAN_CTRLMODE_XL / CAN_CTRLMODE_FD handling.

Best regards,
Oliver

> 
> -- Stéphane
> 
> 
> ----- Mail original -----
> 
> De: "Oliver Hartkopp" <socketcan@hartkopp.net>
> À: "Vincent Mailhol" <mailhol@kernel.org>, "Stéphane Grosjean" <stephane.grosjean@hms-networks.com>
> Cc: linux-can@vger.kernel.org
> Envoyé: Mardi 11 Novembre 2025 15:12:56
> Objet: Re: RFC remove CAN_CTRLMODE_XL_ERR_SIGNAL
> 
> Hi Vincent,
> 
> On 10.11.25 22:22, Vincent Mailhol wrote:
>> On 09/11/2025 at 22:07, Oliver Hartkopp wrote:
>>> I've been playing with the PEAK CAN XL bitrate tool again and it gave me a new
>>> idea:
>>>
>>> There were settings for different bitrates and the belonging/resulting flags for
>>> TMS and ES (error-signalling).
>>>
>>> Staring at the options we have only three options for the CAN XL support aka "xl
>>> on":
>>>
>>> 1. Providing CC/FD/XL bitrates => ES on, TMS off (mixed-mode)
>>>
>>> 2. Providing only CC/XL bitrates => ES off, TMS off (CANXL-only)
>>>
>>> 3. Providing only CC/XL bitrates => ES off, TMS on (CANXL-only)
>>
>> Why isn't
>>
>> 4. Providing only CC/XL bitrates => ES on, TMS off
>>
>> a valid option?
> 
> I had an off-list discussion with Stéphane and other PEAK System experts
> in June and the outcome was that CC/XL bitrates with ES on and TMS off
> is possible (only with the PEAK CAN XL IP core!) but will result in a
> nightmare for support teams.
> 
> The CAN bus will crash if it receives a CAN FD frame.
> 
> This is basically the same with the Bosch X_CAN IP core where you need
> to enable CAN FD for performing the mixed-mode. What would you set as a
> FD bitrate there? There is no "nothing" to be set into the registers.
> You might set 2MBit/s as default but that might crash either when it
> doesn't fit.
> 
> Looking back in our older discussions with Stéphane I found this:
> 
> https://lore.kernel.org/linux-can/DBAPR10MB41879125DC7369359E4AB256D467A@DBAPR10MB4187.EURPRD10.PROD.OUTLOOK.COM/#t
> 
> Stéphane wrote:
> 
> ---
> 
> According to [3] lines 170-184, the CAN_CTRLMODE_FD and CAN_CTRLMODE_XL
> flags are not mutually exclusive, so why introduce
> CAN_CTRLMODE_XL_ERR_SIGNAL [2] when the combinations of CAN_CTRLMODE_FD
> and CAN_CTRLMODE_XL would allow us to deduce this?
> 
> Indeed:
> 
> can_priv->ctrlmode & (CAN_CTRLMODE_FD|CAN_CTRLMODE_XL) ==
> 
> CAN_CTRLMODE_FD CANFD mode (n/a)
> CAN_CTRLMODE_XL|CAN_CTRLMODE_FD mixed-CANXL => error_signaling=ON
> CAN_CTRLMODE_XL pure-CANXL => error_signaling=OFF
> 
> ---
> 
> With the CAN_CTRLMODE_XL (pure-CANXL) the ES is always off and the TMS
> becomes an option to be switched on (default off).
> 
> And the more I think about it, the more I would like to go for this
> solution.
> 
> This setup covers all Bosch use-case slides and Bosch CAN XL IP core
> documentations (e.g. with the 1.5.5.3 Operating Mode table).
> 
> And we can omit the introduction of the CAN_CTRLMODE_XL_ERR_SIGNAL flag
> as this can be retrieved internally from CTRLMODE_XL and CAN_CTRLMODE_FD
> to be set into the controller registers.
> 
> Not defining the FD bitrate in the mixed-mode causes more harm (to the
> system and the CAN bus itself) than urging the user to define it. Even
> if he doesn't use CAN FD frames.
> 
> In the (really unlikely) case that someone shows up with a valid
> use-case (like len8_dlc) and separately wants to fiddle with the ES
> flags, we might introduce such a flag later. But I bet this will not happen.
> 
>>> Therefore we only need "tms" as an additional option when xl is on.
>>>
>>> The error signalling "on" automatically results from the availability of "fd on"
>>> and the FD bitrate.
>>>
>>> Examples:
>>>
>>> 1. Providing CC/FD/XL bitrates => ES on, TMS off
>>>
>>> ip link set can0 type can bitrate 500000 fd on dbitrate 2000000 xl on xbitrate
>>> 4000000
>>>
>>> 2. Providing only CC/XL bitrates => ES off, TMS off
>>>
>>> ip link set can0 type can bitrate 500000 xl on xbitrate 4000000
>>>
>>> 3. Providing only CC/XL bitrates => ES off, TMS on
>>>
>>> ip link set can0 type can bitrate 500000 xl on xbitrate 10000000 tms on
>>>
>>> That's simple and provides only the needed switches, which makes
>>> CAN_CTRLMODE_XL_ERR_SIGNAL obsolete in the netlink API.
>>>
>>> What do you think about this approach?
>>
>> What really bothers me here is that the ISO standard explicitly state that error
>> signaling is a configurable option. Making this an implicit option would result
>> in a somehow non-compliant implementation.
> 
> Yes. According to all the Bosch slides ES=on results in mixed-mode and
> ES=off results in CANXL-only. You need this bit to distinguish these two
> operation modes when using CAN XL (mixed or pure).
> 
> The fact that we need an arbitration bitrate for the CANXL-only modes
> does not imply we can send or receive CC frames (with ES off).
> 
>> I appreciate that for most of the use cases the error signaling can be inferred
>> from the other values, and this is what I tried to implement (c.f. the table of
>> default values which I put in my patch).
>>
>> But I want to leave room so that people who wants to push the standard to its
>> limits can.
> 
> Either CAN CC or CAN FD with ES=off are marked as an "invalid
> configuration" in the 1.5.5.3 Operating Mode table. And I'm pretty sure
> the CAN XL inventor's implementation of the CAN XL IP core is compliant
> with the standard here. Maybe the standard is unclear in this topic or
> left some details.
> 
> What is your interpretation of the standard here?
> What do you think has to be supported beyond the features that Stéphane
> and I suggest?
> 
>> I see this a bit like the can_frame->len8_dlc thing. Should you use DLCs greater
>> than 8 in production code? Hell no! But I still want the implementation to give
>> me this option so that I can do my weird tests.
> 
> Ack. But so far I do not see such weird options. And introducing code
> into the kernel there is no user for and that's potentially only adding
> complexity in the API that might lead to misconfiguration is not
> well-received.
> 
> Best regards,
> Oliver

Re: RFC remove CAN_CTRLMODE_XL_ERR_SIGNAL

[Vincent Mailhol]

Hi Oliver,

I was very confused by your message and I spent the week thinking about it. What
bothered me the most is that the standard and the X_CAN's 1.5.5.3 table just
contradicted each other.

And so, I did my best to investigate and find which one is incorrect. Reading
some other sections of the X_CAN datasheet gave me the answer.

On 11/11/2025 at 15:12, Oliver Hartkopp wrote:
> Hi Vincent,
> 
> On 10.11.25 22:22, Vincent Mailhol wrote:
>> On 09/11/2025 at 22:07, Oliver Hartkopp wrote:
>>> I've been playing with the PEAK CAN XL bitrate tool again and it gave me a new
>>> idea:
>>>
>>> There were settings for different bitrates and the belonging/resulting flags for
>>> TMS and ES (error-signalling).
>>>
>>> Staring at the options we have only three options for the CAN XL support aka "xl
>>> on":
>>>
>>> 1. Providing CC/FD/XL bitrates => ES on, TMS off (mixed-mode)
>>>
>>> 2. Providing only CC/XL bitrates => ES off, TMS off (CANXL-only)
>>>
>>> 3. Providing only CC/XL bitrates => ES off, TMS on (CANXL-only)
>>
>> Why isn't
>>
>>    4. Providing only CC/XL bitrates => ES on, TMS off
>>
>> a valid option?
> 
> I had an off-list discussion with Stéphane and other PEAK System experts in June
> and the outcome was that CC/XL bitrates with ES on and TMS off is possible (only
> with the PEAK CAN XL IP core!) but will result in a nightmare for support teams.

I will start by challenging this assertion.

Looking at the X_CAN datasheet, I see:

  1.4.5.22.2 Classical CAN

  All Classical CAN TX messages are either accepted or rejected, see
  TX_FILTER_CTRL0.CC_CAN bit register. There is no other option for such
  Classical CAN protocol. The TX filter elements are only used
  for the CAN XL protocol.

  1.4.5.22.3 CAN FD

  All CAN FD messages are either accepted or rejected, see
  TX_FILTER_CTRL0.CAN_FD bit register. There is no other option for the CAN FD
  protocol. The TX filter elements are only used for the CAN XL
  protocol.

Did you try those?

> The CAN bus will crash if it receives a CAN FD frame.

I do not understand what you want to prove here. Isn't this the expected behaviour?
If you are in XL with error signaling off and receive a CAN FD frame, does it
crash the bus?

If you are in XL with TMS on and receive a CAN FD frame, does it crash the bus?

The same goes with Stéphane's observation. Where is the problem? Which
observation does not meet the expectations?

> This is basically the same with the Bosch X_CAN IP core where you need to enable
> CAN FD for performing the mixed-mode. What would you set as a FD bitrate there?
> There is no "nothing" to be set into the registers. You might set 2MBit/s as
> default but that might crash either when it doesn't fit.

Once you set the TX_FILTER_CTRL0.CAN_FD bit, all the CAN FD frames will be
discarded and the FD bitrate will never be used. What should you put in the
register? That is not my problem. If the X_CAN is well designed, it should be OK
to leave those to zero. If you still need to put some dummy values, complain to
the X_CAN team, not to me.

> Looking back in our older discussions with Stéphane I found this:
> 
> https://lore.kernel.org/linux-can/
> DBAPR10MB41879125DC7369359E4AB256D467A@DBAPR10MB4187.EURPRD10.PROD.OUTLOOK.COM/#t
> 
> Stéphane wrote:
> 
> ---
> 
> According to [3] lines 170-184, the CAN_CTRLMODE_FD and CAN_CTRLMODE_XL flags
> are not mutually exclusive, so why introduce CAN_CTRLMODE_XL_ERR_SIGNAL [2] when
> the combinations of CAN_CTRLMODE_FD and CAN_CTRLMODE_XL would allow us to deduce
> this?
> 
> Indeed:
> 
> can_priv->ctrlmode & (CAN_CTRLMODE_FD|CAN_CTRLMODE_XL) ==
> 
> CAN_CTRLMODE_FD                    CANFD mode (n/a)
> CAN_CTRLMODE_XL|CAN_CTRLMODE_FD    mixed-CANXL => error_signaling=ON
> CAN_CTRLMODE_XL                    pure-CANXL => error_signaling=OFF
> 
> ---
> 
> With the CAN_CTRLMODE_XL (pure-CANXL) the ES is always off and the TMS becomes
> an option to be switched on (default off).
> 
> And the more I think about it, the more I would like to go for this solution.
> 
> This setup covers all Bosch use-case slides and Bosch CAN XL IP core
> documentations (e.g. with the 1.5.5.3 Operating Mode table).

You are referring to those slides, right?

https://www.bosch-semiconductors.com/media/ip_modules/pdf_2/can_xl_1/20230717_can_xl_overview.pdf

I see in slide 16:

  Error Signaling: Software Configurable: ON/OFF

If you are just referring to the example use cases of slide 24, then no. You
should not be tunnel-visioned on a single slide when some other slide clearly
states differently.

And in which world does an *example* use case in a slide deck take precedence on
the ISO standard? I am sorry, but taking a random slide to disprove what the
standard requires is not a receivable argument.

> And we can omit the introduction of the CAN_CTRLMODE_XL_ERR_SIGNAL flag as this
> can be retrieved internally from CTRLMODE_XL and CAN_CTRLMODE_FD to be set into
> the controller registers.
> 
> Not defining the FD bitrate in the mixed-mode causes more harm (to the system
> and the CAN bus itself) than urging the user to define it. Even if he doesn't
> use CAN FD frames.

I also want to challenge this. You are claiming that the error signaling should
be an implicit value. What if someone requires error signaling because of some
safety requirements?

Here you are just silently turning off a safety feature. How is the end user
meant to see the connection between disabling CAN FD and error signaling? By
dropping the flag, we also loss the reporting. No more way to see in the netlink
interface if error signaling is on or off.

The more I think about it, the more I am getting convinced that silently turning
off a safety feature and hiding its value is nothing but a bad decision.

> In the (really unlikely) case that someone shows up with a valid use-case (like
> len8_dlc) and separately wants to fiddle with the ES flags, we might introduce
> such a flag later. But I bet this will not happen.
The reality is that the people on the linux-can are a small community and the
security/safety researcher is another small community. And the intersection of
those two communities is rather small.

Before joining the linux-can mailing list, I was well aware of the lack of the
len8_dlc and the TDC, and so were the people around me. But no one reported the
problem, mostly because none of us were familiar with open source communities
and we were all using some alternatives (proprietary drivers…)

Once I showed up and implemented those features, we saw people using those.

My point here is that taking the request on the linux-can mailing list is not a
good benchmark to measure if people use a feature or not. At least, this is what
occurred for the len8_dlc and the TDC and I see no reason for this to be
different here.

(...)

> Either CAN CC or CAN FD with ES=off are marked as an "invalid configuration" in
> the 1.5.5.3 Operating Mode table. And I'm pretty sure the CAN XL inventor's
> implementation of the CAN XL IP core is compliant with the standard here. Maybe
> the standard is unclear in this topic or left some details.

1.5.5.3 also shows that FDOE is on whenever XLOE is on (even if error signaling
is off or if TMS is on). Does it mean that you can always send FD frames? No.

That table can just not be used in isolation.

What is not clear here is the 1.5.5.3 Operating Mode table, not the standard.

> What is your interpretation of the standard here?

It is not an interpretation. The standard clearly require that error signaling
should be configurable.

> What do you think has to be supported beyond the features that Stéphane and I
> suggest?

FD off + XL on + error signaling on.

>> I see this a bit like the can_frame->len8_dlc thing. Should you use DLCs greater
>> than 8 in production code? Hell no! But I still want the implementation to give
>> me this option so that I can do my weird tests.
> 
> Ack. But so far I do not see such weird options. And introducing code into the
> kernel there is no user for and that's potentially only adding complexity in the
> API that might lead to misconfiguration is not well-received.

It seems to me that Stéphane is able to use it and that you should also be able
to by using TX_FILTER_CTRL0.CAN_FD. And I could also test it with my dummy-can
driver. That should be enough testing, right?


I made my mind here. It seems to me that you are tunneled-visioned on table
1.5.5.3 when the other sections of your datasheet clearly point out that you can
deactivate CAN FD using TX_FILTER_CTRL0.CAN_FD. If you just partially read your
datasheet to then jump to some conclusion, I would not feel confident to follow
this.

The process to publish an ISO standard is strict with many domain expert
involved. I do not think that any of us here is smarter that the combined
mindset of the ISO 11898 committee. I would need a stronger argument to convince
me that the ISO committee did a wrong design choice into making this error
signaling configurable.


Yours sincerely,
Vincent Mailhol

Re: RFC remove CAN_CTRLMODE_XL_ERR_SIGNAL

[Oliver Hartkopp]

Hi Vincent,

On 15.11.25 14:06, Vincent Mailhol wrote:
> Hi Oliver,
> 
> I was very confused by your message and I spent the week thinking about it. What
> bothered me the most is that the standard and the X_CAN's 1.5.5.3 table just
> contradicted each other.
> 
> And so, I did my best to investigate and find which one is incorrect. Reading
> some other sections of the X_CAN datasheet gave me the answer.
> 
> On 11/11/2025 at 15:12, Oliver Hartkopp wrote:
>> Hi Vincent,
>>
>> On 10.11.25 22:22, Vincent Mailhol wrote:
>>> On 09/11/2025 at 22:07, Oliver Hartkopp wrote:
>>>> I've been playing with the PEAK CAN XL bitrate tool again and it gave me a new
>>>> idea:
>>>>
>>>> There were settings for different bitrates and the belonging/resulting flags for
>>>> TMS and ES (error-signalling).
>>>>
>>>> Staring at the options we have only three options for the CAN XL support aka "xl
>>>> on":
>>>>
>>>> 1. Providing CC/FD/XL bitrates => ES on, TMS off (mixed-mode)
>>>>
>>>> 2. Providing only CC/XL bitrates => ES off, TMS off (CANXL-only)
>>>>
>>>> 3. Providing only CC/XL bitrates => ES off, TMS on (CANXL-only)
>>>
>>> Why isn't
>>>
>>>     4. Providing only CC/XL bitrates => ES on, TMS off
>>>
>>> a valid option?
>>
>> I had an off-list discussion with Stéphane and other PEAK System experts in June
>> and the outcome was that CC/XL bitrates with ES on and TMS off is possible (only
>> with the PEAK CAN XL IP core!) but will result in a nightmare for support teams.
> 
> I will start by challenging this assertion.
> 
> Looking at the X_CAN datasheet, I see:
> 
>    1.4.5.22.2 Classical CAN
> 
>    All Classical CAN TX messages are either accepted or rejected, see
>    TX_FILTER_CTRL0.CC_CAN bit register. There is no other option for such
>    Classical CAN protocol. The TX filter elements are only used
>    for the CAN XL protocol.
> 
>    1.4.5.22.3 CAN FD
> 
>    All CAN FD messages are either accepted or rejected, see
>    TX_FILTER_CTRL0.CAN_FD bit register. There is no other option for the CAN FD
>    protocol. The TX filter elements are only used for the CAN XL
>    protocol.
> 
> Did you try those?
> 

For what reason? This is a detail of how Bosch creates there filtering 
but has nothing to do with what makes sense on the bus.

>> The CAN bus will crash if it receives a CAN FD frame.
> 
> I do not understand what you want to prove here. Isn't this the expected behaviour?
> If you are in XL with error signaling off and receive a CAN FD frame, does it
> crash the bus?

The point is: If you have no valid FD bitrate setting and the controller 
receives a FD frame with BRS=on how can this work? It does not work. Simply.

> If you are in XL with TMS on and receive a CAN FD frame, does it crash the bus?

See the table from Stéphane.

> The same goes with Stéphane's observation. Where is the problem? Which
> observation does not meet the expectations?
> 
>> This is basically the same with the Bosch X_CAN IP core where you need to enable
>> CAN FD for performing the mixed-mode. What would you set as a FD bitrate there?
>> There is no "nothing" to be set into the registers. You might set 2MBit/s as
>> default but that might crash either when it doesn't fit.
> 
> Once you set the TX_FILTER_CTRL0.CAN_FD bit, all the CAN FD frames will be
> discarded and the FD bitrate will never be used. What should you put in the
> register? That is not my problem. If the X_CAN is well designed, it should be OK
> to leave those to zero. If you still need to put some dummy values, complain to
> the X_CAN team, not to me.
> 
>> Looking back in our older discussions with Stéphane I found this:
>>
>> https://lore.kernel.org/linux-can/
>> DBAPR10MB41879125DC7369359E4AB256D467A@DBAPR10MB4187.EURPRD10.PROD.OUTLOOK.COM/#t
>>
>> Stéphane wrote:
>>
>> ---
>>
>> According to [3] lines 170-184, the CAN_CTRLMODE_FD and CAN_CTRLMODE_XL flags
>> are not mutually exclusive, so why introduce CAN_CTRLMODE_XL_ERR_SIGNAL [2] when
>> the combinations of CAN_CTRLMODE_FD and CAN_CTRLMODE_XL would allow us to deduce
>> this?
>>
>> Indeed:
>>
>> can_priv->ctrlmode & (CAN_CTRLMODE_FD|CAN_CTRLMODE_XL) ==
>>
>> CAN_CTRLMODE_FD                    CANFD mode (n/a)
>> CAN_CTRLMODE_XL|CAN_CTRLMODE_FD    mixed-CANXL => error_signaling=ON
>> CAN_CTRLMODE_XL                    pure-CANXL => error_signaling=OFF
>>
>> ---
>>
>> With the CAN_CTRLMODE_XL (pure-CANXL) the ES is always off and the TMS becomes
>> an option to be switched on (default off).
>>
>> And the more I think about it, the more I would like to go for this solution.
>>
>> This setup covers all Bosch use-case slides and Bosch CAN XL IP core
>> documentations (e.g. with the 1.5.5.3 Operating Mode table).
> 
> You are referring to those slides, right?
> 
> https://www.bosch-semiconductors.com/media/ip_modules/pdf_2/can_xl_1/20230717_can_xl_overview.pdf
> 
> I see in slide 16:
> 
>    Error Signaling: Software Configurable: ON/OFF

Yes. Of course! As CAN XL can be used in mixed-mode together with CAN FD 
and in CANXL-only mode. And for those two cases you need to set that bit 
in the controller accordingly.

But you are mixing different thing here:

1. The API to configure CAN FD and CAN XL in Linux
2. The API of the CAN XL controller

Item 1 is on a different level.

> If you are just referring to the example use cases of slide 24, then no. You
> should not be tunnel-visioned on a single slide when some other slide clearly
> states differently.

It does not. And please do not name me tunnel-visioned.
You have no such system on your desk to work with and you are 
over-engineering the CANXL-support with useless options trying to 
interpret the ISO specification.

Also the fact that the restricted mode is required for the CAN XL 
controller. The Linux kernel is not an ISO 11898 compliance checking tool.

> And in which world does an *example* use case in a slide deck take precedence on
> the ISO standard? I am sorry, but taking a random slide to disprove what the
> standard requires is not a receivable argument.
> 
>> And we can omit the introduction of the CAN_CTRLMODE_XL_ERR_SIGNAL flag as this
>> can be retrieved internally from CTRLMODE_XL and CAN_CTRLMODE_FD to be set into
>> the controller registers.
>>
>> Not defining the FD bitrate in the mixed-mode causes more harm (to the system
>> and the CAN bus itself) than urging the user to define it. Even if he doesn't
>> use CAN FD frames.
> 
> I also want to challenge this. You are claiming that the error signaling should
> be an implicit value. What if someone requires error signaling because of some
> safety requirements?
> 
> Here you are just silently turning off a safety feature. How is the end user
> meant to see the connection between disabling CAN FD and error signaling? By
> dropping the flag, we also loss the reporting. No more way to see in the netlink
> interface if error signaling is on or off.

You have no idea what you are talking about when you reference a safety 
feature here. There is a mixed mode with error-signalling and we have a 
CANXL-only mode which used an improved error recognition.

https://can-cia.org/fileadmin/cia/documents/proceedings/2020_mutter.pdf

And this has nothing to do with safety.

> The more I think about it, the more I am getting convinced that silently turning
> off a safety feature and hiding its value is nothing but a bad decision.

No.

>> In the (really unlikely) case that someone shows up with a valid use-case (like
>> len8_dlc) and separately wants to fiddle with the ES flags, we might introduce
>> such a flag later. But I bet this will not happen.
> The reality is that the people on the linux-can are a small community and the
> security/safety researcher is another small community. And the intersection of
> those two communities is rather small.
> 
> Before joining the linux-can mailing list, I was well aware of the lack of the
> len8_dlc and the TDC, and so were the people around me. But no one reported the
> problem, mostly because none of us were familiar with open source communities
> and we were all using some alternatives (proprietary drivers…)
> 
> Once I showed up and implemented those features, we saw people using those.

Great. Then lets wait if people need more than the implicit 
error-signalling.

> My point here is that taking the request on the linux-can mailing list is not a
> good benchmark to measure if people use a feature or not. At least, this is what
> occurred for the len8_dlc and the TDC and I see no reason for this to be
> different here.
> 
> (...)
> 
>> Either CAN CC or CAN FD with ES=off are marked as an "invalid configuration" in
>> the 1.5.5.3 Operating Mode table. And I'm pretty sure the CAN XL inventor's
>> implementation of the CAN XL IP core is compliant with the standard here. Maybe
>> the standard is unclear in this topic or left some details.
> 
> 1.5.5.3 also shows that FDOE is on whenever XLOE is on (even if error signaling
> is off or if TMS is on). Does it mean that you can always send FD frames? No.

Maybe the Bosch controller goes into an error, when the FDF bit is 
active on the bus without having FD enabled. You have to keep the 
bitstream in mind that has an FDF bit before getting to the XLF bit.

> That table can just not be used in isolation.
> 
> What is not clear here is the 1.5.5.3 Operating Mode table, not the standard.
> 

No, but it clearly shows invalid configurations. Maybe you can focus on 
those.

>> What is your interpretation of the standard here?
> 
> It is not an interpretation. The standard clearly require that error signaling
> should be configurable.
> 
>> What do you think has to be supported beyond the features that Stéphane and I
>> suggest?
> 
> FD off + XL on + error signaling on.

This is mixed-mode. Mixed-mode is FD/XL controllers sharing the same 
segment and can talk CC/FD (FD-controllers) and CC/FD/XL (XL-controllers).

Removing the FD bitrate in this setup leads to problems, when BRS is 
used by anyone.

>>> I see this a bit like the can_frame->len8_dlc thing. Should you use DLCs greater
>>> than 8 in production code? Hell no! But I still want the implementation to give
>>> me this option so that I can do my weird tests.
>>
>> Ack. But so far I do not see such weird options. And introducing code into the
>> kernel there is no user for and that's potentially only adding complexity in the
>> API that might lead to misconfiguration is not well-received.
> 
> It seems to me that Stéphane is able to use it and that you should also be able
> to by using TX_FILTER_CTRL0.CAN_FD. And I could also test it with my dummy-can
> driver. That should be enough testing, right?
> 
> 
> I made my mind here. It seems to me that you are tunneled-visioned on table
> 1.5.5.3 when the other sections of your datasheet clearly point out that you can
> deactivate CAN FD using TX_FILTER_CTRL0.CAN_FD. If you just partially read your
> datasheet to then jump to some conclusion, I would not feel confident to follow
> this.
> 
> The process to publish an ISO standard is strict with many domain expert
> involved. I do not think that any of us here is smarter that the combined
> mindset of the ISO 11898 committee. I would need a stronger argument to convince
> me that the ISO committee did a wrong design choice into making this error
> signaling configurable.

I'm also working in ISO committees. And some things sometimes are left 
undocumented as those domain experts simply could not imagine why 
someone would discuss not configuring the FD bitrate in the mixed-mode, 
like you do it here. You are exaggerating the discussion.

And again: Error-signalling is configurable in the CAN controller. Not 
to play with weird options but to differentiate between mixed-mode and 
CANXL-only mode.

And the different invalid configurations on the X_CAN mode register 
show, what works together and what does not work.

I'm really wondering if I am tunneled-visioned or if you are hunting a 
white rabbit.

Best regards,
Oliver

Re: RFC remove CAN_CTRLMODE_XL_ERR_SIGNAL

[Vincent Mailhol]

Hi Oliver,

On 15/11/2025 at 14:52, Oliver Hartkopp wrote:

(...)

>>>> Why isn't
>>>>
>>>>     4. Providing only CC/XL bitrates => ES on, TMS off
>>>>
>>>> a valid option?
>>>
>>> I had an off-list discussion with Stéphane and other PEAK System experts in June
>>> and the outcome was that CC/XL bitrates with ES on and TMS off is possible (only
>>> with the PEAK CAN XL IP core!) but will result in a nightmare for support teams.
>>
>> I will start by challenging this assertion.
>>
>> Looking at the X_CAN datasheet, I see:
>>
>>    1.4.5.22.2 Classical CAN
>>
>>    All Classical CAN TX messages are either accepted or rejected, see
>>    TX_FILTER_CTRL0.CC_CAN bit register. There is no other option for such
>>    Classical CAN protocol. The TX filter elements are only used
>>    for the CAN XL protocol.
>>
>>    1.4.5.22.3 CAN FD
>>
>>    All CAN FD messages are either accepted or rejected, see
>>    TX_FILTER_CTRL0.CAN_FD bit register. There is no other option for the CAN FD
>>    protocol. The TX filter elements are only used for the CAN XL
>>    protocol.
>>
>> Did you try those?
>>
> 
> For what reason? This is a detail of how Bosch creates there filtering but has
> nothing to do with what makes sense on the bus.

The reason is that we are discussing how to deactivate CAN FD on your device
when it is in mixed mode and it appears that your device has a CAN XL specific
feature to filter out CAN FD frames.

Why does your device have a CAN FD filter which can be used only under CAN XL
then? If it is not to disable CAN FD under mixed mode, what is it for?

(...)

>>> This setup covers all Bosch use-case slides and Bosch CAN XL IP core
>>> documentations (e.g. with the 1.5.5.3 Operating Mode table).
>>
>> You are referring to those slides, right?
>>
>> https://www.bosch-semiconductors.com/media/ip_modules/pdf_2/
>> can_xl_1/20230717_can_xl_overview.pdf
>>
>> I see in slide 16:
>>
>>    Error Signaling: Software Configurable: ON/OFF
> 
> Yes. Of course! As CAN XL can be used in mixed-mode together with CAN FD and in
> CANXL-only mode. And for those two cases you need to set that bit in the
> controller accordingly.
> 
> But you are mixing different thing here:
> 
> 1. The API to configure CAN FD and CAN XL in Linux
> 2. The API of the CAN XL controller
> 
> Item 1 is on a different level.
No, 1. and 2. are on the same layer. It is just that 1. is an abstraction of 2.
Also TMS and error signaling are at the same layer so if error signaling is only
at 2., where does TMS configuration go?

>> If you are just referring to the example use cases of slide 24, then no. You
>> should not be tunnel-visioned on a single slide when some other slide clearly
>> states differently.
> 
> It does not. And please do not name me tunnel-visioned.
> You have no such system on your desk to work with and you are over-engineering
> the CANXL-support with useless options trying to interpret the ISO specification.
> 
> Also the fact that the restricted mode is required for the CAN XL controller.
> The Linux kernel is not an ISO 11898 compliance checking tool.
> 
>> And in which world does an *example* use case in a slide deck take precedence on
>> the ISO standard? I am sorry, but taking a random slide to disprove what the
>> standard requires is not a receivable argument.
>>
>>> And we can omit the introduction of the CAN_CTRLMODE_XL_ERR_SIGNAL flag as this
>>> can be retrieved internally from CTRLMODE_XL and CAN_CTRLMODE_FD to be set into
>>> the controller registers.
>>>
>>> Not defining the FD bitrate in the mixed-mode causes more harm (to the system
>>> and the CAN bus itself) than urging the user to define it. Even if he doesn't
>>> use CAN FD frames.
>>
>> I also want to challenge this. You are claiming that the error signaling should
>> be an implicit value. What if someone requires error signaling because of some
>> safety requirements?
>>
>> Here you are just silently turning off a safety feature. How is the end user
>> meant to see the connection between disabling CAN FD and error signaling? By
>> dropping the flag, we also loss the reporting. No more way to see in the netlink
>> interface if error signaling is on or off.
> 
> You have no idea what you are talking about when you reference a safety feature
> here. There is a mixed mode with error-signalling and we have a CANXL-only mode
> which used an improved error recognition.
> 
> https://can-cia.org/fileadmin/cia/documents/proceedings/2020_mutter.pdf

You are saying that the CANXL *only* mode uses an improved error recognition?
Can you quote the relevant text in the paper?

The new error detection features are introduced at the CAN XL frame level,
namely: Header CRC, Frame CRC and fixed stuff bits. You do not have to disable
error signaling nor to be in "XL-only mode" to enable the new CAN XL safety
features. The only requirement is to send a CAN XL frame.

To me, the relevant paragraph is:

  §2.1 Bit Monitoring

  (...)

  A detailed explanation of the bit monitoring in CAN FD can be found in [10].
  If error signaling (via Error Frames) is enabled in CAN XL, bit monitoring is
  nearly equal to that in CAN FD. For the case that error signaling is disabled,
  bit monitoring is not yet fully specified in the current CiA610-1 draft.

I do not have access to CiA610-1, but my understanding here is that once error
signaling is disabled, you lose that bit monitoring (as defined in §2.1). And
so, the user is given the option to enable the error signaling on top of the
other CAN XL new error detection features.

It is not a

  error signaling
  vs.
  Header CRC + Frame CRC + fixed stuff bits

but rather:

  error signaling + Header CRC + Frame CRC + fixed stuff bits
  vs.
  Header CRC + Frame CRC + fixed stuff bits

Which brings us to my point: the CAN XL mode with error signaling has one
additional safety feature when compared to without error signaling. I never said
that CAN XL without error signaling is unsafe. I mean that it is less safe when
error signaling is turned off than it is when turned on.

And silently turning off *a* safety feature is bad (note the singular here and
in my previous message: I never claimed that turning off error signaling will
turn off all the other features).

> And this has nothing to do with safety.

In my research, I was looking at the AUTOSAR specification for CAN XL driver:

https://www.autosar.org/fileadmin/standards/R22-11/CP/AUTOSAR_SWS_CANXLDriver.pdf

In §7.2.3 "BusOff Handling without error signaling", they have a requirement to
emulate a error counter when error signaling is off.

  [CP_SWS_CanXL_00005] If error signaling is disabled, a basic CAN busoff
  handling with TEC (Transmission Error Counter) and REC (Reception
  Error Counter) shall be emulated in software.

If this is not related to safety, why is AUTOSAR requiring some software
workaround to compensate when error signaling is off?

>> The more I think about it, the more I am getting convinced that silently turning
>> off a safety feature and hiding its value is nothing but a bad decision.
> 
> No.
> 

(...)

>> What is not clear here is the 1.5.5.3 Operating Mode table, not the standard.
>>
> 
> No, but it clearly shows invalid configurations. Maybe you can focus on those.

Then explain me why:

  FDOE = 0, XLOE = 1, XLTR = 1, EFDI = 1

is invalid and why you must do:

  FDOE = 1, XLOE = 1, XLTR = 1, EFDI = 1

instead. We know that FD must be turned off when TMS is on, yet FDOE must be set
to 1.


The reality is that in your datasheet, FDOE = 1 does not mean that FD is on.

So:

  FDOE = 0, XLOE = 1, XLTR = 0, EFDI = 0

is invalid the same way

  FDOE = 0, XLOE = 1, XLTR = 1, EFDI = 1

is invalid.

>>> What is your interpretation of the standard here?
>>
>> It is not an interpretation. The standard clearly require that error signaling
>> should be configurable.
>>
>>> What do you think has to be supported beyond the features that Stéphane and I
>>> suggest?
>>
>> FD off + XL on + error signaling on.
> 
> This is mixed-mode. Mixed-mode is FD/XL controllers sharing the same segment and
> can talk CC/FD (FD-controllers) and CC/FD/XL (XL-controllers).
> 
> Removing the FD bitrate in this setup leads to problems, when BRS is used by
> anyone.

And one more time, why do you want to send FD frames when FD is off? It is
*normal* to get errors when receiving FD frames while FD is turned off. If FD is
off, there should be no FD nodes on the bus, period. Everything else is bogus.

This is really what I can not understand in your reasoning.


Yours sincerely,
Vincent Mailhol

Re: RFC remove CAN_CTRLMODE_XL_ERR_SIGNAL

[Oliver Hartkopp]

Hi Vincent,

On 16.11.25 22:34, Vincent Mailhol wrote:

>>> Did you try those?
>>>
>>
>> For what reason? This is a detail of how Bosch creates their filtering but has
>> nothing to do with what makes sense on the bus.
> 
> The reason is that we are discussing how to deactivate CAN FD on your device
> when it is in mixed mode and it appears that your device has a CAN XL specific
> feature to filter out CAN FD frames.
> 
> Why does your device have a CAN FD filter which can be used only under CAN XL
> then? If it is not to disable CAN FD under mixed mode, what is it for?

You are mixing layers what can be sent on the bus and what the 
applications needs can filter for. If you don't want to 'see' FD 
traffic, you can set such a filter like blinding sunglasses. See details 
below.

>>>> This setup covers all Bosch use-case slides and Bosch CAN XL IP core
>>>> documentations (e.g. with the 1.5.5.3 Operating Mode table).
>>>
>>> You are referring to those slides, right?
>>>
>>> https://www.bosch-semiconductors.com/media/ip_modules/pdf_2/
>>> can_xl_1/20230717_can_xl_overview.pdf
>>>
>>> I see in slide 16:
>>>
>>>     Error Signaling: Software Configurable: ON/OFF
>>
>> Yes. Of course! As CAN XL can be used in mixed-mode together with CAN FD and in
>> CANXL-only mode. And for those two cases you need to set that bit in the
>> controller accordingly.
>>
>> But you are mixing different thing here:
>>
>> 1. The API to configure CAN FD and CAN XL in Linux
>> 2. The API of the CAN XL controller
>>
>> Item 1 is on a different level.
> No, 1. and 2. are on the same layer. It is just that 1. is an abstraction of 2.

No. And this is the problem in our discussion, why you think you must 
modify the err-signal configuration bit from the user-space.

The netlink API is not transparent. It is designed to configure various 
CAN controllers with multiple features. And it is an abstraction, 
because different CAN controller specifications use different wordings, 
have different restrictions, initialization sequences and features.

The task is to design an interface, that is not CAN controller specific 
but supports the CAN standards requirements and communication modes.

So when a Bosch IP core provides CAN standard features that are also 
provided by a PEAK IP core and both are officially ISO 11898-1:2024 
certified, then this is the intersection of features we need to provide 
and control.

The tests performed through the certification process are the real 
benchmark for our netlink API.

> Also TMS and error signaling are at the same layer so if error signaling is only
> at 2., where does TMS configuration go?

With the error-signalling bit you permanently insist on the direct 
manipulation of the bit in the CAN controller (from user-space). But if 
there would be a direct manipulation of Bosch's FDOE bit with our 
CAN_CTRLMODE_FD flag the CAN XL-only mode (and TMS) would never work.

That's the proof that there *is* an abstraction and the netlink API is 
definitely different to the Bosch controller API. Therefore the items 1. 
and 2. are *not* on the same layer.

Agreed?

So let's see what the intersection of ISO 11898-1:2024, the Bosch X_CAN 
IP core and the PEAK CANXL IP core looks like. Then this is what we need 
to support. Happily I have both of them on my table.

The required CAN protocol modes are built as follows:

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)

The XL-only mode is the only mode which has ES=0. In this mode no CC/FD 
frames can be sent or received. Ignoring this restriction leads to an 
"invalid frame format evt" in the Bosch X_CAN controller.

If you want to use the CAN XL protocol with error-signalling you need to 
select the XL/FD/CC mixed-mode. This 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.

As the intention of this mode is a hybrid FD/XL network, the CAN FD 
option is always enabled in the Bosch X_CAN and the bitrate 
configuration register for FD is used and therefore has to be valid.

If you don't want to 'see' specific CAN protocols you might filter them 
away. But on the CAN bus all three XL/FD/CC protocol frames are allowed. 
You might misconfigure the FD bitrate if you enjoy it.

The above "required CAN protocol modes" table is the intersection of ISO 
11898-1:2024, the Bosch X_CAN IP core and the PEAK CANXL IP, what we 
need to support with the netlink API:

We only need

- CAN_CTRLMODE_FD
- CAN_CTRLMODE_XL
- CAN_CTRLMODE_XL_TMS
- CAN_CTRLMODE_RESTRICTED

to configure/control the new CAN XL support. The error-signalling bit in 
the CAN controller API level can be derived from the XL-only mode.

Back to your last question:

> And one more time, why do you want to send FD frames when FD is off? It is
> *normal* to get errors when receiving FD frames while FD is turned off. If FD is
> off, there should be no FD nodes on the bus, period. Everything else is bogus.
> 
> This is really what I can not understand in your reasoning.
The answer is: There is no "FD is off" in the XL/FD/CC mixed-mode. And 
if you want CAN XL with error-signalling you have to take FD as a bundle.

Best regards,
Oliver