Hi Petro, I understand having 2 upper separate layers for CAN isn't welcomed. However I don't see any real particular gains for a generic can_ops_s for both the SocketCAN and CAN Char driver.
For example SocketCAN net_driver_s interface uses the dev->d_buf interface to transfer data and then invokes a callback to the actual driver. Whereas CAN Char uses the following prototype to call the driver directly int (*co_send)(FAR struct can_dev_s *dev, FAR struct can_msg_s *msg); If we would manage to unify this we would probably have to rewrite the net/can upper driver to facilitate this. Furthermore modifying the CAN Char can_hdr_s and can_msg_s data structure would break backwards compatibility with all applications using the existing CAN char driver. I'm not aware on the usage of the current CAN char driver is in general. Another option instead of breaking the backwards compatibility for the existing systems would be deprecating CAN Char and try to encourage the use of the SocketCAN driver and maybe migrate some platforms over as well. I've made a quick overview of all NuttX architectures implementing a CAN driver using both upper layers. +---------+----------+-----------+ | | Char CAN | SocketCAN | +---------+----------+-----------+ | AM335X | Yes | No | +---------+----------+-----------+ | IXMRT | No | Yes | +---------+----------+-----------+ | SAMA5 | Yes | No | +---------+----------+-----------+ | SAMV7 | Yes | No | +---------+----------+-----------+ | STM32L4 | Yes | No | +---------+----------+-----------+ | LPC43 | Yes | No | +---------+----------+-----------+ | STM32 | Yes | Yes | +---------+----------+-----------+ | Kinetis | No | Yes | +---------+----------+-----------+ | S32K1XX | No | Yes | +---------+----------+-----------+ | STM32F7 | Yes | No | +---------+----------+-----------+ | STM32H7 | No | Yes | +---------+----------+-----------+ | STM32L4 | Yes | No | +---------+----------+-----------+ | ESP32C3 | Yes | No | +---------+----------+-----------+ | | 9/13 | 5/13 | +---------+----------+-----------+
