diff options
author | John Whitmore <johnfwhitmore@gmail.com> | 2013-12-06 07:49:08 -0500 |
---|---|---|
committer | Marc Kleine-Budde <mkl@pengutronix.de> | 2013-12-17 05:47:20 -0500 |
commit | f35f6c8f74a085c1ed810d642a0c27b38d54e890 (patch) | |
tree | e82ce31d6e5b66cf6dfaf22ded11ab60d2c16723 | |
parent | 4ce78a838c1c5482aeb47cfba9baf9df90400a25 (diff) |
can: update MAINTAINERS and Documentation
Changed MAINTAINERS file to add Documentation/networking/can.txt to the list of
maintained files.
can.txt:
- Globally changed Socket CAN to SocketCAN
- Removed section 3.3 from the document
- Updated Section 7
- Corrected a few simple typos
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: John Whitmore <johnfwhitmore@gmail.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-rw-r--r-- | Documentation/networking/can.txt | 94 | ||||
-rw-r--r-- | MAINTAINERS | 1 |
2 files changed, 38 insertions, 57 deletions
diff --git a/Documentation/networking/can.txt b/Documentation/networking/can.txt index 4c072414eadb..f3089d423515 100644 --- a/Documentation/networking/can.txt +++ b/Documentation/networking/can.txt | |||
@@ -2,21 +2,20 @@ | |||
2 | 2 | ||
3 | can.txt | 3 | can.txt |
4 | 4 | ||
5 | Readme file for the Controller Area Network Protocol Family (aka Socket CAN) | 5 | Readme file for the Controller Area Network Protocol Family (aka SocketCAN) |
6 | 6 | ||
7 | This file contains | 7 | This file contains |
8 | 8 | ||
9 | 1 Overview / What is Socket CAN | 9 | 1 Overview / What is SocketCAN |
10 | 10 | ||
11 | 2 Motivation / Why using the socket API | 11 | 2 Motivation / Why using the socket API |
12 | 12 | ||
13 | 3 Socket CAN concept | 13 | 3 SocketCAN concept |
14 | 3.1 receive lists | 14 | 3.1 receive lists |
15 | 3.2 local loopback of sent frames | 15 | 3.2 local loopback of sent frames |
16 | 3.3 network security issues (capabilities) | 16 | 3.3 network problem notifications |
17 | 3.4 network problem notifications | ||
18 | 17 | ||
19 | 4 How to use Socket CAN | 18 | 4 How to use SocketCAN |
20 | 4.1 RAW protocol sockets with can_filters (SOCK_RAW) | 19 | 4.1 RAW protocol sockets with can_filters (SOCK_RAW) |
21 | 4.1.1 RAW socket option CAN_RAW_FILTER | 20 | 4.1.1 RAW socket option CAN_RAW_FILTER |
22 | 4.1.2 RAW socket option CAN_RAW_ERR_FILTER | 21 | 4.1.2 RAW socket option CAN_RAW_ERR_FILTER |
@@ -34,7 +33,7 @@ This file contains | |||
34 | 4.3 connected transport protocols (SOCK_SEQPACKET) | 33 | 4.3 connected transport protocols (SOCK_SEQPACKET) |
35 | 4.4 unconnected transport protocols (SOCK_DGRAM) | 34 | 4.4 unconnected transport protocols (SOCK_DGRAM) |
36 | 35 | ||
37 | 5 Socket CAN core module | 36 | 5 SocketCAN core module |
38 | 5.1 can.ko module params | 37 | 5.1 can.ko module params |
39 | 5.2 procfs content | 38 | 5.2 procfs content |
40 | 5.3 writing own CAN protocol modules | 39 | 5.3 writing own CAN protocol modules |
@@ -51,20 +50,20 @@ This file contains | |||
51 | 6.6 CAN FD (flexible data rate) driver support | 50 | 6.6 CAN FD (flexible data rate) driver support |
52 | 6.7 supported CAN hardware | 51 | 6.7 supported CAN hardware |
53 | 52 | ||
54 | 7 Socket CAN resources | 53 | 7 SocketCAN resources |
55 | 54 | ||
56 | 8 Credits | 55 | 8 Credits |
57 | 56 | ||
58 | ============================================================================ | 57 | ============================================================================ |
59 | 58 | ||
60 | 1. Overview / What is Socket CAN | 59 | 1. Overview / What is SocketCAN |
61 | -------------------------------- | 60 | -------------------------------- |
62 | 61 | ||
63 | The socketcan package is an implementation of CAN protocols | 62 | The socketcan package is an implementation of CAN protocols |
64 | (Controller Area Network) for Linux. CAN is a networking technology | 63 | (Controller Area Network) for Linux. CAN is a networking technology |
65 | which has widespread use in automation, embedded devices, and | 64 | which has widespread use in automation, embedded devices, and |
66 | automotive fields. While there have been other CAN implementations | 65 | automotive fields. While there have been other CAN implementations |
67 | for Linux based on character devices, Socket CAN uses the Berkeley | 66 | for Linux based on character devices, SocketCAN uses the Berkeley |
68 | socket API, the Linux network stack and implements the CAN device | 67 | socket API, the Linux network stack and implements the CAN device |
69 | drivers as network interfaces. The CAN socket API has been designed | 68 | drivers as network interfaces. The CAN socket API has been designed |
70 | as similar as possible to the TCP/IP protocols to allow programmers, | 69 | as similar as possible to the TCP/IP protocols to allow programmers, |
@@ -74,7 +73,7 @@ sockets. | |||
74 | 2. Motivation / Why using the socket API | 73 | 2. Motivation / Why using the socket API |
75 | ---------------------------------------- | 74 | ---------------------------------------- |
76 | 75 | ||
77 | There have been CAN implementations for Linux before Socket CAN so the | 76 | There have been CAN implementations for Linux before SocketCAN so the |
78 | question arises, why we have started another project. Most existing | 77 | question arises, why we have started another project. Most existing |
79 | implementations come as a device driver for some CAN hardware, they | 78 | implementations come as a device driver for some CAN hardware, they |
80 | are based on character devices and provide comparatively little | 79 | are based on character devices and provide comparatively little |
@@ -89,10 +88,10 @@ the CAN controller requires employment of another device driver and | |||
89 | often the need for adaption of large parts of the application to the | 88 | often the need for adaption of large parts of the application to the |
90 | new driver's API. | 89 | new driver's API. |
91 | 90 | ||
92 | Socket CAN was designed to overcome all of these limitations. A new | 91 | SocketCAN was designed to overcome all of these limitations. A new |
93 | protocol family has been implemented which provides a socket interface | 92 | protocol family has been implemented which provides a socket interface |
94 | to user space applications and which builds upon the Linux network | 93 | to user space applications and which builds upon the Linux network |
95 | layer, so to use all of the provided queueing functionality. A device | 94 | layer, enabling use all of the provided queueing functionality. A device |
96 | driver for CAN controller hardware registers itself with the Linux | 95 | driver for CAN controller hardware registers itself with the Linux |
97 | network layer as a network device, so that CAN frames from the | 96 | network layer as a network device, so that CAN frames from the |
98 | controller can be passed up to the network layer and on to the CAN | 97 | controller can be passed up to the network layer and on to the CAN |
@@ -146,15 +145,15 @@ solution for a couple of reasons: | |||
146 | providing an API for device drivers to register with. However, then | 145 | providing an API for device drivers to register with. However, then |
147 | it would be no more difficult, or may be even easier, to use the | 146 | it would be no more difficult, or may be even easier, to use the |
148 | networking framework provided by the Linux kernel, and this is what | 147 | networking framework provided by the Linux kernel, and this is what |
149 | Socket CAN does. | 148 | SocketCAN does. |
150 | 149 | ||
151 | The use of the networking framework of the Linux kernel is just the | 150 | The use of the networking framework of the Linux kernel is just the |
152 | natural and most appropriate way to implement CAN for Linux. | 151 | natural and most appropriate way to implement CAN for Linux. |
153 | 152 | ||
154 | 3. Socket CAN concept | 153 | 3. SocketCAN concept |
155 | --------------------- | 154 | --------------------- |
156 | 155 | ||
157 | As described in chapter 2 it is the main goal of Socket CAN to | 156 | As described in chapter 2 it is the main goal of SocketCAN to |
158 | provide a socket interface to user space applications which builds | 157 | provide a socket interface to user space applications which builds |
159 | upon the Linux network layer. In contrast to the commonly known | 158 | upon the Linux network layer. In contrast to the commonly known |
160 | TCP/IP and ethernet networking, the CAN bus is a broadcast-only(!) | 159 | TCP/IP and ethernet networking, the CAN bus is a broadcast-only(!) |
@@ -168,11 +167,11 @@ solution for a couple of reasons: | |||
168 | 167 | ||
169 | The network transparent access of multiple applications leads to the | 168 | The network transparent access of multiple applications leads to the |
170 | problem that different applications may be interested in the same | 169 | problem that different applications may be interested in the same |
171 | CAN-IDs from the same CAN network interface. The Socket CAN core | 170 | CAN-IDs from the same CAN network interface. The SocketCAN core |
172 | module - which implements the protocol family CAN - provides several | 171 | module - which implements the protocol family CAN - provides several |
173 | high efficient receive lists for this reason. If e.g. a user space | 172 | high efficient receive lists for this reason. If e.g. a user space |
174 | application opens a CAN RAW socket, the raw protocol module itself | 173 | application opens a CAN RAW socket, the raw protocol module itself |
175 | requests the (range of) CAN-IDs from the Socket CAN core that are | 174 | requests the (range of) CAN-IDs from the SocketCAN core that are |
176 | requested by the user. The subscription and unsubscription of | 175 | requested by the user. The subscription and unsubscription of |
177 | CAN-IDs can be done for specific CAN interfaces or for all(!) known | 176 | CAN-IDs can be done for specific CAN interfaces or for all(!) known |
178 | CAN interfaces with the can_rx_(un)register() functions provided to | 177 | CAN interfaces with the can_rx_(un)register() functions provided to |
@@ -217,21 +216,7 @@ solution for a couple of reasons: | |||
217 | * = you really like to have this when you're running analyser tools | 216 | * = you really like to have this when you're running analyser tools |
218 | like 'candump' or 'cansniffer' on the (same) node. | 217 | like 'candump' or 'cansniffer' on the (same) node. |
219 | 218 | ||
220 | 3.3 network security issues (capabilities) | 219 | 3.3 network problem notifications |
221 | |||
222 | The Controller Area Network is a local field bus transmitting only | ||
223 | broadcast messages without any routing and security concepts. | ||
224 | In the majority of cases the user application has to deal with | ||
225 | raw CAN frames. Therefore it might be reasonable NOT to restrict | ||
226 | the CAN access only to the user root, as known from other networks. | ||
227 | Since the currently implemented CAN_RAW and CAN_BCM sockets can only | ||
228 | send and receive frames to/from CAN interfaces it does not affect | ||
229 | security of others networks to allow all users to access the CAN. | ||
230 | To enable non-root users to access CAN_RAW and CAN_BCM protocol | ||
231 | sockets the Kconfig options CAN_RAW_USER and/or CAN_BCM_USER may be | ||
232 | selected at kernel compile time. | ||
233 | |||
234 | 3.4 network problem notifications | ||
235 | 220 | ||
236 | The use of the CAN bus may lead to several problems on the physical | 221 | The use of the CAN bus may lead to several problems on the physical |
237 | and media access control layer. Detecting and logging of these lower | 222 | and media access control layer. Detecting and logging of these lower |
@@ -251,11 +236,11 @@ solution for a couple of reasons: | |||
251 | by default. The format of the CAN error message frame is briefly | 236 | by default. The format of the CAN error message frame is briefly |
252 | described in the Linux header file "include/linux/can/error.h". | 237 | described in the Linux header file "include/linux/can/error.h". |
253 | 238 | ||
254 | 4. How to use Socket CAN | 239 | 4. How to use SocketCAN |
255 | ------------------------ | 240 | ------------------------ |
256 | 241 | ||
257 | Like TCP/IP, you first need to open a socket for communicating over a | 242 | 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 | 243 | CAN network. Since SocketCAN implements a new protocol family, you |
259 | need to pass PF_CAN as the first argument to the socket(2) system | 244 | 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 | 245 | 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, | 246 | socket protocol and the broadcast manager (BCM). So to open a socket, |
@@ -286,8 +271,8 @@ solution for a couple of reasons: | |||
286 | }; | 271 | }; |
287 | 272 | ||
288 | The alignment of the (linear) payload data[] to a 64bit boundary | 273 | 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 | 274 | allows the user to define their own structs and unions to easily access |
290 | CAN payload. There is no given byteorder on the CAN bus by | 275 | the 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 | 276 | default. A read(2) system call on a CAN_RAW socket transfers a |
292 | struct can_frame to the user space. | 277 | struct can_frame to the user space. |
293 | 278 | ||
@@ -479,7 +464,7 @@ solution for a couple of reasons: | |||
479 | 464 | ||
480 | setsockopt(s, SOL_CAN_RAW, CAN_RAW_FILTER, NULL, 0); | 465 | setsockopt(s, SOL_CAN_RAW, CAN_RAW_FILTER, NULL, 0); |
481 | 466 | ||
482 | To set the filters to zero filters is quite obsolete as not read | 467 | To set the filters to zero filters is quite obsolete as to not read |
483 | data causes the raw socket to discard the received CAN frames. But | 468 | data causes the raw socket to discard the received CAN frames. But |
484 | having this 'send only' use-case we may remove the receive list in the | 469 | having this 'send only' use-case we may remove the receive list in the |
485 | Kernel to save a little (really a very little!) CPU usage. | 470 | Kernel to save a little (really a very little!) CPU usage. |
@@ -814,17 +799,17 @@ solution for a couple of reasons: | |||
814 | 4.4 unconnected transport protocols (SOCK_DGRAM) | 799 | 4.4 unconnected transport protocols (SOCK_DGRAM) |
815 | 800 | ||
816 | 801 | ||
817 | 5. Socket CAN core module | 802 | 5. SocketCAN core module |
818 | ------------------------- | 803 | ------------------------- |
819 | 804 | ||
820 | The Socket CAN core module implements the protocol family | 805 | The SocketCAN core module implements the protocol family |
821 | PF_CAN. CAN protocol modules are loaded by the core module at | 806 | PF_CAN. CAN protocol modules are loaded by the core module at |
822 | runtime. The core module provides an interface for CAN protocol | 807 | runtime. The core module provides an interface for CAN protocol |
823 | modules to subscribe needed CAN IDs (see chapter 3.1). | 808 | modules to subscribe needed CAN IDs (see chapter 3.1). |
824 | 809 | ||
825 | 5.1 can.ko module params | 810 | 5.1 can.ko module params |
826 | 811 | ||
827 | - stats_timer: To calculate the Socket CAN core statistics | 812 | - stats_timer: To calculate the SocketCAN core statistics |
828 | (e.g. current/maximum frames per second) this 1 second timer is | 813 | (e.g. current/maximum frames per second) this 1 second timer is |
829 | invoked at can.ko module start time by default. This timer can be | 814 | invoked at can.ko module start time by default. This timer can be |
830 | disabled by using stattimer=0 on the module commandline. | 815 | disabled by using stattimer=0 on the module commandline. |
@@ -833,7 +818,7 @@ solution for a couple of reasons: | |||
833 | 818 | ||
834 | 5.2 procfs content | 819 | 5.2 procfs content |
835 | 820 | ||
836 | As described in chapter 3.1 the Socket CAN core uses several filter | 821 | As described in chapter 3.1 the SocketCAN core uses several filter |
837 | lists to deliver received CAN frames to CAN protocol modules. These | 822 | lists to deliver received CAN frames to CAN protocol modules. These |
838 | receive lists, their filters and the count of filter matches can be | 823 | receive lists, their filters and the count of filter matches can be |
839 | checked in the appropriate receive list. All entries contain the | 824 | checked in the appropriate receive list. All entries contain the |
@@ -860,15 +845,15 @@ solution for a couple of reasons: | |||
860 | 845 | ||
861 | Additional procfs files in /proc/net/can | 846 | Additional procfs files in /proc/net/can |
862 | 847 | ||
863 | stats - Socket CAN core statistics (rx/tx frames, match ratios, ...) | 848 | stats - SocketCAN core statistics (rx/tx frames, match ratios, ...) |
864 | reset_stats - manual statistic reset | 849 | reset_stats - manual statistic reset |
865 | version - prints the Socket CAN core version and the ABI version | 850 | version - prints the SocketCAN core version and the ABI version |
866 | 851 | ||
867 | 5.3 writing own CAN protocol modules | 852 | 5.3 writing own CAN protocol modules |
868 | 853 | ||
869 | To implement a new protocol in the protocol family PF_CAN a new | 854 | To implement a new protocol in the protocol family PF_CAN a new |
870 | protocol has to be defined in include/linux/can.h . | 855 | protocol has to be defined in include/linux/can.h . |
871 | The prototypes and definitions to use the Socket CAN core can be | 856 | The prototypes and definitions to use the SocketCAN core can be |
872 | accessed by including include/linux/can/core.h . | 857 | accessed by including include/linux/can/core.h . |
873 | In addition to functions that register the CAN protocol and the | 858 | In addition to functions that register the CAN protocol and the |
874 | CAN device notifier chain there are functions to subscribe CAN | 859 | CAN device notifier chain there are functions to subscribe CAN |
@@ -1105,7 +1090,7 @@ solution for a couple of reasons: | |||
1105 | 1090 | ||
1106 | $ ip link set canX up type can bitrate 125000 | 1091 | $ ip link set canX up type can bitrate 125000 |
1107 | 1092 | ||
1108 | A device may enter the "bus-off" state if too much errors occurred on | 1093 | A device may enter the "bus-off" state if too many errors occurred on |
1109 | the CAN bus. Then no more messages are received or sent. An automatic | 1094 | the CAN bus. Then no more messages are received or sent. An automatic |
1110 | bus-off recovery can be enabled by setting the "restart-ms" to a | 1095 | bus-off recovery can be enabled by setting the "restart-ms" to a |
1111 | non-zero value, e.g.: | 1096 | non-zero value, e.g.: |
@@ -1125,7 +1110,7 @@ solution for a couple of reasons: | |||
1125 | 1110 | ||
1126 | CAN FD capable CAN controllers support two different bitrates for the | 1111 | CAN FD capable CAN controllers support two different bitrates for the |
1127 | arbitration phase and the payload phase of the CAN FD frame. Therefore a | 1112 | arbitration phase and the payload phase of the CAN FD frame. Therefore a |
1128 | second bittiming has to be specified in order to enable the CAN FD bitrate. | 1113 | second bit timing has to be specified in order to enable the CAN FD bitrate. |
1129 | 1114 | ||
1130 | Additionally CAN FD capable CAN controllers support up to 64 bytes of | 1115 | Additionally CAN FD capable CAN controllers support up to 64 bytes of |
1131 | payload. The representation of this length in can_frame.can_dlc and | 1116 | payload. The representation of this length in can_frame.can_dlc and |
@@ -1150,21 +1135,16 @@ solution for a couple of reasons: | |||
1150 | 6.7 Supported CAN hardware | 1135 | 6.7 Supported CAN hardware |
1151 | 1136 | ||
1152 | Please check the "Kconfig" file in "drivers/net/can" to get an actual | 1137 | Please check the "Kconfig" file in "drivers/net/can" to get an actual |
1153 | list of the support CAN hardware. On the Socket CAN project website | 1138 | list of the support CAN hardware. On the SocketCAN project website |
1154 | (see chapter 7) there might be further drivers available, also for | 1139 | (see chapter 7) there might be further drivers available, also for |
1155 | older kernel versions. | 1140 | older kernel versions. |
1156 | 1141 | ||
1157 | 7. Socket CAN resources | 1142 | 7. SocketCAN resources |
1158 | ----------------------- | 1143 | ----------------------- |
1159 | 1144 | ||
1160 | You can find further resources for Socket CAN like user space tools, | 1145 | The Linux CAN / SocketCAN project ressources (project site / mailing list) |
1161 | support for old kernel versions, more drivers, mailing lists, etc. | 1146 | are referenced in the MAINTAINERS file in the Linux source tree. |
1162 | at the BerliOS OSS project website for Socket CAN: | 1147 | Search for CAN NETWORK [LAYERS|DRIVERS]. |
1163 | |||
1164 | http://developer.berlios.de/projects/socketcan | ||
1165 | |||
1166 | If you have questions, bug fixes, etc., don't hesitate to post them to | ||
1167 | the Socketcan-Users mailing list. But please search the archives first. | ||
1168 | 1148 | ||
1169 | 8. Credits | 1149 | 8. Credits |
1170 | ---------- | 1150 | ---------- |
diff --git a/MAINTAINERS b/MAINTAINERS index 63ae89617fc5..3d2ac86b0115 100644 --- a/MAINTAINERS +++ b/MAINTAINERS | |||
@@ -2012,6 +2012,7 @@ L: linux-can@vger.kernel.org | |||
2012 | W: http://gitorious.org/linux-can | 2012 | W: http://gitorious.org/linux-can |
2013 | T: git git://gitorious.org/linux-can/linux-can-next.git | 2013 | T: git git://gitorious.org/linux-can/linux-can-next.git |
2014 | S: Maintained | 2014 | S: Maintained |
2015 | F: Documentation/networking/can.txt | ||
2015 | F: net/can/ | 2016 | F: net/can/ |
2016 | F: include/linux/can/core.h | 2017 | F: include/linux/can/core.h |
2017 | F: include/uapi/linux/can.h | 2018 | F: include/uapi/linux/can.h |