+CC: Max Staudt <max@xxxxxxxxx> On Tue. 7 Jun. 2022 at 18:47, Dario Binacchi <dario.binacchi@xxxxxxxxxxxxxxxxxxxx> wrote: > This series originated as a result of CAN communication tests for an > application using the USBtin adapter (https://www.fischl.de/usbtin/). > The tests showed some errors but for the driver everything was ok. > Also, being the first time I used the slcan driver, I was amazed that > it was not possible to configure the bitrate via the ip tool. > For these two reasons, I started looking at the driver code and realized > that it didn't use the CAN network device driver interface. > > Starting from these assumptions, I tried to: > - Use the CAN network device driver interface. > - Set the bitrate via the ip tool. > - Send the open/close command to the adapter from the driver. > - Add ethtool support to reset the adapter errors. > - Extend the protocol to forward the adapter CAN communication > errors and the CAN state changes to the netdev upper layers. > > Except for the protocol extension patches (i. e. forward the adapter CAN > communication errors and the CAN state changes to the netdev upper > layers), the whole series has been tested. Testing the extension > protocol patches requires updating the adapter firmware. Before modifying > the firmware I think it makes sense to know if these extensions can be > considered useful. > > Before applying the series I used these commands: > > slcan_attach -f -s6 -o /dev/ttyACM0 > slcand ttyACM0 can0 > ip link set can0 up > > After applying the series I am using these commands: > > slcan_attach /dev/ttyACM0 > slcand ttyACM0 can0 > ip link set dev can0 down > ip link set can0 type can bitrate 500000 > ethtool --set-priv-flags can0 err-rst-on-open on > ip link set dev can0 up In his CAN327 driver, Max manages to bring the can0 device without the need of dedicated user space daemon by using line discipline (ldattach): https://lore.kernel.org/linux-can/20220602213544.68273-1-max@xxxxxxxxx/ Isn't the same feasible with slcan so that we completely remove the dependency toward slcand? Max what do you think of this? > Now there is a clearer separation between serial line and CAN, > but above all, it is possible to use the ip and ethtool commands > as it happens for any CAN device driver. The changes are backward > compatible, you can continue to use the slcand and slcan_attach > command options. Yours sincerely, Vincent Mailhol
