From: Vincent Mailhol <mailhol@kernel.org>
To: Oliver Hartkopp <socketcan@hartkopp.net>,
Marc Kleine-Budde <mkl@pengutronix.de>
Cc: "Stéphane Grosjean" <stephane.grosjean@hms-networks.com>,
"Robert Nawrath" <mbro1689@gmail.com>,
"Minh Le" <minh.le.aj@renesas.com>,
"Duy Nguyen" <duy.nguyen.rh@renesas.com>,
linux-can@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 06/10] can: netlink: add CAN_CTRLMODE_XL_ERR_SIGNAL
Date: Sun, 9 Nov 2025 15:54:48 +0100 [thread overview]
Message-ID: <fc5e764d-3ef8-455e-9bae-bd50ea206ce2@kernel.org> (raw)
In-Reply-To: <2c75aca3-a19a-4144-8be5-8fb7524e581e@hartkopp.net>
On 06/11/2025 at 09:50, Oliver Hartkopp wrote:
> On 21.10.25 17:47, Vincent Mailhol wrote:
>> Classical CAN and CAN FD must generate error frames on the CAN bus
>> when detecting a protocol violation.
>>
>> CAN XL's error signaling is different and works as follows:
>>
>> - In interoperability mode (both FD and XL), error signaling must be
>> on.
>>
>> - When operating a CAN controller in CAN XL only mode but with TMS
>> off, the user can decide whether the error signalling is enabled
>> or disabled.
>>
>> - On the contrary, when using TMS, error signalling must be off.
>>
>> Introduce the new CAN_CTRLMODE_XL_ERR_SIGNAL control mode. This new
>> option is only made available for CAN XL, so despite the error
>> signalling being always on for Classical CAN and CAN FD, forbid the
>> use of this flag when CAN XL is off.
>>
>> If the user provides the error signalling flag, check its validity. If
>> the flag is omitted, activate error signalling by default whenever
>> possible. This is summarized in below table:
>>
>> CAN_CTRLMODE_XL_ERR_SIGNAL
>> -------------------------------------------
>> CC/FD option not available
>> CC/FD/XL on
>
> Yes. This is the 'mixed-mode'
> I would propose to use the 'mixed-mode' expression in the patch description.
Ack!
>> XL TMS off configurable (default on)
>
> Good default.
>
>> XL TMS on off
>>
>> Suggested-by: Oliver Hartkopp <socketcan@hartkopp.net>
>> Link: https://lore.kernel.org/linux-can/20250527195625.65252-9-
>> socketcan@hartkopp.net/
>> Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
>> ---
>> drivers/net/can/dev/dev.c | 2 ++
>> drivers/net/can/dev/netlink.c | 29 +++++++++++++++++++++++++++--
>> include/uapi/linux/can/netlink.h | 1 +
>> 3 files changed, 30 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/can/dev/dev.c b/drivers/net/can/dev/dev.c
>> index 1de5babcc4f3..0c16d0174f7f 100644
>> --- a/drivers/net/can/dev/dev.c
>> +++ b/drivers/net/can/dev/dev.c
>> @@ -125,6 +125,8 @@ const char *can_get_ctrlmode_str(u32 ctrlmode)
>> return "xl-tdc-manual";
>> case CAN_CTRLMODE_XL_TMS:
>> return "xl-tms";
>> + case CAN_CTRLMODE_XL_ERR_SIGNAL:
>> + return "xl-error-signalling";
>> default:
>> return "<unknown>";
>> }
>> diff --git a/drivers/net/can/dev/netlink.c b/drivers/net/can/dev/netlink.c
>> index 8afd2baa03cf..6126b191fea0 100644
>> --- a/drivers/net/can/dev/netlink.c
>> +++ b/drivers/net/can/dev/netlink.c
>> @@ -191,7 +191,8 @@ static int can_validate_xl_flags(struct netlink_ext_ack
>> *extack,
>> }
>> if (masked_flags & CAN_CTRLMODE_XL_TMS) {
>> const u32 tms_conflicts_mask = CAN_CTRLMODE_FD |
>> - CAN_CTRLMODE_XL_TDC_MASK;
>> + CAN_CTRLMODE_XL_TDC_MASK |
>> + CAN_CTRLMODE_XL_ERR_SIGNAL;
>> u32 tms_conflicts = masked_flags & tms_conflicts_mask;
>> if (tms_conflicts) {
>> @@ -201,11 +202,23 @@ static int can_validate_xl_flags(struct netlink_ext_ack
>> *extack,
>> return -EOPNOTSUPP;
>> }
>> }
>> + if ((masked_flags & CAN_CTRLMODE_FD) &&
>> + (mask & CAN_CTRLMODE_XL_ERR_SIGNAL) &&
>> + !(masked_flags & CAN_CTRLMODE_XL_ERR_SIGNAL)) {
>> + NL_SET_ERR_MSG(extack,
>> + "When using both CAN FD and XL, error signalling must
>> be on");
I changed that error message to:
NL_SET_ERR_MSG(extack, "Mixed mode requires error signalling");
> This implicitly tells us that mixed-mode is CC/FD/XL ;-)
I was under the assumption that Classical CAN was always allowed, even under
TMS. The arbitration still uses the nominal bittiming anyway, so I still have
some issue understanding why an XL nodes operating under TMS wouldn't be able to
send a classical CAN frame.
The restriction seems rather arbitrary to me. I would be curious to understand
what the issue would be to allow Classical CAN under TMS.
> > + return -EOPNOTSUPP;
>> + }
>> } else {
>> if (mask & CAN_CTRLMODE_XL_TMS) {
>> NL_SET_ERR_MSG(extack, "TMS requires CAN XL");
>> return -EOPNOTSUPP;
>> }
>> + if (mask & CAN_CTRLMODE_XL_ERR_SIGNAL) {
>> + NL_SET_ERR_MSG(extack,
>> + "Error signalling is only configurable with CAN XL");
>> + return -EOPNOTSUPP;
>> + }
>> }
>> return 0;
>> @@ -310,6 +323,11 @@ static int can_ctrlmode_changelink(struct net_device *dev,
>> "TMS can not be activated while CAN FD is on");
>> return -EOPNOTSUPP;
>> }
>> + if (deactivated & CAN_CTRLMODE_XL_ERR_SIGNAL) {
>> + NL_SET_ERR_MSG(extack,
>> + "Error signalling can not be deactivated while CAN FD
>> is on");
>> + return -EOPNOTSUPP;
>> + }
>> }
>> /* If a top dependency flag is provided, reset all its dependencies */
>> @@ -317,12 +335,19 @@ static int can_ctrlmode_changelink(struct net_device *dev,
>> priv->ctrlmode &= ~CAN_CTRLMODE_FD_TDC_MASK;
>> if (cm->mask & CAN_CTRLMODE_XL)
>> priv->ctrlmode &= ~(CAN_CTRLMODE_XL_TDC_MASK |
>> - CAN_CTRLMODE_XL_TMS);
>> + CAN_CTRLMODE_XL_TMS |
>> + CAN_CTRLMODE_XL_ERR_SIGNAL);
>> /* clear bits to be modified and copy the flag values */
>> priv->ctrlmode &= ~cm->mask;
>> priv->ctrlmode |= maskedflags;
>> + /* If omitted, set error signalling on if possible */
>> + if ((maskedflags & CAN_CTRLMODE_XL) &&
>> + !(cm->mask & CAN_CTRLMODE_XL_ERR_SIGNAL) &&
>> + !(priv->ctrlmode & CAN_CTRLMODE_XL_TMS))
>> + priv->ctrlmode |= CAN_CTRLMODE_XL_ERR_SIGNAL;
>> +
>> /* Wipe potential leftovers from previous CAN FD/XL config */
>> if (!(priv->ctrlmode & CAN_CTRLMODE_FD)) {
>> memset(&priv->fd.data_bittiming, 0,
>> diff --git a/include/uapi/linux/can/netlink.h b/include/uapi/linux/can/netlink.h
>> index ebafb091d80f..30d446921dc4 100644
>> --- a/include/uapi/linux/can/netlink.h
>> +++ b/include/uapi/linux/can/netlink.h
>> @@ -108,6 +108,7 @@ struct can_ctrlmode {
>> #define CAN_CTRLMODE_XL_TDC_AUTO 0x2000 /* XL transceiver
>> automatically calculates TDCV */
>> #define CAN_CTRLMODE_XL_TDC_MANUAL 0x4000 /* XL TDCV is manually set
>> up by user */
>> #define CAN_CTRLMODE_XL_TMS 0x8000 /* Transceiver Mode Switching */
>> +#define CAN_CTRLMODE_XL_ERR_SIGNAL 0x10000 /* XL error signalling */
>> /*
>> * CAN device statistics
>>
> Reviewed-by: Oliver Hartkopp <socketcan@hartkopp.net>
Thanks!
Yours sincerely,
Vincent Mailhol
next prev parent reply other threads:[~2025-11-09 14:54 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-21 15:47 [PATCH v2 00/10] can: netlink: add CAN XL Vincent Mailhol
2025-10-21 15:47 ` [PATCH v2 01/10] can: bittiming: apply NL_SET_ERR_MSG() to can_calc_bittiming() Vincent Mailhol
2025-10-21 15:47 ` [PATCH v2 02/10] can: dev: can_dev_dropped_skb: drop CAN FD skbs if FD is off Vincent Mailhol
2025-10-21 15:47 ` [PATCH v2 03/10] can: netlink: add CAN_CTRLMODE_RESTRICTED Vincent Mailhol
2025-10-21 15:47 ` [PATCH v2 04/10] can: netlink: add initial CAN XL support Vincent Mailhol
2025-10-21 15:47 ` [PATCH v2 05/10] can: netlink: add CAN_CTRLMODE_XL_TMS flag Vincent Mailhol
2025-11-06 8:42 ` Oliver Hartkopp
2025-11-09 14:28 ` Vincent Mailhol
2025-11-09 17:40 ` Oliver Hartkopp
2025-10-21 15:47 ` [PATCH v2 06/10] can: netlink: add CAN_CTRLMODE_XL_ERR_SIGNAL Vincent Mailhol
2025-11-06 8:50 ` Oliver Hartkopp
2025-11-09 14:54 ` Vincent Mailhol [this message]
2025-11-09 17:46 ` Oliver Hartkopp
2025-10-21 15:47 ` [PATCH v2 07/10] can: bittiming: add PWM parameters Vincent Mailhol
2025-10-21 15:47 ` [PATCH v2 08/10] can: bittiming: add PWM validation Vincent Mailhol
2025-10-21 15:47 ` [PATCH v2 09/10] can: calc_bittiming: add PWM calculation Vincent Mailhol
2025-10-21 15:47 ` [PATCH v2 10/10] can: netlink: add PWM netlink interface Vincent Mailhol
2025-10-31 21:17 ` [PATCH v2 00/10] can: netlink: add CAN XL Oliver Hartkopp
2025-11-02 22:11 ` Vincent Mailhol
2025-11-03 19:15 ` Oliver Hartkopp
2025-11-04 7:28 ` Marc Kleine-Budde
2025-11-04 8:01 ` Oliver Hartkopp
2025-11-04 13:13 ` Marc Kleine-Budde
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fc5e764d-3ef8-455e-9bae-bd50ea206ce2@kernel.org \
--to=mailhol@kernel.org \
--cc=duy.nguyen.rh@renesas.com \
--cc=linux-can@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mbro1689@gmail.com \
--cc=minh.le.aj@renesas.com \
--cc=mkl@pengutronix.de \
--cc=socketcan@hartkopp.net \
--cc=stephane.grosjean@hms-networks.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.