Merge branch 'drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied...

[linux-2.6-omap-h63xx.git] / Documentation / networking / can.txt

diff --git a/Documentation/networking/can.txt b/Documentation/networking/can.txt
index f1b2de1709296277758aac6ab6dad1757cc7ebe4..2035bc4932f224685992ca57b29e64de5da4934e 100644 (file)
--- a/Documentation/networking/can.txt
+++ b/Documentation/networking/can.txt
@@ -35,8 +35,9 @@ This file contains
     6.1 general settings
     6.2 local loopback of sent frames
     6.3 CAN controller hardware filters
     6.1 general settings
     6.2 local loopback of sent frames
     6.3 CAN controller hardware filters

-    6.4 currently supported CAN hardware
-    6.5 todo
+    6.4 The virtual CAN driver (vcan)
+    6.5 currently supported CAN hardware
+    6.6 todo

 
   7 Credits
 
 
   7 Credits
 


@@ -186,7 +187,7 @@ solution for a couple of reasons:
 
   The Linux network devices (by default) just can handle the
   transmission and reception of media dependent frames. Due to the
 
   The Linux network devices (by default) just can handle the
   transmission and reception of media dependent frames. Due to the

-  arbritration on the CAN bus the transmission of a low prio CAN-ID
+  arbitration on the CAN bus the transmission of a low prio CAN-ID

   may be delayed by the reception of a high prio CAN frame. To
   reflect the correct* traffic on the node the loopback of the sent
   data has to be performed right after a successful transmission. If
   may be delayed by the reception of a high prio CAN frame. To
   reflect the correct* traffic on the node the loopback of the sent
   data has to be performed right after a successful transmission. If


@@ -281,10 +282,10 @@ solution for a couple of reasons:
             sa_family_t can_family;
             int         can_ifindex;
             union {
             sa_family_t can_family;
             int         can_ifindex;
             union {

-                    struct { canid_t rx_id, tx_id; } tp16;
-                    struct { canid_t rx_id, tx_id; } tp20;
-                    struct { canid_t rx_id, tx_id; } mcnet;
-                    struct { canid_t rx_id, tx_id; } isotp;
+                    /* transport protocol class address info (e.g. ISOTP) */
+                    struct { canid_t rx_id, tx_id; } tp;
+
+                    /* reserved for future CAN protocols address information */

             } can_addr;
     };
 
             } can_addr;
     };
 


@@ -481,7 +482,7 @@ solution for a couple of reasons:
   - stats_timer: To calculate the Socket CAN core statistics
     (e.g. current/maximum frames per second) this 1 second timer is
     invoked at can.ko module start time by default. This timer can be
   - stats_timer: To calculate the Socket CAN core statistics
     (e.g. current/maximum frames per second) this 1 second timer is
     invoked at can.ko module start time by default. This timer can be

-    disabled by using stattimer=0 on the module comandline.
+    disabled by using stattimer=0 on the module commandline.

 
   - debug: (removed since SocketCAN SVN r546)
 
 
   - debug: (removed since SocketCAN SVN r546)
 


@@ -584,7 +585,42 @@ solution for a couple of reasons:
   @133MHz with four SJA1000 CAN controllers from 2002 under heavy bus
   load without any problems ...
 
   @133MHz with four SJA1000 CAN controllers from 2002 under heavy bus
   load without any problems ...
 

-  6.4 currently supported CAN hardware (September 2007)
+  6.4 The virtual CAN driver (vcan)
+
+  Similar to the network loopback devices, vcan offers a virtual local
+  CAN interface. A full qualified address on CAN consists of
+
+  - a unique CAN Identifier (CAN ID)
+  - the CAN bus this CAN ID is transmitted on (e.g. can0)
+
+  so in common use cases more than one virtual CAN interface is needed.
+
+  The virtual CAN interfaces allow the transmission and reception of CAN
+  frames without real CAN controller hardware. Virtual CAN network
+  devices are usually named 'vcanX', like vcan0 vcan1 vcan2 ...
+  When compiled as a module the virtual CAN driver module is called vcan.ko
+
+  Since Linux Kernel version 2.6.24 the vcan driver supports the Kernel
+  netlink interface to create vcan network devices. The creation and
+  removal of vcan network devices can be managed with the ip(8) tool:
+
+  - Create a virtual CAN network interface:
+       ip link add type vcan
+
+  - Create a virtual CAN network interface with a specific name 'vcan42':
+       ip link add dev vcan42 type vcan
+
+  - Remove a (virtual CAN) network interface 'vcan42':
+       ip link del vcan42
+
+  The tool 'vcan' from the SocketCAN SVN repository on BerliOS is obsolete.
+
+  Virtual CAN network device creation in older Kernels:
+  In Linux Kernel versions < 2.6.24 the vcan driver creates 4 vcan
+  netdevices at module load time by default. This value can be changed
+  with the module parameter 'numdev'. E.g. 'modprobe vcan numdev=8'
+
+  6.5 currently supported CAN hardware

 
   On the project website http://developer.berlios.de/projects/socketcan
   there are different drivers available:
 
   On the project website http://developer.berlios.de/projects/socketcan
   there are different drivers available:


@@ -603,7 +639,7 @@ solution for a couple of reasons:
 
   Please check the Mailing Lists on the berlios OSS project website.
 
 
   Please check the Mailing Lists on the berlios OSS project website.
 

-  6.5 todo (September 2007)
+  6.6 todo

 
   The configuration interface for CAN network drivers is still an open
   issue that has not been finalized in the socketcan project. Also the
 
   The configuration interface for CAN network drivers is still an open
   issue that has not been finalized in the socketcan project. Also the