linux/Documentation/networking/can.txt
<<
>>
Prefs
   1============================================================================
   2
   3can.txt
   4
   5Readme file for the Controller Area Network Protocol Family (aka Socket CAN)
   6
   7This file contains
   8
   9  1 Overview / What is Socket CAN
  10
  11  2 Motivation / Why using the socket API
  12
  13  3 Socket CAN concept
  14    3.1 receive lists
  15    3.2 local loopback of sent frames
  16    3.3 network security issues (capabilities)
  17    3.4 network problem notifications
  18
  19  4 How to use Socket CAN
  20    4.1 RAW protocol sockets with can_filters (SOCK_RAW)
  21      4.1.1 RAW socket option CAN_RAW_FILTER
  22      4.1.2 RAW socket option CAN_RAW_ERR_FILTER
  23      4.1.3 RAW socket option CAN_RAW_LOOPBACK
  24      4.1.4 RAW socket option CAN_RAW_RECV_OWN_MSGS
  25    4.2 Broadcast Manager protocol sockets (SOCK_DGRAM)
  26    4.3 connected transport protocols (SOCK_SEQPACKET)
  27    4.4 unconnected transport protocols (SOCK_DGRAM)
  28
  29  5 Socket CAN core module
  30    5.1 can.ko module params
  31    5.2 procfs content
  32    5.3 writing own CAN protocol modules
  33
  34  6 CAN network drivers
  35    6.1 general settings
  36    6.2 local loopback of sent frames
  37    6.3 CAN controller hardware filters
  38    6.4 The virtual CAN driver (vcan)
  39    6.5 The CAN network device driver interface
  40      6.5.1 Netlink interface to set/get devices properties
  41      6.5.2 Setting the CAN bit-timing
  42      6.5.3 Starting and stopping the CAN network device
  43    6.6 supported CAN hardware
  44
  45  7 Socket CAN resources
  46
  47  8 Credits
  48
  49============================================================================
  50
  511. Overview / What is Socket CAN
  52--------------------------------
  53
  54The socketcan package is an implementation of CAN protocols
  55(Controller Area Network) for Linux.  CAN is a networking technology
  56which has widespread use in automation, embedded devices, and
  57automotive fields.  While there have been other CAN implementations
  58for Linux based on character devices, Socket CAN uses the Berkeley
  59socket API, the Linux network stack and implements the CAN device
  60drivers as network interfaces.  The CAN socket API has been designed
  61as similar as possible to the TCP/IP protocols to allow programmers,
  62familiar with network programming, to easily learn how to use CAN
  63sockets.
  64
  652. Motivation / Why using the socket API
  66----------------------------------------
  67
  68There have been CAN implementations for Linux before Socket CAN so the
  69question arises, why we have started another project.  Most existing
  70implementations come as a device driver for some CAN hardware, they
  71are based on character devices and provide comparatively little
  72functionality.  Usually, there is only a hardware-specific device
  73driver which provides a character device interface to send and
  74receive raw CAN frames, directly to/from the controller hardware.
  75Queueing of frames and higher-level transport protocols like ISO-TP
  76have to be implemented in user space applications.  Also, most
  77character-device implementations support only one single process to
  78open the device at a time, similar to a serial interface.  Exchanging
  79the CAN controller requires employment of another device driver and
  80often the need for adaption of large parts of the application to the
  81new driver's API.
  82
  83Socket CAN was designed to overcome all of these limitations.  A new
  84protocol family has been implemented which provides a socket interface
  85to user space applications and which builds upon the Linux network
  86layer, so to use all of the provided queueing functionality.  A device
  87driver for CAN controller hardware registers itself with the Linux
  88network layer as a network device, so that CAN frames from the
  89controller can be passed up to the network layer and on to the CAN
  90protocol family module and also vice-versa.  Also, the protocol family
  91module provides an API for transport protocol modules to register, so
  92that any number of transport protocols can be loaded or unloaded
  93dynamically.  In fact, the can core module alone does not provide any
  94protocol and cannot be used without loading at least one additional
  95protocol module.  Multiple sockets can be opened at the same time,
  96on different or the same protocol module and they can listen/send
  97frames on different or the same CAN IDs.  Several sockets listening on
  98the same interface for frames with the same CAN ID are all passed the
  99same received matching CAN frames.  An application wishing to
 100communicate using a specific transport protocol, e.g. ISO-TP, just
 101selects that protocol when opening the socket, and then can read and
 102write application data byte streams, without having to deal with
 103CAN-IDs, frames, etc.
 104
 105Similar functionality visible from user-space could be provided by a
 106character device, too, but this would lead to a technically inelegant
 107solution for a couple of reasons:
 108
 109* Intricate usage.  Instead of passing a protocol argument to
 110  socket(2) and using bind(2) to select a CAN interface and CAN ID, an
 111  application would have to do all these operations using ioctl(2)s.
 112
 113* Code duplication.  A character device cannot make use of the Linux
 114  network queueing code, so all that code would have to be duplicated
 115  for CAN networking.
 116
 117* Abstraction.  In most existing character-device implementations, the
 118  hardware-specific device driver for a CAN controller directly
 119  provides the character device for the application to work with.
 120  This is at least very unusual in Unix systems for both, char and
 121  block devices.  For example you don't have a character device for a
 122  certain UART of a serial interface, a certain sound chip in your
 123  computer, a SCSI or IDE controller providing access to your hard
 124  disk or tape streamer device.  Instead, you have abstraction layers
 125  which provide a unified character or block device interface to the
 126  application on the one hand, and a interface for hardware-specific
 127  device drivers on the other hand.  These abstractions are provided
 128  by subsystems like the tty layer, the audio subsystem or the SCSI
 129  and IDE subsystems for the devices mentioned above.
 130
 131  The easiest way to implement a CAN device driver is as a character
 132  device without such a (complete) abstraction layer, as is done by most
 133  existing drivers.  The right way, however, would be to add such a
 134  layer with all the functionality like registering for certain CAN
 135  IDs, supporting several open file descriptors and (de)multiplexing
 136  CAN frames between them, (sophisticated) queueing of CAN frames, and
 137  providing an API for device drivers to register with.  However, then
 138  it would be no more difficult, or may be even easier, to use the
 139  networking framework provided by the Linux kernel, and this is what
 140  Socket CAN does.
 141
 142  The use of the networking framework of the Linux kernel is just the
 143  natural and most appropriate way to implement CAN for Linux.
 144
 1453. Socket CAN concept
 146---------------------
 147
 148  As described in chapter 2 it is the main goal of Socket CAN to
 149  provide a socket interface to user space applications which builds
 150  upon the Linux network layer. In contrast to the commonly known
 151  TCP/IP and ethernet networking, the CAN bus is a broadcast-only(!)
 152  medium that has no MAC-layer addressing like ethernet. The CAN-identifier
 153  (can_id) is used for arbitration on the CAN-bus. Therefore the CAN-IDs
 154  have to be chosen uniquely on the bus. When designing a CAN-ECU
 155  network the CAN-IDs are mapped to be sent by a specific ECU.
 156  For this reason a CAN-ID can be treated best as a kind of source address.
 157
 158  3.1 receive lists
 159
 160  The network transparent access of multiple applications leads to the
 161  problem that different applications may be interested in the same
 162  CAN-IDs from the same CAN network interface. The Socket CAN core
 163  module - which implements the protocol family CAN - provides several
 164  high efficient receive lists for this reason. If e.g. a user space
 165  application opens a CAN RAW socket, the raw protocol module itself
 166  requests the (range of) CAN-IDs from the Socket CAN core that are
 167  requested by the user. The subscription and unsubscription of
 168  CAN-IDs can be done for specific CAN interfaces or for all(!) known
 169  CAN interfaces with the can_rx_(un)register() functions provided to
 170  CAN protocol modules by the SocketCAN core (see chapter 5).
 171  To optimize the CPU usage at runtime the receive lists are split up
 172  into several specific lists per device that match the requested
 173  filter complexity for a given use-case.
 174
 175  3.2 local loopback of sent frames
 176
 177  As known from other networking concepts the data exchanging
 178  applications may run on the same or different nodes without any
 179  change (except for the according addressing information):
 180
 181         ___   ___   ___                   _______   ___
 182        | _ | | _ | | _ |                 | _   _ | | _ |
 183        ||A|| ||B|| ||C||                 ||A| |B|| ||C||
 184        |___| |___| |___|                 |_______| |___|
 185          |     |     |                       |       |
 186        -----------------(1)- CAN bus -(2)---------------
 187
 188  To ensure that application A receives the same information in the
 189  example (2) as it would receive in example (1) there is need for
 190  some kind of local loopback of the sent CAN frames on the appropriate
 191  node.
 192
 193  The Linux network devices (by default) just can handle the
 194  transmission and reception of media dependent frames. Due to the
 195  arbitration on the CAN bus the transmission of a low prio CAN-ID
 196  may be delayed by the reception of a high prio CAN frame. To
 197  reflect the correct* traffic on the node the loopback of the sent
 198  data has to be performed right after a successful transmission. If
 199  the CAN network interface is not capable of performing the loopback for
 200  some reason the SocketCAN core can do this task as a fallback solution.
 201  See chapter 6.2 for details (recommended).
 202
 203  The loopback functionality is enabled by default to reflect standard
 204  networking behaviour for CAN applications. Due to some requests from
 205  the RT-SocketCAN group the loopback optionally may be disabled for each
 206  separate socket. See sockopts from the CAN RAW sockets in chapter 4.1.
 207
 208  * = you really like to have this when you're running analyser tools
 209      like 'candump' or 'cansniffer' on the (same) node.
 210
 211  3.3 network security issues (capabilities)
 212
 213  The Controller Area Network is a local field bus transmitting only
 214  broadcast messages without any routing and security concepts.
 215  In the majority of cases the user application has to deal with
 216  raw CAN frames. Therefore it might be reasonable NOT to restrict
 217  the CAN access only to the user root, as known from other networks.
 218  Since the currently implemented CAN_RAW and CAN_BCM sockets can only
 219  send and receive frames to/from CAN interfaces it does not affect
 220  security of others networks to allow all users to access the CAN.
 221  To enable non-root users to access CAN_RAW and CAN_BCM protocol
 222  sockets the Kconfig options CAN_RAW_USER and/or CAN_BCM_USER may be
 223  selected at kernel compile time.
 224
 225  3.4 network problem notifications
 226
 227  The use of the CAN bus may lead to several problems on the physical
 228  and media access control layer. Detecting and logging of these lower
 229  layer problems is a vital requirement for CAN users to identify
 230  hardware issues on the physical transceiver layer as well as
 231  arbitration problems and error frames caused by the different
 232  ECUs. The occurrence of detected errors are important for diagnosis
 233  and have to be logged together with the exact timestamp. For this
 234  reason the CAN interface driver can generate so called Error Frames
 235  that can optionally be passed to the user application in the same
 236  way as other CAN frames. Whenever an error on the physical layer
 237  or the MAC layer is detected (e.g. by the CAN controller) the driver
 238  creates an appropriate error frame. Error frames can be requested by
 239  the user application using the common CAN filter mechanisms. Inside
 240  this filter definition the (interested) type of errors may be
 241  selected. The reception of error frames is disabled by default.
 242  The format of the CAN error frame is briefly decribed in the Linux
 243  header file "include/linux/can/error.h".
 244
 2454. How to use Socket CAN
 246------------------------
 247
 248  Like TCP/IP, you first need to open a socket for communicating over a
 249  CAN network. Since Socket CAN implements a new protocol family, you
 250  need to pass PF_CAN as the first argument to the socket(2) system
 251  call. Currently, there are two CAN protocols to choose from, the raw
 252  socket protocol and the broadcast manager (BCM). So to open a socket,
 253  you would write
 254
 255    s = socket(PF_CAN, SOCK_RAW, CAN_RAW);
 256
 257  and
 258
 259    s = socket(PF_CAN, SOCK_DGRAM, CAN_BCM);
 260
 261  respectively.  After the successful creation of the socket, you would
 262  normally use the bind(2) system call to bind the socket to a CAN
 263  interface (which is different from TCP/IP due to different addressing
 264  - see chapter 3). After binding (CAN_RAW) or connecting (CAN_BCM)
 265  the socket, you can read(2) and write(2) from/to the socket or use
 266  send(2), sendto(2), sendmsg(2) and the recv* counterpart operations
 267  on the socket as usual. There are also CAN specific socket options
 268  described below.
 269
 270  The basic CAN frame structure and the sockaddr structure are defined
 271  in include/linux/can.h:
 272
 273    struct can_frame {
 274            canid_t can_id;  /* 32 bit CAN_ID + EFF/RTR/ERR flags */
 275            __u8    can_dlc; /* data length code: 0 .. 8 */
 276            __u8    data[8] __attribute__((aligned(8)));
 277    };
 278
 279  The alignment of the (linear) payload data[] to a 64bit boundary
 280  allows the user to define own structs and unions to easily access the
 281  CAN payload. There is no given byteorder on the CAN bus by
 282  default. A read(2) system call on a CAN_RAW socket transfers a
 283  struct can_frame to the user space.
 284
 285  The sockaddr_can structure has an interface index like the
 286  PF_PACKET socket, that also binds to a specific interface:
 287
 288    struct sockaddr_can {
 289            sa_family_t can_family;
 290            int         can_ifindex;
 291            union {
 292                    /* transport protocol class address info (e.g. ISOTP) */
 293                    struct { canid_t rx_id, tx_id; } tp;
 294
 295                    /* reserved for future CAN protocols address information */
 296            } can_addr;
 297    };
 298
 299  To determine the interface index an appropriate ioctl() has to
 300  be used (example for CAN_RAW sockets without error checking):
 301
 302    int s;
 303    struct sockaddr_can addr;
 304    struct ifreq ifr;
 305
 306    s = socket(PF_CAN, SOCK_RAW, CAN_RAW);
 307
 308    strcpy(ifr.ifr_name, "can0" );
 309    ioctl(s, SIOCGIFINDEX, &ifr);
 310
 311    addr.can_family = AF_CAN;
 312    addr.can_ifindex = ifr.ifr_ifindex;
 313
 314    bind(s, (struct sockaddr *)&addr, sizeof(addr));
 315
 316    (..)
 317
 318  To bind a socket to all(!) CAN interfaces the interface index must
 319  be 0 (zero). In this case the socket receives CAN frames from every
 320  enabled CAN interface. To determine the originating CAN interface
 321  the system call recvfrom(2) may be used instead of read(2). To send
 322  on a socket that is bound to 'any' interface sendto(2) is needed to
 323  specify the outgoing interface.
 324
 325  Reading CAN frames from a bound CAN_RAW socket (see above) consists
 326  of reading a struct can_frame:
 327
 328    struct can_frame frame;
 329
 330    nbytes = read(s, &frame, sizeof(struct can_frame));
 331
 332    if (nbytes < 0) {
 333            perror("can raw socket read");
 334            return 1;
 335    }
 336
 337    /* paranoid check ... */
 338    if (nbytes < sizeof(struct can_frame)) {
 339            fprintf(stderr, "read: incomplete CAN frame\n");
 340            return 1;
 341    }
 342
 343    /* do something with the received CAN frame */
 344
 345  Writing CAN frames can be done similarly, with the write(2) system call:
 346
 347    nbytes = write(s, &frame, sizeof(struct can_frame));
 348
 349  When the CAN interface is bound to 'any' existing CAN interface
 350  (addr.can_ifindex = 0) it is recommended to use recvfrom(2) if the
 351  information about the originating CAN interface is needed:
 352
 353    struct sockaddr_can addr;
 354    struct ifreq ifr;
 355    socklen_t len = sizeof(addr);
 356    struct can_frame frame;
 357
 358    nbytes = recvfrom(s, &frame, sizeof(struct can_frame),
 359                      0, (struct sockaddr*)&addr, &len);
 360
 361    /* get interface name of the received CAN frame */
 362    ifr.ifr_ifindex = addr.can_ifindex;
 363    ioctl(s, SIOCGIFNAME, &ifr);
 364    printf("Received a CAN frame from interface %s", ifr.ifr_name);
 365
 366  To write CAN frames on sockets bound to 'any' CAN interface the
 367  outgoing interface has to be defined certainly.
 368
 369    strcpy(ifr.ifr_name, "can0");
 370    ioctl(s, SIOCGIFINDEX, &ifr);
 371    addr.can_ifindex = ifr.ifr_ifindex;
 372    addr.can_family  = AF_CAN;
 373
 374    nbytes = sendto(s, &frame, sizeof(struct can_frame),
 375                    0, (struct sockaddr*)&addr, sizeof(addr));
 376
 377  4.1 RAW protocol sockets with can_filters (SOCK_RAW)
 378
 379  Using CAN_RAW sockets is extensively comparable to the commonly
 380  known access to CAN character devices. To meet the new possibilities
 381  provided by the multi user SocketCAN approach, some reasonable
 382  defaults are set at RAW socket binding time:
 383
 384  - The filters are set to exactly one filter receiving everything
 385  - The socket only receives valid data frames (=> no error frames)
 386  - The loopback of sent CAN frames is enabled (see chapter 3.2)
 387  - The socket does not receive its own sent frames (in loopback mode)
 388
 389  These default settings may be changed before or after binding the socket.
 390  To use the referenced definitions of the socket options for CAN_RAW
 391  sockets, include <linux/can/raw.h>.
 392
 393  4.1.1 RAW socket option CAN_RAW_FILTER
 394
 395  The reception of CAN frames using CAN_RAW sockets can be controlled
 396  by defining 0 .. n filters with the CAN_RAW_FILTER socket option.
 397
 398  The CAN filter structure is defined in include/linux/can.h:
 399
 400    struct can_filter {
 401            canid_t can_id;
 402            canid_t can_mask;
 403    };
 404
 405  A filter matches, when
 406
 407    <received_can_id> & mask == can_id & mask
 408
 409  which is analogous to known CAN controllers hardware filter semantics.
 410  The filter can be inverted in this semantic, when the CAN_INV_FILTER
 411  bit is set in can_id element of the can_filter structure. In
 412  contrast to CAN controller hardware filters the user may set 0 .. n
 413  receive filters for each open socket separately:
 414
 415    struct can_filter rfilter[2];
 416
 417    rfilter[0].can_id   = 0x123;
 418    rfilter[0].can_mask = CAN_SFF_MASK;
 419    rfilter[1].can_id   = 0x200;
 420    rfilter[1].can_mask = 0x700;
 421
 422    setsockopt(s, SOL_CAN_RAW, CAN_RAW_FILTER, &rfilter, sizeof(rfilter));
 423
 424  To disable the reception of CAN frames on the selected CAN_RAW socket:
 425
 426    setsockopt(s, SOL_CAN_RAW, CAN_RAW_FILTER, NULL, 0);
 427
 428  To set the filters to zero filters is quite obsolete as not read
 429  data causes the raw socket to discard the received CAN frames. But
 430  having this 'send only' use-case we may remove the receive list in the
 431  Kernel to save a little (really a very little!) CPU usage.
 432
 433  4.1.2 RAW socket option CAN_RAW_ERR_FILTER
 434
 435  As described in chapter 3.4 the CAN interface driver can generate so
 436  called Error Frames that can optionally be passed to the user
 437  application in the same way as other CAN frames. The possible
 438  errors are divided into different error classes that may be filtered
 439  using the appropriate error mask. To register for every possible
 440  error condition CAN_ERR_MASK can be used as value for the error mask.
 441  The values for the error mask are defined in linux/can/error.h .
 442
 443    can_err_mask_t err_mask = ( CAN_ERR_TX_TIMEOUT | CAN_ERR_BUSOFF );
 444
 445    setsockopt(s, SOL_CAN_RAW, CAN_RAW_ERR_FILTER,
 446               &err_mask, sizeof(err_mask));
 447
 448  4.1.3 RAW socket option CAN_RAW_LOOPBACK
 449
 450  To meet multi user needs the local loopback is enabled by default
 451  (see chapter 3.2 for details). But in some embedded use-cases
 452  (e.g. when only one application uses the CAN bus) this loopback
 453  functionality can be disabled (separately for each socket):
 454
 455    int loopback = 0; /* 0 = disabled, 1 = enabled (default) */
 456
 457    setsockopt(s, SOL_CAN_RAW, CAN_RAW_LOOPBACK, &loopback, sizeof(loopback));
 458
 459  4.1.4 RAW socket option CAN_RAW_RECV_OWN_MSGS
 460
 461  When the local loopback is enabled, all the sent CAN frames are
 462  looped back to the open CAN sockets that registered for the CAN
 463  frames' CAN-ID on this given interface to meet the multi user
 464  needs. The reception of the CAN frames on the same socket that was
 465  sending the CAN frame is assumed to be unwanted and therefore
 466  disabled by default. This default behaviour may be changed on
 467  demand:
 468
 469    int recv_own_msgs = 1; /* 0 = disabled (default), 1 = enabled */
 470
 471    setsockopt(s, SOL_CAN_RAW, CAN_RAW_RECV_OWN_MSGS,
 472               &recv_own_msgs, sizeof(recv_own_msgs));
 473
 474  4.2 Broadcast Manager protocol sockets (SOCK_DGRAM)
 475  4.3 connected transport protocols (SOCK_SEQPACKET)
 476  4.4 unconnected transport protocols (SOCK_DGRAM)
 477
 478
 4795. Socket CAN core module
 480-------------------------
 481
 482  The Socket CAN core module implements the protocol family
 483  PF_CAN. CAN protocol modules are loaded by the core module at
 484  runtime. The core module provides an interface for CAN protocol
 485  modules to subscribe needed CAN IDs (see chapter 3.1).
 486
 487  5.1 can.ko module params
 488
 489  - stats_timer: To calculate the Socket CAN core statistics
 490    (e.g. current/maximum frames per second) this 1 second timer is
 491    invoked at can.ko module start time by default. This timer can be
 492    disabled by using stattimer=0 on the module commandline.
 493
 494  - debug: (removed since SocketCAN SVN r546)
 495
 496  5.2 procfs content
 497
 498  As described in chapter 3.1 the Socket CAN core uses several filter
 499  lists to deliver received CAN frames to CAN protocol modules. These
 500  receive lists, their filters and the count of filter matches can be
 501  checked in the appropriate receive list. All entries contain the
 502  device and a protocol module identifier:
 503
 504    foo@bar:~$ cat /proc/net/can/rcvlist_all
 505
 506    receive list 'rx_all':
 507      (vcan3: no entry)
 508      (vcan2: no entry)
 509      (vcan1: no entry)
 510      device   can_id   can_mask  function  userdata   matches  ident
 511       vcan0     000    00000000  f88e6370  f6c6f400         0  raw
 512      (any: no entry)
 513
 514  In this example an application requests any CAN traffic from vcan0.
 515
 516    rcvlist_all - list for unfiltered entries (no filter operations)
 517    rcvlist_eff - list for single extended frame (EFF) entries
 518    rcvlist_err - list for error frames masks
 519    rcvlist_fil - list for mask/value filters
 520    rcvlist_inv - list for mask/value filters (inverse semantic)
 521    rcvlist_sff - list for single standard frame (SFF) entries
 522
 523  Additional procfs files in /proc/net/can
 524
 525    stats       - Socket CAN core statistics (rx/tx frames, match ratios, ...)
 526    reset_stats - manual statistic reset
 527    version     - prints the Socket CAN core version and the ABI version
 528
 529  5.3 writing own CAN protocol modules
 530
 531  To implement a new protocol in the protocol family PF_CAN a new
 532  protocol has to be defined in include/linux/can.h .
 533  The prototypes and definitions to use the Socket CAN core can be
 534  accessed by including include/linux/can/core.h .
 535  In addition to functions that register the CAN protocol and the
 536  CAN device notifier chain there are functions to subscribe CAN
 537  frames received by CAN interfaces and to send CAN frames:
 538
 539    can_rx_register   - subscribe CAN frames from a specific interface
 540    can_rx_unregister - unsubscribe CAN frames from a specific interface
 541    can_send          - transmit a CAN frame (optional with local loopback)
 542
 543  For details see the kerneldoc documentation in net/can/af_can.c or
 544  the source code of net/can/raw.c or net/can/bcm.c .
 545
 5466. CAN network drivers
 547----------------------
 548
 549  Writing a CAN network device driver is much easier than writing a
 550  CAN character device driver. Similar to other known network device
 551  drivers you mainly have to deal with:
 552
 553  - TX: Put the CAN frame from the socket buffer to the CAN controller.
 554  - RX: Put the CAN frame from the CAN controller to the socket buffer.
 555
 556  See e.g. at Documentation/networking/netdevices.txt . The differences
 557  for writing CAN network device driver are described below:
 558
 559  6.1 general settings
 560
 561    dev->type  = ARPHRD_CAN; /* the netdevice hardware type */
 562    dev->flags = IFF_NOARP;  /* CAN has no arp */
 563
 564    dev->mtu   = sizeof(struct can_frame);
 565
 566  The struct can_frame is the payload of each socket buffer in the
 567  protocol family PF_CAN.
 568
 569  6.2 local loopback of sent frames
 570
 571  As described in chapter 3.2 the CAN network device driver should
 572  support a local loopback functionality similar to the local echo
 573  e.g. of tty devices. In this case the driver flag IFF_ECHO has to be
 574  set to prevent the PF_CAN core from locally echoing sent frames
 575  (aka loopback) as fallback solution:
 576
 577    dev->flags = (IFF_NOARP | IFF_ECHO);
 578
 579  6.3 CAN controller hardware filters
 580
 581  To reduce the interrupt load on deep embedded systems some CAN
 582  controllers support the filtering of CAN IDs or ranges of CAN IDs.
 583  These hardware filter capabilities vary from controller to
 584  controller and have to be identified as not feasible in a multi-user
 585  networking approach. The use of the very controller specific
 586  hardware filters could make sense in a very dedicated use-case, as a
 587  filter on driver level would affect all users in the multi-user
 588  system. The high efficient filter sets inside the PF_CAN core allow
 589  to set different multiple filters for each socket separately.
 590  Therefore the use of hardware filters goes to the category 'handmade
 591  tuning on deep embedded systems'. The author is running a MPC603e
 592  @133MHz with four SJA1000 CAN controllers from 2002 under heavy bus
 593  load without any problems ...
 594
 595  6.4 The virtual CAN driver (vcan)
 596
 597  Similar to the network loopback devices, vcan offers a virtual local
 598  CAN interface. A full qualified address on CAN consists of
 599
 600  - a unique CAN Identifier (CAN ID)
 601  - the CAN bus this CAN ID is transmitted on (e.g. can0)
 602
 603  so in common use cases more than one virtual CAN interface is needed.
 604
 605  The virtual CAN interfaces allow the transmission and reception of CAN
 606  frames without real CAN controller hardware. Virtual CAN network
 607  devices are usually named 'vcanX', like vcan0 vcan1 vcan2 ...
 608  When compiled as a module the virtual CAN driver module is called vcan.ko
 609
 610  Since Linux Kernel version 2.6.24 the vcan driver supports the Kernel
 611  netlink interface to create vcan network devices. The creation and
 612  removal of vcan network devices can be managed with the ip(8) tool:
 613
 614  - Create a virtual CAN network interface:
 615       $ ip link add type vcan
 616
 617  - Create a virtual CAN network interface with a specific name 'vcan42':
 618       $ ip link add dev vcan42 type vcan
 619
 620  - Remove a (virtual CAN) network interface 'vcan42':
 621       $ ip link del vcan42
 622
 623  6.5 The CAN network device driver interface
 624
 625  The CAN network device driver interface provides a generic interface
 626  to setup, configure and monitor CAN network devices. The user can then
 627  configure the CAN device, like setting the bit-timing parameters, via
 628  the netlink interface using the program "ip" from the "IPROUTE2"
 629  utility suite. The following chapter describes briefly how to use it.
 630  Furthermore, the interface uses a common data structure and exports a
 631  set of common functions, which all real CAN network device drivers
 632  should use. Please have a look to the SJA1000 or MSCAN driver to
 633  understand how to use them. The name of the module is can-dev.ko.
 634
 635  6.5.1 Netlink interface to set/get devices properties
 636
 637  The CAN device must be configured via netlink interface. The supported
 638  netlink message types are defined and briefly described in
 639  "include/linux/can/netlink.h". CAN link support for the program "ip"
 640  of the IPROUTE2 utility suite is avaiable and it can be used as shown
 641  below:
 642
 643  - Setting CAN device properties:
 644
 645    $ ip link set can0 type can help
 646    Usage: ip link set DEVICE type can
 647        [ bitrate BITRATE [ sample-point SAMPLE-POINT] ] |
 648        [ tq TQ prop-seg PROP_SEG phase-seg1 PHASE-SEG1
 649          phase-seg2 PHASE-SEG2 [ sjw SJW ] ]
 650
 651        [ loopback { on | off } ]
 652        [ listen-only { on | off } ]
 653        [ triple-sampling { on | off } ]
 654
 655        [ restart-ms TIME-MS ]
 656        [ restart ]
 657
 658        Where: BITRATE       := { 1..1000000 }
 659               SAMPLE-POINT  := { 0.000..0.999 }
 660               TQ            := { NUMBER }
 661               PROP-SEG      := { 1..8 }
 662               PHASE-SEG1    := { 1..8 }
 663               PHASE-SEG2    := { 1..8 }
 664               SJW           := { 1..4 }
 665               RESTART-MS    := { 0 | NUMBER }
 666
 667  - Display CAN device details and statistics:
 668
 669    $ ip -details -statistics link show can0
 670    2: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP qlen 10
 671      link/can
 672      can <TRIPLE-SAMPLING> state ERROR-ACTIVE restart-ms 100
 673      bitrate 125000 sample_point 0.875
 674      tq 125 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1
 675      sja1000: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..64 brp-inc 1
 676      clock 8000000
 677      re-started bus-errors arbit-lost error-warn error-pass bus-off
 678      41         17457      0          41         42         41
 679      RX: bytes  packets  errors  dropped overrun mcast
 680      140859     17608    17457   0       0       0
 681      TX: bytes  packets  errors  dropped carrier collsns
 682      861        112      0       41      0       0
 683
 684  More info to the above output:
 685
 686    "<TRIPLE-SAMPLING>"
 687        Shows the list of selected CAN controller modes: LOOPBACK,
 688        LISTEN-ONLY, or TRIPLE-SAMPLING.
 689
 690    "state ERROR-ACTIVE"
 691        The current state of the CAN controller: "ERROR-ACTIVE",
 692        "ERROR-WARNING", "ERROR-PASSIVE", "BUS-OFF" or "STOPPED"
 693
 694    "restart-ms 100"
 695        Automatic restart delay time. If set to a non-zero value, a
 696        restart of the CAN controller will be triggered automatically
 697        in case of a bus-off condition after the specified delay time
 698        in milliseconds. By default it's off.
 699
 700    "bitrate 125000 sample_point 0.875"
 701        Shows the real bit-rate in bits/sec and the sample-point in the
 702        range 0.000..0.999. If the calculation of bit-timing parameters
 703        is enabled in the kernel (CONFIG_CAN_CALC_BITTIMING=y), the
 704        bit-timing can be defined by setting the "bitrate" argument.
 705        Optionally the "sample-point" can be specified. By default it's
 706        0.000 assuming CIA-recommended sample-points.
 707
 708    "tq 125 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1"
 709        Shows the time quanta in ns, propagation segment, phase buffer
 710        segment 1 and 2 and the synchronisation jump width in units of
 711        tq. They allow to define the CAN bit-timing in a hardware
 712        independent format as proposed by the Bosch CAN 2.0 spec (see
 713        chapter 8 of http://www.semiconductors.bosch.de/pdf/can2spec.pdf).
 714
 715    "sja1000: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..64 brp-inc 1
 716     clock 8000000"
 717        Shows the bit-timing constants of the CAN controller, here the
 718        "sja1000". The minimum and maximum values of the time segment 1
 719        and 2, the synchronisation jump width in units of tq, the
 720        bitrate pre-scaler and the CAN system clock frequency in Hz.
 721        These constants could be used for user-defined (non-standard)
 722        bit-timing calculation algorithms in user-space.
 723
 724    "re-started bus-errors arbit-lost error-warn error-pass bus-off"
 725        Shows the number of restarts, bus and arbitration lost errors,
 726        and the state changes to the error-warning, error-passive and
 727        bus-off state. RX overrun errors are listed in the "overrun"
 728        field of the standard network statistics.
 729
 730  6.5.2 Setting the CAN bit-timing
 731
 732  The CAN bit-timing parameters can always be defined in a hardware
 733  independent format as proposed in the Bosch CAN 2.0 specification
 734  specifying the arguments "tq", "prop_seg", "phase_seg1", "phase_seg2"
 735  and "sjw":
 736
 737    $ ip link set canX type can tq 125 prop-seg 6 \
 738                                phase-seg1 7 phase-seg2 2 sjw 1
 739
 740  If the kernel option CONFIG_CAN_CALC_BITTIMING is enabled, CIA
 741  recommended CAN bit-timing parameters will be calculated if the bit-
 742  rate is specified with the argument "bitrate":
 743
 744    $ ip link set canX type can bitrate 125000
 745
 746  Note that this works fine for the most common CAN controllers with
 747  standard bit-rates but may *fail* for exotic bit-rates or CAN system
 748  clock frequencies. Disabling CONFIG_CAN_CALC_BITTIMING saves some
 749  space and allows user-space tools to solely determine and set the
 750  bit-timing parameters. The CAN controller specific bit-timing
 751  constants can be used for that purpose. They are listed by the
 752  following command:
 753
 754    $ ip -details link show can0
 755    ...
 756      sja1000: clock 8000000 tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..64 brp-inc 1
 757
 758  6.5.3 Starting and stopping the CAN network device
 759
 760  A CAN network device is started or stopped as usual with the command
 761  "ifconfig canX up/down" or "ip link set canX up/down". Be aware that
 762  you *must* define proper bit-timing parameters for real CAN devices
 763  before you can start it to avoid error-prone default settings:
 764
 765    $ ip link set canX up type can bitrate 125000
 766
 767  A device may enter the "bus-off" state if too much errors occurred on
 768  the CAN bus. Then no more messages are received or sent. An automatic
 769  bus-off recovery can be enabled by setting the "restart-ms" to a
 770  non-zero value, e.g.:
 771
 772    $ ip link set canX type can restart-ms 100
 773
 774  Alternatively, the application may realize the "bus-off" condition
 775  by monitoring CAN error frames and do a restart when appropriate with
 776  the command:
 777
 778    $ ip link set canX type can restart
 779
 780  Note that a restart will also create a CAN error frame (see also
 781  chapter 3.4).
 782
 783  6.6 Supported CAN hardware
 784
 785  Please check the "Kconfig" file in "drivers/net/can" to get an actual
 786  list of the support CAN hardware. On the Socket CAN project website
 787  (see chapter 7) there might be further drivers available, also for
 788  older kernel versions.
 789
 7907. Socket CAN resources
 791-----------------------
 792
 793  You can find further resources for Socket CAN like user space tools,
 794  support for old kernel versions, more drivers, mailing lists, etc.
 795  at the BerliOS OSS project website for Socket CAN:
 796
 797    http://developer.berlios.de/projects/socketcan
 798
 799  If you have questions, bug fixes, etc., don't hesitate to post them to
 800  the Socketcan-Users mailing list. But please search the archives first.
 801
 8028. Credits
 803----------
 804
 805  Oliver Hartkopp (PF_CAN core, filters, drivers, bcm, SJA1000 driver)
 806  Urs Thuermann (PF_CAN core, kernel integration, socket interfaces, raw, vcan)
 807  Jan Kizka (RT-SocketCAN core, Socket-API reconciliation)
 808  Wolfgang Grandegger (RT-SocketCAN core & drivers, Raw Socket-API reviews,
 809                       CAN device driver interface, MSCAN driver)
 810  Robert Schwebel (design reviews, PTXdist integration)
 811  Marc Kleine-Budde (design reviews, Kernel 2.6 cleanups, drivers)
 812  Benedikt Spranger (reviews)
 813  Thomas Gleixner (LKML reviews, coding style, posting hints)
 814  Andrey Volkov (kernel subtree structure, ioctls, MSCAN driver)
 815  Matthias Brukner (first SJA1000 CAN netdevice implementation Q2/2003)
 816  Klaus Hitschler (PEAK driver integration)
 817  Uwe Koppe (CAN netdevices with PF_PACKET approach)
 818  Michael Schulze (driver layer loopback requirement, RT CAN drivers review)
 819  Pavel Pisa (Bit-timing calculation)
 820  Sascha Hauer (SJA1000 platform driver)
 821  Sebastian Haas (SJA1000 EMS PCI driver)
 822  Markus Plessing (SJA1000 EMS PCI driver)
 823  Per Dalen (SJA1000 Kvaser PCI driver)
 824  Sam Ravnborg (reviews, coding style, kbuild help)
 825
lxr.linux.no kindly hosted by Redpill Linpro AS, provider of Linux consulting and operations services since 1995.