1 TO-DO and Wish list for the Socket-CAN-Project:
2 ==============================================
7 - baudrate, speed -> bitrate
9 - names of CAN devices and modules
10 - prefix in variables and definitions of the SJA1000 driver
13 o Coding style issues:
15 E.g. net/can/dev.[ch] needs reformatting and beautification.
18 o CAN bit rate setting:
20 Default CAN bit rate calculation and custom bit rate setting in a
21 more hardware independent way should re-worked. See thread
22 https://lists.berlios.de/pipermail/socketcan-core/2007-October/000715.html.
25 o CAN state management:
27 How should the CAN state be managed? We have the common "state"
28 variable of the CAN device interface and the do_get_state() method.
31 - the common "state" variable is updated in the ISR and it always
32 hold the proper state. There's no need for do_get_state().
34 - if do_get_state(), it should return the proper state.
36 Part of it could be handled in common code.
39 o Controller start, stop and re-start (mode setting):
41 When and how should the controller be restarted? I see the following
44 - via ifconfig up/down
46 - via automatic restart in case of persistent error condition or
47 TX timeout (do we really need that?).
49 - via ioctl request SIOCGCANCTRLMODE / CAN_MODE_START
51 A restart may also be triggered by a baud-rate setting. The restart
52 behavior should also be configurable when the driver is statically
53 linked into the kernel (no module parameters).
56 o Local loopback device (echo).
58 The SJA1000 driver has a local loopback implemented:
61 * CAN network devices *should* support a local echo functionality
62 * (see Documentation/networking/can.txt). To test the handling of CAN
63 * interfaces that do not support the local echo both driver types are
64 * implemented inside this sja1000 driver. In the case that the driver does
65 * not support the echo the IFF_ECHO remains clear in dev->flags.
66 * This causes the PF_CAN core to perform the echo as a fallback solution.
72 See https://lists.berlios.de/pipermail/socketcan-core/2007-November/000789.html
75 o CAN controller mode setting:
77 Currently we have defined:
79 #define CAN_CTRLMODE_LOOPBACK 0x1
80 #define CAN_CTRLMODE_LISTENONLY 0x2
81 #define CAN_CTRLMODE_SINGLESHOT 0x3
83 How should the mode be set and handled by the driver.
86 o PROCFS or SYSFS support:
88 How to set/get common and specific device properties like the CAN
89 baudrate, ctrlmode or device statistics?
91 $ cat /proc/net/dev_can
92 i-face can-clock bitrate canstate err-warn err-pass buserrors overruns arb-lost wakeups restarts
93 can0 8000000 125000 active 5 3 92 0 0 0 6
94 can1 8000000 500000 stopped 0 0 0 0 0 0 0
97 o Driver options/parameters:
99 So far driver options have been set through module parameters. Does
100 it work with static linking as well? Should we switch to SYSFS.
103 o CAN device statistics:
105 I think it is to much biased by the SJA1000. It actually counts
106 the error interrupt sources of the SJA1000.
111 The debugging code should be reviewed and used consistantly.
118 o Using (N)NAPI, rx-poll for SJA1000 to deal better with high interrupt
119 load, especially bus error flooding (check MSCAN driver).
122 o Purge Tx queue before restarting the CAN [Vladislav Gribov]
125 o Automatic bit rate detection [Vladislav Gribov]
128 o Support for CAN tranceivers [Vladislav Gribov]
130 There are CAN interface boards which allows to switch CAN transceiver
131 between low-speed / high-speed . Shall be selection done over IOCTL or
132 other module parameter?
133 Are there any boards with termination resistance which may be switched
134 on/off? If yes, the same question: ioctl or module parameters?
137 o Interface to query the capabilities of the CAN controllers.