4 This patch adds documentation for the PF_CAN protocol family.
6 Signed-off-by: Oliver Hartkopp <oliver.hartkopp@volkswagen.de>
7 Signed-off-by: Urs Thuermann <urs.thuermann@volkswagen.de>
10 Documentation/networking/00-INDEX | 2
11 Documentation/networking/can.txt | 635 ++++++++++++++++++++++++++++++++++++++
12 2 files changed, 637 insertions(+)
14 Index: linux-2.6.22/Documentation/networking/can.txt
15 ===================================================================
16 --- /dev/null 1970-01-01 00:00:00.000000000 +0000
17 +++ linux-2.6.22/Documentation/networking/can.txt 2007-08-03 11:06:26.000000000 +0200
19 +============================================================================
23 +Readme file for the Controller Area Network Protocol Family (aka Socket CAN)
27 + 1 Overview / What is Socket CAN
29 + 2 Motivation / Why using the socket API
31 + 3 Socket CAN concept
34 + 3.3 network security issues (capabilities)
35 + 3.4 network problem notifications
37 + 4 How to use Socket CAN
38 + 4.1 RAW protocol sockets with can_filters (SOCK_RAW)
39 + 4.1.1 RAW socket option CAN_RAW_FILTER
40 + 4.1.2 RAW socket option CAN_RAW_ERR_FILTER
41 + 4.1.3 RAW socket option CAN_RAW_LOOPBACK
42 + 4.1.4 RAW socket option CAN_RAW_RECV_OWN_MSGS
43 + 4.2 Broadcast Manager protocol sockets (SOCK_DGRAM)
44 + 4.3 connected transport protocols (SOCK_SEQPACKET)
45 + 4.4 unconnected transport protocols (SOCK_DGRAM)
47 + 5 Socket CAN core module
48 + 5.1 can.ko module params
50 + 5.3 writing own CAN protocol modules
52 + 6 CAN network drivers
53 + 6.1 general settings
55 + 6.3 CAN controller hardware filters
56 + 6.4 currently supported CAN hardware
61 +============================================================================
63 +1. Overview / What is Socket CAN
64 +--------------------------------
66 +The socketcan package is an implementation of CAN protocols
67 +(Controller Area Network) for Linux. CAN is a networking technology
68 +which has wide-spread use in automation, embedded devices, and
69 +automotive fields. While there have been other CAN implementations
70 +for Linux based on character devices, Socket CAN uses the Berkeley
71 +socket API, the Linux network stack and implements the CAN device
72 +drivers as network interfaces. The CAN socket API has been designed
73 +as similar as possible to the TCP/IP protocols to allow programmers,
74 +familiar with network programming, to easily learn how to use CAN
77 +2. Motivation / Why using the socket API
78 +----------------------------------------
80 +There have been CAN implementations for Linux before Socket CAN so the
81 +question arises, why we have started another project. Most existing
82 +implementations come as a device driver for some CAN hardware, they
83 +are based on character devices and provide comparatively little
84 +functionality. Usually, there is only a hardware-specific device
85 +driver which provides a character device interface to send and
86 +receive raw CAN frames, directly to/from the controller hardware.
87 +Queueing of frames and higher-level transport protocols like ISO-TP
88 +have to be implemented in user space applications. Also, most
89 +character-device implementations support only one single process to
90 +open the device at a time, similar to a serial interface. Exchanging
91 +the CAN controller requires employment of another device driver and
92 +often the need for adaption of large parts of the application to the
95 +Socket CAN was designed to overcome all of these limitations. A new
96 +protocol family has been implemented which provides a socket interface
97 +to user space applications and which builds upon the Linux network
98 +layer, so to use all of the provided queueing functionality. Device
99 +drivers for CAN controller hardware register itself with the Linux
100 +network layer as a network device, so that CAN frames from the
101 +controller can be passed up to the network layer and on to the CAN
102 +protocol family module and also vice-versa. Also, the protocol family
103 +module provides an API for transport protocol modules to register, so
104 +that any number of transport protocols can be loaded or unloaded
105 +dynamically. In fact, the can core module alone does not provide any
106 +protocol and can not be used without loading at least one additional
107 +protocol module. Multiple sockets can be opened at the same time,
108 +on different or the same protocol module and they can listen/send
109 +frames on different or the same CAN IDs. Several sockets listening on
110 +the same interface for frames with the same CAN ID are all passed the
111 +same received matching CAN frames. An application wishing to
112 +communicate using a specific transport protocol, e.g. ISO-TP, just
113 +selects that protocol when opening the socket, and then can read and
114 +write application data byte streams, without having to deal with
115 +CAN-IDs, frames, etc.
117 +Similar functionality visible from user-space could be provided by a
118 +character decive, too, but this would lead to a technically inelegant
119 +solution for a couple of reasons:
121 +* Intricate usage. Instead of passing a protocol argument to
122 + socket(2) and using bind(2) to select a CAN interface and CAN ID, an
123 + application would have to do all these operations using ioctl(2)s.
125 +* Code duplication. A character device cannot make use of the Linux
126 + network queueing code, so all that code would have to be duplicated
127 + for CAN networking.
129 +* Abstraction. In most existing character-device implementations, the
130 + hardware-specific device driver for a CAN controller directly
131 + provides the character device for the application to work with.
132 + This is at least very unusual in Unix systems, for both, char and
133 + block devices. For example you don't have a character device for a
134 + certain UART of a serial interface, a certain sound chip in your
135 + computer, a SCSI or IDE controller providing access to your hard
136 + disk or tape streamer device. Instead, you have abstraction layers
137 + which provide a unified character or block device interface to the
138 + application on the one hand, and a interface for hardware-specific
139 + device drivers on the other hand. These abstractions are provided
140 + by subsystems like the tty layer, the audio subsystem or the SCSI
141 + and IDE subsystems for the devices mentioned above.
143 + The easiest way to implement a CAN device driver is as a character
144 + without such a (complete) abstraction layer, as is done by most
145 + existing drivers. The right way, however, would be to add such a
146 + layer with all the functionality like registering for certain CAN
147 + IDs, supporting several open file descriptors and (de)multplexing
148 + CAN frames between them, (sophisticated) queueing of CAN frames, and
149 + providing an API for device driver to register with. However, then
150 + it would be no more difficult, or may be even easier, to use the
151 + networking framework provided by the Linux kernel, and this is what
154 + The use of the networking framework of the Linux kernel is just the
155 + natural and most appropriate way to implement CAN for Linux.
157 +3. Socket CAN concept
158 +---------------------
160 + As described in chapter 2 it is the main goal of Socket CAN to
161 + provide a socket interface to user space applications which builds
162 + upon the Linux networklayer. In opposite to the commonly known
163 + TCP/IP and ethernet networking the CAN bus is a broadcast-only(!)
164 + medium that has no MAC-layer adressing like ethernet. The CAN-identifier
165 + (can_id) is used for arbitration on the CAN-bus. Therefore the CAN-IDs
166 + have to be choosen unique on the bus. When designing a CAN-ECU
167 + network the CAN-IDs are mapped to be sent by a specific ECU.
168 + For this reason a CAN-ID can be treatened best as a kind of source address.
172 + The network transparent access of multiple applications leads to the
173 + problem that different applications may be interrested in the same
174 + CAN-IDs from the same CAN network interface. The Socket CAN core
175 + module - which implements the protocol family CAN - provides several
176 + high efficient receive lists for this reason. If e.g. a user space
177 + application opens a CAN RAW socket, the raw protocol module itself
178 + requests the (range of) CAN-IDs from the Socket CAN core that are
179 + requested by the user. The subscription and unsubscription of
180 + CAN-IDs can be done for specific CAN interfaces or for all(!) known
181 + CAN interfaces with the can_rx_(un)register() functions provided to
182 + CAN protocol modules by the SocketCAN core (see chapter 5).
183 + To optimize the CPU usage at runtime the receive lists are split up
184 + into several specific lists per device that match the requested
185 + filter complexity for a given use-case.
189 + As known from other networking concepts the data exchanging
190 + applications may run on the same or different nodes without any
191 + change (except if the according addressing information):
193 + ___ ___ ___ _______ ___
194 + | _ | | _ | | _ | | _ _ | | _ |
195 + ||A|| ||B|| ||C|| ||A| |B|| ||C||
196 + |___| |___| |___| |_______| |___|
198 + -----------------(1)- CAN bus -(2)---------------
200 + To ensure that application A receives the same information in the
201 + expample (2) as it would receive in example (1) there is need for
202 + some kind of local loopback on the appropriate node.
204 + The Linux network devices (by default) just can handle the
205 + transmission and receiption of media dependend frames. Due to the
206 + arbritration on the CAN bus the transmission of a low prio CAN-ID
207 + may be delayed from the receipition of a high prio CAN frame. To
208 + reflect the correct* traffic on the node the loopback of the sent
209 + data has to be performed right after a successful transmission. If
210 + the CAN network interface is not capable to perform the loopback for
211 + some reason the SocketCAN core can do this task as a fallback solution.
212 + See chapter 6.2 for details (recommended).
214 + The loopback functionality is enabled by default to reflect standard
215 + networking behaviour for CAN applications. Due to some requests from
216 + the RT-SocketCAN group the loopback optionally may be disabled for each
217 + seperate socket. See sockopts from the CAN RAW sockets in chapter 4.1 .
219 + * = you really like to have this when you're running analyser tools
220 + like 'candump' or 'cansniffer' on the (same) node.
222 + 3.3 network security issues (capabilities)
224 + The Controller Area Network is a local field bus transmitting only
225 + broadcast messages without any routing and security concepts.
226 + In the majority of cases the user application has to deal with
227 + raw CAN frames. Therefore it might be reasonable NOT to restrict
228 + the CAN access only to the user root, as known from other networks.
229 + Since the currently implemented CAN_RAW and CAN_BCM sockets can only
230 + send and receive frames to/from CAN interfaces it does not affect
231 + security of others networks to allow all users to access the CAN.
232 + To enable non-root users to access CAN_RAW and CAN_BCM protocol
233 + sockets the Kconfig options CAN_RAW_USER and/or CAN_BCM_USER may be
234 + selected at kernel compile time.
236 + 3.4 network problem notifications
238 + The use of the CAN bus may lead to several problems on the physical
239 + and media access control layer. Detecting and logging of these lower
240 + layer problems is a vital requirement for CAN users to identify
241 + hardware issues on the physical transceiver layer as well as
242 + arbitration problems and error frames caused by the different
243 + ECUs. The occurance of detected errors are important for diagnosis
244 + and have to be logged together with the exact timestamp. For this
245 + reason the CAN interface driver can generate so called Error Frames
246 + that can optionally be passed to the user application on the same
247 + way like other CAN frames. Whenever an error on the physical layer
248 + or the MAC layer is detected (e.g. by the CAN controller) the driver
249 + creates an appropriate error frame. Error frames can be requested by
250 + the user application using the common CAN filter mechanisms. Inside
251 + this filter definition the (interrested) type of errors may be
252 + selected. The receiption of error frames is disabled by default.
254 +4. How to use Socket CAN
255 +------------------------
257 + Like TCP/IP, you first need to open a socket for communicating over a
258 + CAN network. Since Socket CAN implements a new protocol family, you
259 + need to pass PF_CAN as the first argument to the socket(2) system
260 + call. Currently, there are two CAN protocols to choose from, the raw
261 + socket protocol and the broadcast manager (BCM). So to open a socket,
264 + s = socket(PF_CAN, SOCK_RAW, CAN_RAW);
268 + s = socket(PF_CAN, SOCK_DGRAM, CAN_BCM);
270 + respectively. After the successful creation of the socket, you would
271 + normally use the bind(2) system call to bind the socket to a CAN
272 + interface (which is different to TCP/IP due to different addressing
273 + - see chapter 3). After binding (CAN_RAW) or connecting (CAN_BCM)
274 + the socket, you can read(2) and write(2) from/to the socket or use
275 + send(2), sendto(2), sendmsg(2) and the recv* counterpart operations
276 + on the socket as usual. There are also CAN specific socket options
279 + The basic CAN frame structure and the sockaddr structure are defined
280 + in include/linux/can.h:
283 + canid_t can_id; /* 32 bit CAN_ID + EFF/RTR/ERR flags */
284 + __u8 can_dlc; /* data length code: 0 .. 8 */
285 + __u8 data[8] __attribute__((aligned(8)));
288 + The alignment of the (linear) payload data[] to a 64bit boundary
289 + allows the user to define own structs and unions to easily access the
290 + CAN payload. There is no given byteorder on the CAN bus by
291 + default. A read(2) system call on a CAN_RAW socket transfers a
292 + struct can_frame to the user space.
294 + The sockaddr_can structure has an interface index analogue to the
295 + PF_PACKET socket, that also binds to a specific interface:
297 + struct sockaddr_can {
298 + sa_family_t can_family;
301 + struct { canid_t rx_id, tx_id; } tp16;
302 + struct { canid_t rx_id, tx_id; } tp20;
303 + struct { canid_t rx_id, tx_id; } mcnet;
304 + struct { canid_t rx_id, tx_id; } isotp;
305 + struct { int lcu, type; } bap;
309 + To determine the interface index the an appropriate ioctl() has to
310 + be used (example for CAN_RAW sockets without error checking):
313 + struct sockaddr_can addr;
316 + s = socket(PF_CAN, SOCK_RAW, CAN_RAW);
318 + strcpy(ifr.ifr_name, "can0" );
319 + ioctl(s, SIOCGIFINDEX, &ifr);
321 + addr.can_family = AF_CAN;
322 + addr.can_ifindex = ifr.ifr_ifindex;
324 + bind(s, (struct sockaddr *)&addr, sizeof(addr));
328 + To bind a socket to all(!) CAN interfaces the interface index might
329 + be 0 (zero). In this case the socket receives CAN frames from every
330 + enabled CAN interface. To determine the originating CAN interface
331 + the system call recvfrom(2) may be used instead of read(2). To send
332 + on a socket that is bound to 'any' interface sendto(2) is needed to
333 + specify the outgoing interface.
335 + Reading CAN frames from a bound CAN_RAW socket (see above) consists
336 + of reading a struct can_frame:
338 + struct can_frame frame;
340 + nbytes = read(s, &frame, sizeof(struct can_frame));
343 + perror("can raw socket read");
347 + /* paraniod check ... */
348 + if (nbytes < sizeof(struct can_frame)) {
349 + fprintf(stderr, "read: incomplete CAN frame\n");
353 + /* do something with the received CAN frame */
355 + Writing CAN frames can be done analogue with the write(2) system call:
357 + nbytes = write(s, &frame, sizeof(struct can_frame));
359 + When the CAN interface is bound to 'any' existing CAN interface
360 + (addr.can_ifindex = 0) it is recommended to use recvfrom(2) if the
361 + information about the originating CAN interface is needed:
363 + struct sockaddr_can addr;
365 + socklen_t len = sizeof(addr);
366 + struct can_frame frame;
368 + nbytes = recvfrom(s, &frame, sizeof(struct can_frame),
369 + 0, (struct sockaddr*)&addr, &len);
371 + /* get interface name of the received CAN frame */
372 + ifr.ifr_ifindex = addr.can_ifindex;
373 + ioctl(s, SIOCGIFNAME, &ifr);
374 + printf("Received a CAN frame from interface %s", ifr.ifr_name);
376 + To write CAN frames on sockets bound to 'any' CAN interface the
377 + outgoing interface has to be defined certainly.
379 + strcpy(ifr.ifr_name, "can0");
380 + ioctl(s, SIOCGIFINDEX, &ifr);
381 + addr.can_ifindex = ifr.ifr_ifindex;
382 + addr.can_family = AF_CAN;
384 + nbytes = sendto(s, &frame, sizeof(struct can_frame),
385 + 0, (struct sockaddr*)&addr, sizeof(addr));
387 + 4.1 RAW protocol sockets with can_filters (SOCK_RAW)
389 + Using CAN_RAW sockets is extensively comparable to the commonly
390 + known access to CAN character devices. To meet the new possibilities
391 + provided by the multi user SocketCAN approach, some reasonable
392 + defaults are set at RAW socket bindung time:
394 + - The filters are set to exactly one filter receiving everything
395 + - The socket only receives valid data frames (=> no error frames)
396 + - The loopback of sent CAN frames is enabled (see chapter 3.2)
397 + - The socket does not receive it's own sent frames (in loopback mode)
399 + These default settings may be changed before or after binding the socket.
400 + To use the referenced definitions of the socket options for CAN_RAW
401 + sockets include linux/can/raw.h .
403 + 4.1.1 RAW socket option CAN_RAW_FILTER
405 + The receiption of CAN frames using CAN_RAW sockets can be controlled
406 + by defining 0 .. n filters with the CAN_RAW_FILTER socket option.
408 + The CAN filter structure is defined in include/linux/can.h:
410 + struct can_filter {
415 + A filter matches, when
417 + <received_can_id> & mask == can_id & mask
419 + which is analogue to known CAN controllers hardware filter semantics.
420 + The filter can be inverted in this semantic, when the CAN_INV_FILTER
421 + bit is set in can_id element of the can_filter structure. In
422 + opposite to CAN controller hardware filters the user may set 0 .. n
423 + receive filters for each open socket separately:
425 + struct can_filter rfilter[2];
427 + rfilter[0].can_id = 0x123;
428 + rfilter[0].can_mask = CAN_SFF_MASK;
429 + rfilter[1].can_id = 0x200;
430 + rfilter[1].can_mask = 0x700;
432 + setsockopt(s, SOL_CAN_RAW, CAN_RAW_FILTER, &rfilter, sizeof(rfilter));
434 + To disable the receiption of CAN frames on the selected CAN_RAW socket:
436 + setsockopt(s, SOL_CAN_RAW, CAN_RAW_FILTER, NULL, 0);
438 + To set the filters to zero filters is quite obsolete as not readed
439 + data causes the raw socket to discard the received CAN frames. But
440 + having this 'send only' use-case we may remove the receive list in the
441 + Kernel to save a little (really a very little!) CPU usage.
443 + 4.1.2 RAW socket option CAN_RAW_ERR_FILTER
445 + As described in chapter 3.4 the CAN interface driver can generate so
446 + called Error Frames that can optionally be passed to the user
447 + application on the same way like other CAN frames. The possible
448 + errors are devided into different error classes that may be filtered
449 + using the appropriate error mask. To register for every possible
450 + error condition CAN_ERR_MASK can be used as value for the error mask.
451 + The values for the error mask are defined in linux/can/error.h .
453 + can_err_mask_t err_mask = ( CAN_ERR_TX_TIMEOUT | CAN_ERR_BUSOFF );
455 + setsockopt(s, SOL_CAN_RAW, CAN_RAW_ERR_FILTER,
456 + &err_mask, sizeof(err_mask));
458 + 4.1.3 RAW socket option CAN_RAW_LOOPBACK
460 + To meet multi user needs the local loopback is enabled by default
461 + (see chapter 3.2 for details). But in some embedded use-cases
462 + (e.g. when only one application uses the CAN bus) this loopback
463 + functionality can be disabled (separately for each socket):
465 + int loopback = 0; /* 0 = disabled, 1 = enabled (default) */
467 + setsockopt(s, SOL_CAN_RAW, CAN_RAW_LOOPBACK, &loopback, sizeof(loopback));
469 + 4.1.4 RAW socket option CAN_RAW_RECV_OWN_MSGS
471 + When the local loopback is enabled, all the sent CAN frames are
472 + looped back to the open CAN sockets that registered for the CAN
473 + frames' CAN-ID on this given interface to meet the multi user
474 + needs. The receiption of the CAN frames on the same socket that was
475 + sending the CAN frame is assumed to be unwanted and therefore
476 + disabled by default. This default behaviour may be changed on
479 + int set_recv_own_msgs = 1; /* 0 = disabled (default), 1 = enabled */
481 + setsockopt(s, SOL_CAN_RAW, CAN_RAW_RECV_OWN_MSGS,
482 + &recv_own_msgs, sizeof(recv_own_msgs));
484 + 4.2 Broadcast Manager protocol sockets (SOCK_DGRAM)
485 + 4.3 connected transport protocols (SOCK_SEQPACKET)
486 + 4.4 unconnected transport protocols (SOCK_DGRAM)
489 +5. Socket CAN core module
490 +-------------------------
492 + The Socket CAN core module implements the protocol family
493 + PF_CAN. CAN protocol modules are loaded by the core module at
494 + runtime. The core module provides an interface for CAN protocol
495 + modules to subscribe needed CAN IDs (see chapter 3.1).
497 + 5.1 can.ko module params
499 + - stats_timer: To calculate the Socket CAN core statistics
500 + (e.g. current/maximum frames per second) this 1 second timer is
501 + invoked at can.ko module start time by default. This timer can be
502 + disabled giving stattimer=0 on the module comandline.
504 + - debug: When the Kconfig option CONFIG_CAN_DEBUG_CORE is set at
505 + compile time, the debug output code is compiled into the module.
506 + debug = 0x01 => print general debug information
507 + debug = 0x02 => print content of processed CAN frames
508 + debug = 0x04 => print content of processed socket buffers
510 + It is possible or have ORed values e.g. 3 or 7 for an output off
511 + all available debug information. Using 0x02 and 0x04 may flood
512 + your kernel log - so be careful.
516 + As described in chapter 3.1 the Socket CAN core uses several filter
517 + lists to deliver received CAN frames to CAN protocol modules. These
518 + receive lists, their filters and the count of filter matches can be
519 + checked in the appropriate receive list. All entries contain the
520 + device and a protocol module identifier:
522 + foo@bar:~$ cat /proc/net/can/rcvlist_all
524 + receive list 'rx_all':
528 + device can_id can_mask function userdata matches ident
529 + vcan0 000 00000000 f88e6370 f6c6f400 0 raw
532 + In this example an application requests any CAN traffic from vcan0.
534 + rcvlist_all - list for unfiltered entries (no filter operations)
535 + rcvlist_eff - list for single extended frame (EFF) entries
536 + rcvlist_err - list for error frames masks
537 + rcvlist_fil - list for mask/value filters
538 + rcvlist_inv - list for mask/value filters (inverse semantic)
539 + rcvlist_sff - list for single standard frame (SFF) entries
541 + Additional procfs files in /proc/net/can
543 + stats - Socket CAN core statistics (rx/tx frames, match ratios, ...)
544 + reset_stats - manual statistic reset
545 + version - prints the Socket CAN core version and the ABI version
547 + 5.3 writing own CAN protocol modules
549 + To implement a new protocol in the protocol family PF_CAN a new
550 + protocol has to be defined in include/linux/can.h .
551 + The prototypes and definitions to use the Socket CAN core can be
552 + accessed by including include/linux/can/core.h .
553 + Additionally to functions that register the CAN protocol and the
554 + CAN device notifier chain there are functions to subscribe CAN
555 + frames received by CAN interfaces and to send CAN frames:
557 + can_rx_register - subscribe CAN frames from a specific interface
558 + can_rx_unregister - unsubscribe CAN frames from a specific interface
559 + can_send - transmit a CAN frame (optional with local loopback)
561 + For details see the kerneldoc documentation in net/can/af_can.c or
562 + the source code of net/can/raw.c or net/can/bcm.c .
564 +6. CAN network drivers
565 +----------------------
567 + Writing a CAN network device driver is much easier than writing a
568 + CAN character device driver. Analogue to other know network device
569 + drivers you mainly have to deal with:
571 + - TX: Put the CAN frame from the socket buffer to the CAN controller.
572 + - RX: Put the CAN frame from the CAN controller to the socket buffer.
574 + See e.g. at Documentation/networking/netdevices.txt . The differences
575 + for writing CAN network device driver are described below:
577 + 6.1 general settings
579 + dev->type = ARPHRD_CAN; /* the netdevice hardware type */
580 + dev->flags = IFF_NOARP; /* CAN has no arp */
582 + dev->mtu = sizeof(struct can_frame);
584 + The struct can_frame is the payload of each socket buffer in the
585 + protocol family PF_CAN.
589 + As described in chapter 3.2 the CAN network device driver should
590 + support a local loopback functionality. If so the driver flag
591 + IFF_LOOPBACK has to be set to omit the PF_CAN core to perform the
592 + loopback as fallback solution:
594 + dev->flags = (IFF_NOARP | IFF_LOOPBACK);
596 + 6.3 CAN controller hardware filters
598 + To reduce the interrupt load on deep embedded systems some CAN
599 + controllers support the filtering of CAN IDs or ranges of CAN IDs.
600 + These hardware filter capabilities vary from controller to
601 + controller and have to be identified as not feasible in a multi-user
602 + networking approach. The use of the very controller specific
603 + hardware filters could make sense in a very dedicated use-case, as a
604 + filter on driver level would affect all users in the multi-user
605 + system. The high efficient filter sets inside the PF_CAN core allow
606 + to set different multiple filters for each socket separately.
607 + Therefore the use of hardware filters goes to the category 'handmade
608 + tuning on deep embedded systems'. The author is running a MPC603e
609 + @133MHz with four SJA1000 CAN controllers from 2002 under heavy bus
610 + load without any problems ...
612 + 6.4 currently supported CAN hardware (May 2007)
614 + On the project website http://developer.berlios.de/projects/socketcan
615 + there are different drivers available:
617 + vcan: Virtual CAN interface driver (if no real hardware is available)
618 + sja1000: Philips SJA1000 CAN controller (recommended)
619 + i82527: Intel i82527 CAN controller
620 + mscan: Motorola/Freescale CAN controller (e.g. inside SOC MPC5200)
621 + slcan: For a bunch of CAN adaptors that are attached via a
622 + serial line ASCII protocol (for serial / USB adaptors)
624 + Additionally the different CAN adaptors (ISA/PCI/PCMCIA/USB/Parport)
625 + from PEAK Systemtechnik support the CAN netdevice driver modell
626 + since Linux driver v6.0: http://www.peak-system.com/linux/index.htm
628 + Please check the Mailing Lists on the berlios OSS project website.
630 + 6.5 todo (May 2007)
632 + The configuration interface for CAN network drivers is still an open
633 + issue that has not been finalized in the socketcan project. Also the
634 + idea of having a library module (candev.ko) that holds functions
635 + that are needed by all CAN netdevices is not ready to ship.
636 + Your contribution is welcome.
641 + Oliver Hartkopp (PF_CAN core, filters, drivers, bcm)
642 + Urs Thuermann (PF_CAN core, kernel integration, socket interfaces, raw, vcan)
643 + Jan Kizka (RT-SocketCAN core, Socket-API reconciliation)
644 + Wolfgang Grandegger (RT-SocketCAN core & drivers, Raw Socket-API reviews)
645 + Robert Schwebel (design reviews, PTXdist integration)
646 + Marc Kleine-Budde (design reviews, Kernel 2.6 cleanups, drivers)
647 + Benedikt Spranger (reviews)
648 + Thomas Gleixner (LKML reviews, coding style, posting hints)
649 + Andrey Volkov (kernel subtree structure, ioctls, mscan driver)
650 + Matthias Brukner (first SJA1000 CAN netdevice implementation Q2/2003)
651 + Klaus Hitschler (PEAK driver integration)
652 + Uwe Koppe (CAN netdevices with PF_PACKET approach)
653 + Michael Schulze (driver layer loopback requirement, RT CAN drivers review)
654 Index: linux-2.6.22/Documentation/networking/00-INDEX
655 ===================================================================
656 --- linux-2.6.22.orig/Documentation/networking/00-INDEX 2007-07-16 21:42:28.000000000 +0200
657 +++ linux-2.6.22/Documentation/networking/00-INDEX 2007-07-16 21:54:42.000000000 +0200
659 - info on the driver for Baycom style amateur radio modems
661 - where to get user space programs for ethernet bridging with Linux.
663 + - documentation on CAN protocol family.
665 - info on drivers for COMX line of synchronous serial adapters.