drivers/net/can/dev/dev.c | 1 + 1 file changed, 1 insertion(+)
The idea behind series 6c1f5146b214 ("Merge patch series "can: raw: better
approach to instantly reject unsupported CAN frames"") is to set the
capabilities of a CAN device (CAN-CC, CAN-FD, CAN-XL, and listen only) [1]
and, based on these capabilities, reject unsupported CAN frames in the
CAN-RAW protocol [2].
This works perfectly for CAN devices configured in CAN-FD or CAN-XL mode.
CAN devices with static CAN control modes define their capabilities via
can_set_static_ctrlmode() -> can_set_cap_info(). CAN devices configured by
the user space for CAN-FD or CAN-XL set their capabilities via
can_changelink() -> can_ctrlmode_changelink() -> can_set_cap_info().
However, in commit 166e87329ce6 ("can: propagate CAN device capabilities
via ml_priv"), the capabilities of CAN devices are not initialized.
This results in CAN-RAW rejecting all CAN frames on devices directly
after ifup if the user space has not changed the CAN control mode.
Fix this problem by setting the default capabilities to CAN-CC in
alloc_candev_mqs() as soon as the CAN specific ml_priv is allocated.
[1] commit 166e87329ce6 ("can: propagate CAN device capabilities via ml_priv")
[2] commit faba5860fcf9 ("can: raw: instantly reject disabled CAN frames")
Fixes: 166e87329ce6 ("can: propagate CAN device capabilities via ml_priv")
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/dev/dev.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/can/dev/dev.c b/drivers/net/can/dev/dev.c
index 7ab9578f5b89..769745e22a3c 100644
--- a/drivers/net/can/dev/dev.c
+++ b/drivers/net/can/dev/dev.c
@@ -332,6 +332,7 @@ struct net_device *alloc_candev_mqs(int sizeof_priv, unsigned int echo_skb_max,
can_ml = (void *)priv + ALIGN(sizeof_priv, NETDEV_ALIGN);
can_set_ml_priv(dev, can_ml);
+ can_set_cap(dev, CAN_CAP_CC);
if (echo_skb_max) {
priv->echo_skb_max = echo_skb_max;
---
base-commit: a74c7a58ca2ca1cbb93f4c01421cf24b8642b962
change-id: 20260116-can_add_missing_set_caps-388627edda13
Best regards,
--
Marc Kleine-Budde <mkl@pengutronix.de>
On 16.01.2026 13:44:22, Marc Kleine-Budde wrote:
> The idea behind series 6c1f5146b214 ("Merge patch series "can: raw: better
> approach to instantly reject unsupported CAN frames"") is to set the
> capabilities of a CAN device (CAN-CC, CAN-FD, CAN-XL, and listen only) [1]
> and, based on these capabilities, reject unsupported CAN frames in the
> CAN-RAW protocol [2].
>
> This works perfectly for CAN devices configured in CAN-FD or CAN-XL mode.
> CAN devices with static CAN control modes define their capabilities via
> can_set_static_ctrlmode() -> can_set_cap_info(). CAN devices configured by
> the user space for CAN-FD or CAN-XL set their capabilities via
> can_changelink() -> can_ctrlmode_changelink() -> can_set_cap_info().
>
> However, in commit 166e87329ce6 ("can: propagate CAN device capabilities
> via ml_priv"), the capabilities of CAN devices are not initialized.
> This results in CAN-RAW rejecting all CAN frames on devices directly
> after ifup if the user space has not changed the CAN control mode.
>
> Fix this problem by setting the default capabilities to CAN-CC in
> alloc_candev_mqs() as soon as the CAN specific ml_priv is allocated.
>
> [1] commit 166e87329ce6 ("can: propagate CAN device capabilities via ml_priv")
> [2] commit faba5860fcf9 ("can: raw: instantly reject disabled CAN frames")
>
> Fixes: 166e87329ce6 ("can: propagate CAN device capabilities via ml_priv")
> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Applied with fixed subject to linux-can.
Thanks,
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 |
… > Fix this problem by setting the default capabilities to CAN-CC in > alloc_candev_mqs() as soon as the CAN specific ml_priv is allocated. Please avoid a typo in the summary phrase. Regards, Markus
On 16.01.26 13:44, Marc Kleine-Budde wrote:
> The idea behind series 6c1f5146b214 ("Merge patch series "can: raw: better
> approach to instantly reject unsupported CAN frames"") is to set the
> capabilities of a CAN device (CAN-CC, CAN-FD, CAN-XL, and listen only) [1]
> and, based on these capabilities, reject unsupported CAN frames in the
> CAN-RAW protocol [2].
>
> This works perfectly for CAN devices configured in CAN-FD or CAN-XL mode.
> CAN devices with static CAN control modes define their capabilities via
> can_set_static_ctrlmode() -> can_set_cap_info(). CAN devices configured by
> the user space for CAN-FD or CAN-XL set their capabilities via
> can_changelink() -> can_ctrlmode_changelink() -> can_set_cap_info().
>
> However, in commit 166e87329ce6 ("can: propagate CAN device capabilities
> via ml_priv"), the capabilities of CAN devices are not initialized.
> This results in CAN-RAW rejecting all CAN frames on devices directly
> after ifup if the user space has not changed the CAN control mode.
Ah! It's about setting the bitrate without changing the control mode.
Sorry. I tested multiple configurations several times but missed the
most simple one as initial test :-/
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Best regards,
Oliver
>
> Fix this problem by setting the default capabilities to CAN-CC in
> alloc_candev_mqs() as soon as the CAN specific ml_priv is allocated.
>
> [1] commit 166e87329ce6 ("can: propagate CAN device capabilities via ml_priv")
> [2] commit faba5860fcf9 ("can: raw: instantly reject disabled CAN frames")
>
> Fixes: 166e87329ce6 ("can: propagate CAN device capabilities via ml_priv")
> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
> ---
> drivers/net/can/dev/dev.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/can/dev/dev.c b/drivers/net/can/dev/dev.c
> index 7ab9578f5b89..769745e22a3c 100644
> --- a/drivers/net/can/dev/dev.c
> +++ b/drivers/net/can/dev/dev.c
> @@ -332,6 +332,7 @@ struct net_device *alloc_candev_mqs(int sizeof_priv, unsigned int echo_skb_max,
>
> can_ml = (void *)priv + ALIGN(sizeof_priv, NETDEV_ALIGN);
> can_set_ml_priv(dev, can_ml);
> + can_set_cap(dev, CAN_CAP_CC);
>
> if (echo_skb_max) {
> priv->echo_skb_max = echo_skb_max;
>
> ---
> base-commit: a74c7a58ca2ca1cbb93f4c01421cf24b8642b962
> change-id: 20260116-can_add_missing_set_caps-388627edda13
>
> Best regards,
> --
> Marc Kleine-Budde <mkl@pengutronix.de>
>
On 16.01.26 14:10, Oliver Hartkopp wrote:
> On 16.01.26 13:44, Marc Kleine-Budde wrote:
>> However, in commit 166e87329ce6 ("can: propagate CAN device capabilities
>> via ml_priv"), the capabilities of CAN devices are not initialized.
>> This results in CAN-RAW rejecting all CAN frames on devices directly
>> after ifup if the user space has not changed the CAN control mode.
>
> Ah! It's about setting the bitrate without changing the control mode.
>
> Sorry. I tested multiple configurations several times but missed the
> most simple one as initial test :-/
>
> Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Tested-by: Oliver Hartkopp <socketcan@hartkopp.net>
Fixed typo in subject (capabilitied -> capabilities) for v2. 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 |
© 2016 - 2026 Red Hat, Inc.