On 1/15/21 5:30 PM, Vincent MAILHOL wrote:

quoted

quoted

quoted

quoted

quoted

quoted

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.

3. Deprecate struct can_bittiming as the user space interface
    and transfer each member individually via netlink. Extend
    the kernel-only can_bittiming by the tdc related
    parameters, and add these to the new netlink interface.

Wow, didn't see that third option coming!

By "extend the kernel-only can_bittiming by the tdc related
parameters" do you mean to still use a single struct
can_bittiming for classical CAN and CAN FD with the tdc
parameters in both (a bit like what I suggested in 1.)?

Let's put it this way, we need 3. in order to implement 1. As we need a stable
userspace ABI.

I was not familiar enough with the netlink interface to foresee
all those dependencies but thanks to your explanations, now
everything starts to make sense.

quoted

Option 4:
We can introduce a struct can_bitiming_fd with the first member being the struct
can_bitiming and add tdc related variables after that. This way we can use the
same function to calculate the bit timing on both CAN and CAN-FD.

While option 3 is slightly easier, my preference will go to option 4.

We still need the netlink enhancement from option 3.

quoted

What about future developments?

Does anyone have a clue about CAN-XL? Will we ever see real HW?

Recent news would suggest that CiA will release the CAN XL
specification this year:
https://www.can-cia.org/news/cia-in-action/view/a-bright-future-for-can/2021/1/2/

Thanks, I've missed this.

quoted

Or will
10Base-T1 and 100Base-T1 take the market?

My guts tell me that 100Base-T1 will take the market for
autonomous driving (camera, Lidar...) and that CAN(-FD) has still
a bright future for safety critical domains, at least in the next
decade.

There are already automotive equipment out there, that uses CAN-FD and
100Base-T1. Wakeup via CAN-FD, once alive do other stuff via 100Base-T1.

Will CAN XL find its place or will it meet the same
destiny as flexray? I do not know. But once the specification and
the first hardware are out, we would probably start to implement
it in Socket CAN before knowing if it will win the market :)

Nonetheless, if we follow your idea of transferring each member
individually via netlink, then we will have enough flexibility to
adjust the new kernel only can_bitiming structures to our liking.

ACK

quoted

There are also these new transceivers in development that should be better
suited for "special" bus setups.

Do these require additional bittiming parameters?

Don't know - haven't had one of those in my hands, yet. They are called "CAN SIC
Transceivers" the slides promise Signal Improvement and former "Ringing
Suppression".

Back to TDC, which values do you want to provide to user space?

quoted

+		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));

Can we describe them in a HW independent way?

Marc

-- 
Pengutronix e.K.                 | Marc Kleine-Budde           |
Embedded Linux                   | https://www.pengutronix.de  |
Vertretung West/Dortmund         | Phone: +49-231-2826-924     |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-5555 |