74 lines
		
	
	
		
			3.0 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
		
		
			
		
	
	
			74 lines
		
	
	
		
			3.0 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
| 
								 | 
							
								# SPDX-License-Identifier: GPL-2.0-only
							 | 
						||
| 
								 | 
							
								#
							 | 
						||
| 
								 | 
							
								# Controller Area Network (CAN) network layer core configuration
							 | 
						||
| 
								 | 
							
								#
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								menuconfig CAN
							 | 
						||
| 
								 | 
							
									tristate "CAN bus subsystem support"
							 | 
						||
| 
								 | 
							
									help
							 | 
						||
| 
								 | 
							
									  Controller Area Network (CAN) is a slow (up to 1Mbit/s) serial
							 | 
						||
| 
								 | 
							
									  communications protocol. Development of the CAN bus started in
							 | 
						||
| 
								 | 
							
									  1983 at Robert Bosch GmbH, and the protocol was officially
							 | 
						||
| 
								 | 
							
									  released in 1986. The CAN bus was originally mainly for automotive,
							 | 
						||
| 
								 | 
							
									  but is now widely used in marine (NMEA2000), industrial, and medical
							 | 
						||
| 
								 | 
							
									  applications. More information on the CAN network protocol family
							 | 
						||
| 
								 | 
							
									  PF_CAN is contained in <Documentation/networking/can.rst>.
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
									  If you want CAN support you should say Y here and also to the
							 | 
						||
| 
								 | 
							
									  specific driver for your controller(s) under the Network device
							 | 
						||
| 
								 | 
							
									  support section.
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								if CAN
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								config CAN_RAW
							 | 
						||
| 
								 | 
							
									tristate "Raw CAN Protocol (raw access with CAN-ID filtering)"
							 | 
						||
| 
								 | 
							
									default y
							 | 
						||
| 
								 | 
							
									help
							 | 
						||
| 
								 | 
							
									  The raw CAN protocol option offers access to the CAN bus via
							 | 
						||
| 
								 | 
							
									  the BSD socket API. You probably want to use the raw socket in
							 | 
						||
| 
								 | 
							
									  most cases where no higher level protocol is being used. The raw
							 | 
						||
| 
								 | 
							
									  socket has several filter options e.g. ID masking / error frames.
							 | 
						||
| 
								 | 
							
									  To receive/send raw CAN messages, use AF_CAN with protocol CAN_RAW.
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								config CAN_BCM
							 | 
						||
| 
								 | 
							
									tristate "Broadcast Manager CAN Protocol (with content filtering)"
							 | 
						||
| 
								 | 
							
									default y
							 | 
						||
| 
								 | 
							
									help
							 | 
						||
| 
								 | 
							
									  The Broadcast Manager offers content filtering, timeout monitoring,
							 | 
						||
| 
								 | 
							
									  sending of RTR frames, and cyclic CAN messages without permanent user
							 | 
						||
| 
								 | 
							
									  interaction. The BCM can be 'programmed' via the BSD socket API and
							 | 
						||
| 
								 | 
							
									  informs you on demand e.g. only on content updates / timeouts.
							 | 
						||
| 
								 | 
							
									  You probably want to use the bcm socket in most cases where cyclic
							 | 
						||
| 
								 | 
							
									  CAN messages are used on the bus (e.g. in automotive environments).
							 | 
						||
| 
								 | 
							
									  To use the Broadcast Manager, use AF_CAN with protocol CAN_BCM.
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								config CAN_GW
							 | 
						||
| 
								 | 
							
									tristate "CAN Gateway/Router (with netlink configuration)"
							 | 
						||
| 
								 | 
							
									default y
							 | 
						||
| 
								 | 
							
									help
							 | 
						||
| 
								 | 
							
									  The CAN Gateway/Router is used to route (and modify) CAN frames.
							 | 
						||
| 
								 | 
							
									  It is based on the PF_CAN core infrastructure for msg filtering and
							 | 
						||
| 
								 | 
							
									  msg sending and can optionally modify routed CAN frames on the fly.
							 | 
						||
| 
								 | 
							
									  CAN frames can be routed between CAN network interfaces (one hop).
							 | 
						||
| 
								 | 
							
									  They can be modified with AND/OR/XOR/SET operations as configured
							 | 
						||
| 
								 | 
							
									  by the netlink configuration interface known e.g. from iptables.
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								source "net/can/j1939/Kconfig"
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								config CAN_ISOTP
							 | 
						||
| 
								 | 
							
									tristate "ISO 15765-2:2016 CAN transport protocol"
							 | 
						||
| 
								 | 
							
									help
							 | 
						||
| 
								 | 
							
									  CAN Transport Protocols offer support for segmented Point-to-Point
							 | 
						||
| 
								 | 
							
									  communication between CAN nodes via two defined CAN Identifiers.
							 | 
						||
| 
								 | 
							
									  As CAN frames can only transport a small amount of data bytes
							 | 
						||
| 
								 | 
							
									  (max. 8 bytes for 'classic' CAN and max. 64 bytes for CAN FD) this
							 | 
						||
| 
								 | 
							
									  segmentation is needed to transport longer Protocol Data Units (PDU)
							 | 
						||
| 
								 | 
							
									  as needed e.g. for vehicle diagnosis (UDS, ISO 14229) or IP-over-CAN
							 | 
						||
| 
								 | 
							
									  traffic.
							 | 
						||
| 
								 | 
							
									  This protocol driver implements data transfers according to
							 | 
						||
| 
								 | 
							
									  ISO 15765-2:2016 for 'classic' CAN and CAN FD frame types.
							 | 
						||
| 
								 | 
							
									  If you want to perform automotive vehicle diagnostic services (UDS),
							 | 
						||
| 
								 | 
							
									  say 'y'.
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								endif
							 |