ppisa commented on issue #15567: URL: https://github.com/apache/nuttx/issues/15567#issuecomment-3068535640
Thanks for analysis. As for the SocketCAN, we should follow its documentation/"specification" as closely as possible https://docs.kernel.org/networking/can.html The user-kernel setup structures are defined in https://elixir.bootlin.com/linux/v6.15.6/source/include/uapi/linux/can/netlink.h#L31 and IPROUTE2 is used for setup over NETLINK https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/tree/include/uapi/linux/can/netlink.h#n31 The setup code for bit-timing is in https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/tree/ip/iplink_can.c#n296 I am not sure if the `CANIOC_SET_BITTIMING` should be extended for FD or if the new separate `CANIOC_SET_BITTIMING_DATA` and `CANIOC_GET_BITTIMING_DATA` should be added. I would vote for new IOCTLs because I really do not like the `type` as the conditional field ``` #ifdef CONFIG_CAN_FD uint8_t type; /* Nominal/Data bit timing. This is * used to specify which bit timing * should be set/obtained. Applies * only if CAN FD is configured. */ #endif ``` Yes, we have proposed the type for RTEMS but it has been the new implementation from scratch without consideration for compatibility with already existing drivers and code. `canioc_bittiming_s` should be extended to include ` sample_point` at least to allow automatic setup when `bt_tseg1` and `bt_tseg2` are are set to zero, same as on Linux. `tq` and `brp` fields should be added as well for readback. The propagation segment is partially redundant but it is question how tseg1 and tseg2 maps to the chips, if tseg1 includes typical additional one time-quanta or not. The other option which would make sense is to add IOCTL for FD which would take array of two `canioc_bittiming_s` where the first is for arbitration and the second for data. There is problem that for some chips the prescaler should be set the same value for arbitration and data so setup of bittiming should account for both bitrates together. But we do not need to consider this complication for the start. As for [can_bittiming_const](https://elixir.bootlin.com/linux/v6.15.6/C/ident/can_bittiming_const) or may be `can_bittiming_const_s` for NuttX, I would propose in the longer term perspective to introduce some filed like `optimal_tq_per_bit`. This is something which I would like to introduce to Linux and RTEMS computations in longert timeframe. Or at least define this as some constant or range where I see about 20 as good minimal value. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
