Thread (11 messages) 11 messages, 3 authors, 2021-01-16

Re: [PATCH v10 1/1] can: usb: etas_es58X: add support for ETAS ES58X CAN USB interfaces

From: Vincent MAILHOL <hidden>
Date: 2021-01-15 00:42:46
Also in: netdev

On Fri. 15 Jan 2021 at 02:23, Oliver Hartkopp [off-list ref] wrote:
Hi Vincent,

On 12.01.21 14:05, Vincent Mailhol wrote:
quoted
This driver supports the ES581.4, ES582.1 and ES584.1 interfaces from
ETAS GmbH (https://www.etas.com/en/products/es58x.php).
(..)
quoted
diff --git a/drivers/net/can/usb/etas_es58x/es58x_fd.c b/drivers/net/can/usb/etas_es58x/es58x_fd.c
new file mode 100644
index 000000000000..6b9534f23c96
--- /dev/null
+++ b/drivers/net/can/usb/etas_es58x/es58x_fd.c
(..)
quoted
+static void es58x_fd_print_bittiming(struct net_device *netdev,
+                                  struct es58x_fd_bittiming
+                                  *es58x_fd_bittiming, char *type)
+{
+     netdev_vdbg(netdev, "bitrate %s    = %d\n", type,
+                 le32_to_cpu(es58x_fd_bittiming->bitrate));
+     netdev_vdbg(netdev, "tseg1 %s      = %d\n", type,
+                 le16_to_cpu(es58x_fd_bittiming->tseg1));
+     netdev_vdbg(netdev, "tseg2 %s      = %d\n", type,
+                 le16_to_cpu(es58x_fd_bittiming->tseg2));
+     netdev_vdbg(netdev, "brp %s        = %d\n", type,
+                 le16_to_cpu(es58x_fd_bittiming->brp));
+     netdev_vdbg(netdev, "sjw %s        = %d\n", type,
+                 le16_to_cpu(es58x_fd_bittiming->sjw));
+}
What is the reason for this code?

These values can be retrieved with the 'ip' tool and are probably
interesting for development - but not in the final code.
First thing, I used netdev_vdbg() (verbose debug). That macro
will only produce code if VERBOSE_DEBUG is defined. Normal users
will not see those. So yes, this is mostly for development.

Also, just realised that netdev_vdbg() is barely used
anywhere (only three files use it:
https://elixir.bootlin.com/linux/v5.11-rc3/C/ident/netdev_vdbg).

I guess that I will remove it :)
quoted
+
+static void es58x_fd_print_conf(struct net_device *netdev,
+                             struct es58x_fd_tx_conf_msg *tx_conf_msg)
+{
+     es58x_fd_print_bittiming(netdev, &tx_conf_msg->nominal_bittiming,
+                              "nominal");
+     netdev_vdbg(netdev, "samples_per_bit    = %d\n",
+                 tx_conf_msg->samples_per_bit);
+     netdev_vdbg(netdev, "sync_edge          = %d\n",
+                 tx_conf_msg->sync_edge);
+     netdev_vdbg(netdev, "physical_layer     = %d\n",
+                 tx_conf_msg->physical_layer);
+     netdev_vdbg(netdev, "self_reception     = %d\n",
+                 tx_conf_msg->self_reception_mode);
+     netdev_vdbg(netdev, "ctrlmode           = %d\n", tx_conf_msg->ctrlmode);
+     netdev_vdbg(netdev, "canfd_enabled      = %d\n",
+                 tx_conf_msg->canfd_enabled);
+     if (tx_conf_msg->canfd_enabled) {
+             es58x_fd_print_bittiming(netdev,
+                                      &tx_conf_msg->data_bittiming, "data");
+             netdev_vdbg(netdev,
+                         "Transmitter Delay Compensation        = %d\n",
+                         tx_conf_msg->tdc);
+             netdev_vdbg(netdev,
+                         "Transmitter Delay Compensation Offset = %d\n",
+                         le16_to_cpu(tx_conf_msg->tdco));
+             netdev_vdbg(netdev,
+                         "Transmitter Delay Compensation Filter = %d\n",
+                         le16_to_cpu(tx_conf_msg->tdcf));
+     }
+}
Same here.

Either the information can be retrieved with the 'ip' tool OR the are
not necessary as set to some reasonable default anyway
Ack, will remove.
OR we should
implement the functionality in the general CAN driver infrastructure.
Would make sense to me to add the tdco (Transmitter Delay
Compensation Offset). Ref: ISO 11898-1 section
11.3.3 "Transmitter delay compensation"

I would just like your opinion on one topic: the tdco is specific
to CAN FD. If we add it, we have two choices:
  1. put it in struct can_bittiming: that will mean that we will
     have an unused field for classical CAN (field bittiming of
     struct can_priv).
  2. put it in struct can_priv (but outside of struct
     can_bittiming): no unused field but less pretty.

I think that 1/ is best.


Yours sincerely,
Vincent
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help