On 1/15/21 2:59 PM, Vincent MAILHOL wrote: >>>>> 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 |
Attachment:
signature.asc
Description: OpenPGP digital signature
