On 1/15/21 2:59 PM, Vincent MAILHOL wrote:

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.

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.

What about future developments?

Does anyone have a clue about CAN-XL? Will we ever see real HW? Or will
10Base-T1 and 100Base-T1 take the market?

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

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 |