TODO

   1 TO-DO and Wish list for the Socket-CAN-Project:
   2 ==============================================
   3
   4
   5 o Naming issues:
   6
   7   - baudrate, speed -> bitrate
   8   - bit_time -> bittime
   9   - names of CAN devices and modules
  10   - prefix in variables and definitions of the SJA1000 driver
  11
  12
  13 o Coding style issues:
  14
  15   E.g. net/can/dev.[ch] needs reformatting and beautification.
  16
  17
  18 o CAN bit rate setting:
  19
  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.
  23
  24
  25 o CAN state management:
  26
  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.
  29   I see two methods:
  30
  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().
  33
  34   - if do_get_state(), it should return the proper state.
  35
  36   Part of it could be handled in common code.
  37
  38
  39 o Controller start, stop and re-start (mode setting):
  40
  41   When and how should the controller be restarted? I see the following
  42   three methods:
  43
  44   - via ifconfig up/down
  45
  46   - via automatic restart in case of persistent error condition or
  47     TX timeout (do we really need that?).
  48
  49   - via ioctl request SIOCGCANCTRLMODE / CAN_MODE_START
  50
  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).
  54
  55
  56 o Local loopback device (echo).
  57
  58   The SJA1000 driver has a local loopback implemented:
  59
  60   /*
  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.
  67    */
  68
  69
  70 o Feature RX-Probe:
  71
  72   See https://lists.berlios.de/pipermail/socketcan-core/2007-November/000789.html
  73
  74
  75 o CAN controller mode setting:
  76
  77   Currently we have defined:
  78
  79   #define CAN_CTRLMODE_LOOPBACK   0x1
  80   #define CAN_CTRLMODE_LISTENONLY 0x2
  81   #define CAN_CTRLMODE_SINGLESHOT 0x3
  82
  83   How should the mode be set and handled by the driver.
  84
  85
  86 o PROCFS or SYSFS support:
  87
  88   How to set/get common and specific device properties like the CAN
  89   baudrate, ctrlmode or device statistics?
  90
  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
  95
  96
  97 o Driver options/parameters:
  98
  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.
 101
 102
 103 o CAN device statistics:
 104
 105   I think it is to much biased by the SJA1000. It actually counts
 106   the error interrupt sources of the SJA1000.
 107
 108
 109 o Debugging code:
 110
 111   The debugging code should be reviewed and used consistantly.
 112
 113
 114
 115 Further wishes:
 116 --------------
 117
 118 o Using (N)NAPI, rx-poll for SJA1000 to deal better with high interrupt
 119   load, especially bus error flooding (check MSCAN driver).
 120
 121
 122 o Purge Tx queue before restarting the CAN [Vladislav Gribov]
 123
 124
 125 o Automatic bit rate detection [Vladislav Gribov]
 126
 127
 128 o Support for CAN tranceivers  [Vladislav Gribov]
 129
 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?
 135
 136
 137 o Interface to query the capabilities of the CAN controllers.