ip link valid options checking

Good Afternoon,

Do any of you know a way to check what options are valid when setting up a CAN device with the ip link commands, either from bash or through C++? I'm working on a piece of code that will get used on systems with varying CAN drivers and for instance one of them doesn't support CAN-FD, so how would I be able to know that setting the fd flag or dbitrate value would fail before calling the setup command and seeing it fail?

Quoted 8 lines

Good Afternoon,

Do any of you know a way to check what options are valid when setting up a CAN device with the ip link commands, either from bash or through C++? I'm working on a piece of code that will get used on systems with varying CAN drivers and for instance one of them doesn't support CAN-FD, so how would I be able to know that setting the fd flag or dbitrate value would fail before calling the setup command and seeing it fail?

I would suggest to use:

Quoted 1 line

ip --details link show can0

You can then parse the results to check if the data bitrate information is present. If so, it means that FD is supported. Also, the output might be easier to parse if formatted in json:

Quoted 1 line

ip --details --json --pretty link show can0

Alternatively, instead of using the command line, you might prefer to directly use the kernel netlink interface to directly retrieve the different modes supported by the controller. You can refer to iproute2 source code for the how-to:

priv->ctrlmode flags set in the driver (see also in a Linux tree under

ctrlmode_static. But for these flags there is no netlink interface to

Am Freitag, den 09.07.2021, 14:00 +0200 schrieb Vincent MAILHOL:

Unfortunately the netlink kernel interface gives access only to the IFLA_CAN_CTRLMODE data which boils down to an access of the netdev_priv(dev)-

Quoted 1 line

priv->ctrlmode flags set in the driver (see also in a Linux tree under

drivers/net/can/dev/netlink.c). But the "ctrlmode" flags represent only the current setup. So you can see if CAN-FD mode is currently enabled.

But I think the thread opener wants to know in advance if the kernel gives us the information what modes a certain driver supports. That is encoded in netdev_priv(dev)->priv->ctrlmode_supported and netdev_priv(dev)->priv-

Quoted 1 line

ctrlmode_static. But for these flags there is no netlink interface to

interrogate that settings at the moment.

So you can't see in advance if a CAN driver would support for instance triple- sampling or the CAN_CTRLMODE_CC_LEN8_DLC mode. To know it you must try to set such option atm. I think.

Hi Stefan,

Quoted 12 lines · Stefan Mätje

Am Freitag, den 09.07.2021, 14:00 +0200 schrieb Vincent MAILHOL:

Unfortunately the netlink kernel interface gives access only to the IFLA_CAN_CTRLMODE data which boils down to an access of the netdev_priv(dev)-

Quoted 1 line

priv->ctrlmode flags set in the driver (see also in a Linux tree under

drivers/net/can/dev/netlink.c). But the "ctrlmode" flags represent only the current setup. So you can see if CAN-FD mode is currently enabled.

But I think the thread opener wants to know in advance if the kernel gives us the information what modes a certain driver supports. That is encoded in netdev_priv(dev)->priv->ctrlmode_supported and netdev_priv(dev)->priv-

Quoted 7 lines

Quoted 1 line

ctrlmode_static. But for these flags there is no netlink interface to

interrogate that settings at the moment.

So you can't see in advance if a CAN driver would support for instance triple- sampling or the CAN_CTRLMODE_CC_LEN8_DLC mode. To know it you must try to set such option atm. I think.

Yes, but the settings of priv->ctrlmode_static may lead into problems too as there might be a fixed setting that can not be altered.

As you already pointed out the netlink interface only provides the current setting of priv->ctrlmode.

Btw. the struct can_ctrlmode has two u32 elements, so we could use the mask element to pass the priv->ctrlmode_supported value to the user space:

drivers/net/can/dev/netlink.c +2 -1

index e38c2566aff4..91c6ae06a576 100644
@@ -259,11 +259,12 @@ static size_t can_get_size(const struct net_device 
 *dev)
  }
 
  static int can_fill_info(struct sk_buff *skb, const struct net_device 
 *dev)
  {
         struct can_priv *priv = netdev_priv(dev);
-       struct can_ctrlmode cm = {.flags = priv->ctrlmode};
+       struct can_ctrlmode cm = {.flags = priv->ctrlmode,
+               .mask = priv->ctrlmode_supported};
         struct can_berr_counter bec = { };
         enum can_state state = priv->state;
 

         if (priv->do_get_state)
                 priv->do_get_state(dev, &state);

Additionally we could also make the mask element in struct can_ctrlmode a union with a 'supported' element ...

But this is, what would be needed here, right?