drivers/net/can/dev/bittiming.c | 63 +++++++ drivers/net/can/dev/calc_bittiming.c | 36 ++++ drivers/net/can/dev/dev.c | 20 +- drivers/net/can/dev/netlink.c | 357 +++++++++++++++++++++++++++++++++-- include/linux/can/bittiming.h | 76 +++++++- include/linux/can/dev.h | 49 +++-- include/uapi/linux/can/netlink.h | 35 ++++ 7 files changed, 595 insertions(+), 41 deletions(-)
Following all the refactoring on the CAN netlink done in series [1],
[2] and [3], this is now time to finally introduce the CAN XL netlink
interface.
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.
Patch #1 adds a check in can_dev_dropped_skb() to drop CAN FD frames
when CAN FD is turned off.
Patch #2 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 #3 adds all the CAN XL features which are inherited from CAN FD:
the nominal bittiming, the data bittiming and the TDC.
Patch #4 and #5 add two new CAN control modes which are specific to
CAN XL: CAN_CTRLMODE_XL_TMS, CAN_CTRLMODE_XL_ERR_SIGNAL respectively.
Finally, patch #6 to #9 add the PWM logic.
[1] can: netlink: preparation before introduction of CAN XL
Link: https://lore.kernel.org/linux-can/20241112165118.586613-7-mailhol.vincent@wanadoo.fr/
[2] can: rework the CAN MTU logic (CAN XL preparation step 2/3)
Link: https://lore.kernel.org/linux-can/20250923-can-fix-mtu-v3-0-581bde113f52@kernel.org/
[3] can: netlink: preparation before introduction of CAN XL step 3/3
Link: https://lore.kernel.org/linux-can/20250923-canxl-netlink-prep-v4-0-e720d28f66fe@kernel.org/
---
Changes in v1:
- Add PWM
- Add the CAN_CTRLMODE_RESTRICTED, CAN_CTRLMODE_XL_TMS and
CAN_CTRLMODE_XL_ERR_SIGNAL control modes.
- A lot has changed since the original RFC was sent in November
last year. The preparation patches went in a separate series as
explained in the cover letter, and what used to be a single patch
to introduce CAN XL is now a full series. A few additional
details are added to the individual patches, but overall I did
not keep track of all the changes over the last year. You may as
well consider this as a new series.
Link to RFC: https://lore.kernel.org/linux-can/20241110155902.72807-16-mailhol.vincent@wanadoo.fr/
---
Vincent Mailhol (9):
can: dev: can_dev_dropped_skb: drop CAN FD skbs if FD is off
can: netlink: add CAN_CTRLMODE_RESTRICTED
can: netlink: add initial CAN XL support
can: netlink: add CAN_CTRLMODE_XL_TMS flag
can: netlink: add CAN_CTRLMODE_XL_ERR_SIGNAL
can: bittiming: add PWM parameters
can: bittiming: add PWM validation
can: calc_bittiming: add PWM calculation
can: netlink: add PWM netlink interface
drivers/net/can/dev/bittiming.c | 63 +++++++
drivers/net/can/dev/calc_bittiming.c | 36 ++++
drivers/net/can/dev/dev.c | 20 +-
drivers/net/can/dev/netlink.c | 357 +++++++++++++++++++++++++++++++++--
include/linux/can/bittiming.h | 76 +++++++-
include/linux/can/dev.h | 49 +++--
include/uapi/linux/can/netlink.h | 35 ++++
7 files changed, 595 insertions(+), 41 deletions(-)
---
base-commit: cb6649f6217c0331b885cf787f1d175963e2a1d2
change-id: 20241229-canxl-netlink-bc640af10673
Best regards,
--
Vincent Mailhol <mailhol@kernel.org>
On 13.10.2025 20:01:22, Vincent Mailhol wrote: > Following all the refactoring on the CAN netlink done in series [1], > [2] and [3], this is now time to finally introduce the CAN XL netlink > interface. > > 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. > > Patch #1 adds a check in can_dev_dropped_skb() to drop CAN FD frames > when CAN FD is turned off. > > Patch #2 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. What about merging patches 1+2 now? regards, Marc -- Pengutronix e.K. | Marc Kleine-Budde | Embedded Linux | https://www.pengutronix.de | Vertretung Nürnberg | Phone: +49-5121-206917-129 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |
On 17/10/2025 at 22:53, Marc Kleine-Budde wrote: > On 13.10.2025 20:01:22, Vincent Mailhol wrote: >> Following all the refactoring on the CAN netlink done in series [1], >> [2] and [3], this is now time to finally introduce the CAN XL netlink >> interface. >> >> 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. >> >> Patch #1 adds a check in can_dev_dropped_skb() to drop CAN FD frames >> when CAN FD is turned off. >> >> Patch #2 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. > > What about merging patches 1+2 now? If patch 1 had to be squashed, it should probably be in patch 3 "can: netlink: add initial CAN XL support". The MTU workaround as introduced in patch 1 does not share any of the logic of the CAN_CTRLMODE_RESTRICTED as introduced in patch 2. Patch 1 is really just a preparation for CAN XL. You could remove patch 2 from the series and it will still work (aside from missing one of ISO mandatory features). Remove patch 1, and the thing breaks apart because it is required by patch 3. If I were to squash 1 and 2, I am not sure how I would describe those two different changes in a single patch message. Yours sincerely, Vincent Mailhol
On 18.10.2025 00:40:22, Vincent Mailhol wrote: > On 17/10/2025 at 22:53, Marc Kleine-Budde wrote: > > On 13.10.2025 20:01:22, Vincent Mailhol wrote: > >> Following all the refactoring on the CAN netlink done in series [1], > >> [2] and [3], this is now time to finally introduce the CAN XL netlink > >> interface. > >> > >> 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. > >> > >> Patch #1 adds a check in can_dev_dropped_skb() to drop CAN FD frames > >> when CAN FD is turned off. > >> > >> Patch #2 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. > > > > What about merging patches 1+2 now? > > If patch 1 had to be squashed, Sorry - I was offering you to take patches 1+2 into can-next-testing now. > it should probably be in patch 3 > "can: netlink: add initial CAN XL support". The MTU workaround as > introduced in patch 1 does not share any of the logic of the > CAN_CTRLMODE_RESTRICTED as introduced in patch 2. Patch 1 is really > just a preparation for CAN XL. You could remove patch 2 from the > series and it will still work (aside from missing one of ISO mandatory > features). Remove patch 1, and the thing breaks apart because it is > required by patch 3. > > If I were to squash 1 and 2, I am not sure how I would describe those > two different changes in a single patch message. regards, Marc -- Pengutronix e.K. | Marc Kleine-Budde | Embedded Linux | https://www.pengutronix.de | Vertretung Nürnberg | Phone: +49-5121-206917-129 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |
On 18/10/2025 at 01:02, Marc Kleine-Budde wrote: > On 18.10.2025 00:40:22, Vincent Mailhol wrote: >> On 17/10/2025 at 22:53, Marc Kleine-Budde wrote: >>> On 13.10.2025 20:01:22, Vincent Mailhol wrote: >>>> Following all the refactoring on the CAN netlink done in series [1], >>>> [2] and [3], this is now time to finally introduce the CAN XL netlink >>>> interface. >>>> >>>> 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. >>>> >>>> Patch #1 adds a check in can_dev_dropped_skb() to drop CAN FD frames >>>> when CAN FD is turned off. >>>> >>>> Patch #2 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. >>> >>> What about merging patches 1+2 now? >> >> If patch 1 had to be squashed, > > Sorry - I was offering you to take patches 1+2 into can-next-testing > now. Ah! This makes more sense. Sorry for misreading you. Yes, you can pick those two. But could you just push your can-next-testing branch to git.kernel.org after picking those? This way, I can rebase my series on top of it instead of dealing with some complex dependencies. Yours sincerely, Vincent Mailhol
On 18.10.2025 01:20:31, Vincent Mailhol wrote: > >>> What about merging patches 1+2 now? > >> > >> If patch 1 had to be squashed, > > > > Sorry - I was offering you to take patches 1+2 into can-next-testing > > now. > > Ah! This makes more sense. Sorry for misreading you. > > Yes, you can pick those two. But could you just push your > can-next-testing branch to git.kernel.org after picking those? This > way, I can rebase my series on top of it instead of dealing with some > complex dependencies. Right, taking only part of the series makes things more complicated. Better keep them for now. regards, Marc -- Pengutronix e.K. | Marc Kleine-Budde | Embedded Linux | https://www.pengutronix.de | Vertretung Nürnberg | Phone: +49-5121-206917-129 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |
On 13/10/2025 at 20:01, Vincent Mailhol wrote: > Following all the refactoring on the CAN netlink done in series [1], > [2] and [3], this is now time to finally introduce the CAN XL netlink > interface. I am sending this extra message to give a few additional hints on how to test. In addition to the mailing list, I also push this series and the dummy_can driver to: https://git.kernel.org/pub/scm/linux/kernel/git/mailhol/linux.git/log/?h=b4/canxl-netlink I also have a work in progress for iproute2 here: https://git.kernel.org/pub/scm/linux/kernel/git/mailhol/iproute2-next.git/log/?h=canxl-netlink I will submit the iproute2 series later on, after receiving comments on this series. For the moment, the iproute2 canxl is only available through the link above. To test, after cloning and compiling above branches, do: modprobe dummy-can to load the driver. Then configure it, for example, this is a 500 KB/s nominal bittiming and a 10 MB/s XL databittiming with TMS on: ./ip/ip link set can0 up type can bitrate 500000 xl on xbitrate 10000000 tms on If you have debug log enabled (e.g. with CONFIG_CAN_DEBUG_DEVICES), this is what you should see in the kernel log: can0: Clock frequency: 160000000 can0: Maximum bitrate: 20000000 can0: MTU: 2060 can0: can0: Control modes: can0: supported: 0x0001ba22 can0: enabled: 0x00009000 can0: list: can0: listen-only: off can0: fd: off can0: fd-tdc-auto: off can0: restricted-operation: off can0: xl: on can0: xl-tdc-auto: off can0: xl-tms: on can0: xl-error-signalling: off can0: can0: Classical CAN nominal bittiming: can0: bitrate: 500000 can0: sample_point: 875 can0: tq: 12 can0: prop_seg: 69 can0: phase_seg1: 70 can0: phase_seg2: 20 can0: sjw: 10 can0: brp: 2 can0: can0: can0: CAN XL databittiming: can0: bitrate: 10000000 can0: sample_point: 750 can0: tq: 6 can0: prop_seg: 5 can0: phase_seg1: 6 can0: phase_seg2: 4 can0: sjw: 2 can0: brp: 1 can0: CAN XL PWM: can0: pwms: 4 can0: pwml: 12 can0: pwmo: 0 can0: can0: dummy-can is up Finally, you can use a recent version of can-utils to generate some traffic. The driver will echo back anything it receives. I will continue to update the above branches according to the comments received. See these as work in progress. Use the series as posted on the mailing if you want something more stable. Yours sincerely, Vincent Mailhol
© 2016 - 2026 Red Hat, Inc.