[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

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

[Oliver Hartkopp]

Hi Vincent,

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

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

We are already in 6.17-rc2 and I would definitely like to have the CAN 
XL driver support finalized in this net-next merge window phase.

What is your plan? Do you have an updated patch set to be posted for the 
discussion?

Best regards,
Oliver

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

[Vincent Mailhol]

Hi Oliver,

On 18/08/2025 at 21:35, Oliver Hartkopp wrote:
> Hi Vincent,
> 
> On 30.07.25 16:15, Vincent Mailhol wrote:
>> On Tue. 29 Jul. 2025 at 03:20, Oliver Hartkopp <socketcan@hartkopp.net> wrote:
> 
>>> 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.
>>
> 
> We are already in 6.17-rc2 and I would definitely like to have the CAN XL driver
> support finalized in this net-next merge window phase.
> 
> What is your plan? Do you have an updated patch set to be posted for the
> discussion?

I uploaded my current WIP here:

https://git.kernel.org/pub/scm/linux/kernel/git/mailhol/linux.git/log/?h=b4/canxl-netlink

As you will be able to see, most of the features are here. Now, I am trying to
think of all the edge cases and make sure that any incorrect configuration is
correctly rejected.

I am just sharing this to reassure everyone on the progress. The patches are not
yet ready for discussion. You can have a look if you want, but no need to do a
review as I am still making changes.


Yours sincerely,
Vincent Mailhol

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

[Oliver Hartkopp]

Hi Vincent,

On 21.08.25 17:47, Vincent Mailhol wrote:
> Hi Oliver,
> 
> On 18/08/2025 at 21:35, Oliver Hartkopp wrote:
>> Hi Vincent,
>>
>> On 30.07.25 16:15, Vincent Mailhol wrote:
>>> On Tue. 29 Jul. 2025 at 03:20, Oliver Hartkopp <socketcan@hartkopp.net> wrote:
>>
>>>> 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.
>>>
>>
>> We are already in 6.17-rc2 and I would definitely like to have the CAN XL driver
>> support finalized in this net-next merge window phase.
>>
>> What is your plan? Do you have an updated patch set to be posted for the
>> discussion?
> 
> I uploaded my current WIP here:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/mailhol/linux.git/log/?h=b4/canxl-netlink
> 
> As you will be able to see, most of the features are here. Now, I am trying to
> think of all the edge cases and make sure that any incorrect configuration is
> correctly rejected.
> 
> I am just sharing this to reassure everyone on the progress. The patches are not
> yet ready for discussion. You can have a look if you want, but no need to do a
> review as I am still making changes.

I upgraded my hardware test setup to 6.17-rc3 with the patches from your 
b4/canxl-netlink branch.

Most things were easy to adapt but the netlink PWM API.

Two questions:
1. Why did you make the PWM values u32 as the 6 bit will always fit into 
a u8 value?

2. Can you share some PWM code for the iproute2 package or do I need to 
adapt this code myself?

https://github.com/hartkopp/canxl-nl/blob/main/iproute2/0005-iplink_can-canxl-add-PWM-config-support.patch

Best regards,
Oliver

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

[Oliver Hartkopp]

On 24.08.25 22:24, Oliver Hartkopp wrote:

> On 21.08.25 17:47, Vincent Mailhol wrote:

>> I uploaded my current WIP here:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/mailhol/linux.git/ 
>> log/?h=b4/canxl-netlink
>>
>> As you will be able to see, most of the features are here. Now, I am 
>> trying to
>> think of all the edge cases and make sure that any incorrect 
>> configuration is
>> correctly rejected.
>>
>> I am just sharing this to reassure everyone on the progress. The 
>> patches are not
>> yet ready for discussion. You can have a look if you want, but no need 
>> to do a
>> review as I am still making changes.
> 
> I upgraded my hardware test setup to 6.17-rc3 with the patches from your 
> b4/canxl-netlink branch.
> 
> Most things were easy to adapt but the netlink PWM API.
> 
> Two questions:
> 1. Why did you make the PWM values u32 as the 6 bit will always fit into 
> a u8 value?
> 
> 2. Can you share some PWM code for the iproute2 package or do I need to 
> adapt this code myself?
> 
> https://github.com/hartkopp/canxl-nl/blob/main/iproute2/0005-iplink_can- 
> canxl-add-PWM-config-support.patch
> 

Well, that was an unneeded effort as you pushed your changes just a 
short time after I adapted all my code :-/

Can you please post your changes here on the mailing list so that the 
usual development process is executed?

E.g. the CAN_CTRLMODE_RESTRIC_OP should be named to 
CAN_CTRLMODE_RESTRICTED to meet the other configuration options.

The listen-only operation mode is not named CAN_CTRLMODE_LISTENONLY_OP 
but CAN_CTRLMODE_LISTENONLY ...

Best regards,
Oliver

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

[Vincent Mailhol]

On 25/08/2025 at 16:17, Oliver Hartkopp wrote:
> On 24.08.25 22:24, Oliver Hartkopp wrote:
> 
>> On 21.08.25 17:47, Vincent Mailhol wrote:
> 
>>> I uploaded my current WIP here:
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/mailhol/linux.git/ log/?h=b4/
>>> canxl-netlink
>>>
>>> As you will be able to see, most of the features are here. Now, I am trying to
>>> think of all the edge cases and make sure that any incorrect configuration is
>>> correctly rejected.
>>>
>>> I am just sharing this to reassure everyone on the progress. The patches are not
>>> yet ready for discussion. You can have a look if you want, but no need to do a
>>> review as I am still making changes.
>>
>> I upgraded my hardware test setup to 6.17-rc3 with the patches from your b4/
>> canxl-netlink branch.
>>
>> Most things were easy to adapt but the netlink PWM API.
>>
>> Two questions:
>> 1. Why did you make the PWM values u32 as the 6 bit will always fit into a u8
>> value?

u32 is the common method for netlink interface.

Marc raised the point here:

https://lore.kernel.org/linux-can/20250528-encouraging-scallop-of-expression-2d1ebe-mkl@pengutronix.de/

and I agree with him (and anyway, my intent was to use u32 from the beginning
even before Marc sent his comment).

>> 2. Can you share some PWM code for the iproute2 package or do I need to adapt
>> this code myself?
>>
>> https://github.com/hartkopp/canxl-nl/blob/main/iproute2/0005-iplink_can-
>> canxl-add-PWM-config-support.patch

OK. I will upload the iproute2 later on. But same as the above, it will *not* be
ready for review. So, please, do not share comment for now.

> Well, that was an unneeded effort as you pushed your changes just a short time
> after I adapted all my code :-/
> 
> Can you please post your changes here on the mailing list so that the usual
> development process is executed?

Well, what can I say? Read again the message I posted right above:

  I am just sharing this to reassure everyone on the progress. The patches are
  not yet ready for discussion. You can have a look if you want, but no need to
  do a review as I am still making changes.

I thought that I was clear. This is a WIP which I am sharing because you ask for
it but there will be some changes until I am happy with the result.

I will post it using the usual development process when I am fully happy with
it. Meanwhile, it is *not* ready for review. You are welcome to play with it,
but it is *not* open for discussion at the moment.

> E.g. the CAN_CTRLMODE_RESTRIC_OP should be named to CAN_CTRLMODE_RESTRICTED to
> meet the other configuration options.
> 
> The listen-only operation mode is not named CAN_CTRLMODE_LISTENONLY_OP but
> CAN_CTRLMODE_LISTENONLY ...

I named it like that because in ISO 11898-1:2024 it is "restricted operation
mode" not the "restricted mode". But I am fine to rename.

As I tried to stress above, this not being ready for review, I will not be
answering further comments. Sorry if I am disappointing you, but at the moment,
I want to focus on the debugging by myself (and there are a few bugs I am aware
of, if you expect something production ready, please do not use).


Yours sincerely,
Vincent Mailhol

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

[Vincent Mailhol]

On 25/08/2025 at 17:32, Vincent Mailhol wrote:
> On 25/08/2025 at 16:17, Oliver Hartkopp wrote:
>> On 24.08.25 22:24, Oliver Hartkopp wrote:

(...)

>>> 2. Can you share some PWM code for the iproute2 package or do I need to adapt
>>> this code myself?
>>>
>>> https://github.com/hartkopp/canxl-nl/blob/main/iproute2/0005-iplink_can-
>>> canxl-add-PWM-config-support.patch
> 
> OK. I will upload the iproute2 later on. But same as the above, it will *not* be
> ready for review. So, please, do not share comment for now.

And here it is:

https://git.kernel.org/pub/scm/linux/kernel/git/mailhol/iproute2-next.git/log/?h=canxl-netlink

This part is far from completion, but at least you have the PWM interface. I
plan to finalize the iproute2 last once the kernel part is fully working.

One more time, this is a WIP which is *not* ready for review.


Yours sincerely,
Vincent Mailhol

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

[Oliver Hartkopp]

On 25.08.25 18:01, Vincent Mailhol wrote:
> On 25/08/2025 at 17:32, Vincent Mailhol wrote:
>> On 25/08/2025 at 16:17, Oliver Hartkopp wrote:
>>> On 24.08.25 22:24, Oliver Hartkopp wrote:
> 
> (...)
> 
>>>> 2. Can you share some PWM code for the iproute2 package or do I need to adapt
>>>> this code myself?
>>>>
>>>> https://github.com/hartkopp/canxl-nl/blob/main/iproute2/0005-iplink_can-
>>>> canxl-add-PWM-config-support.patch
>>
>> OK. I will upload the iproute2 later on. But same as the above, it will *not* be
>> ready for review. So, please, do not share comment for now.
> 
> And here it is:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/mailhol/iproute2-next.git/log/?h=canxl-netlink
> 
> This part is far from completion, but at least you have the PWM interface. I
> plan to finalize the iproute2 last once the kernel part is fully working.
> 
> One more time, this is a WIP which is *not* ready for review.

Thanks Vincent!

I gave it a try.

At least my setup can send all types of CAN CC/FD/XL frames without BRS 
and TMS. So I have something more to test.

Best regards,
Oliver