lael-labs/linux

Documentation/devicetree/bindings/i2c/i2c-mux-gpmux.txt+1−1

@@ -42,7 +42,7 @@ Optional properties: · 41 unmodified lines
42	This means that no unrelated I2C transactions are allowed on the parent I2C	42	This means that no unrelated I2C transactions are allowed on the parent I2C
43	adapter for the complete multiplexed I2C transaction.	43	adapter for the complete multiplexed I2C transaction.
44	The properties of mux-locked and parent-locked multiplexers are discussed	44	The properties of mux-locked and parent-locked multiplexers are discussed
45	in more detail in Documentation/i2c/i2c-topology.	45	in more detail in Documentation/i2c/i2c-topology.rst.
46		46
47	For each i2c child node, an I2C child bus will be created. They will	47	For each i2c child node, an I2C child bus will be created. They will
48	be numbered based on their order in the device tree.	48	be numbered based on their order in the device tree.

Documentation/driver-api/ipmb.rst+1−1

@@ -83,7 +83,7 @@ Instantiate the device · 82 unmodified lines
83	----------------------	83	----------------------
84		84
85	After loading the driver, you can instantiate the device as	85	After loading the driver, you can instantiate the device as
86	described in 'Documentation/i2c/instantiating-devices'.	86	described in 'Documentation/i2c/instantiating-devices.rst'.
87	If you have multiple BMCs, each connected to your Satellite MC via	87	If you have multiple BMCs, each connected to your Satellite MC via
88	a different I2C bus, you can instantiate a device for each of	88	a different I2C bus, you can instantiate a device for each of
89	those BMCs.	89	those BMCs.

Documentation/hwmon/adm1021.rst+1−1

@@ -142,7 +142,7 @@ loading the adm1021 module, then things are good. · 141 unmodified lines
142	If nothing happens when loading the adm1021 module, and you are certain	142	If nothing happens when loading the adm1021 module, and you are certain
143	that your specific Xeon processor model includes compatible sensors, you	143	that your specific Xeon processor model includes compatible sensors, you
144	will have to explicitly instantiate the sensor chips from user-space. See	144	will have to explicitly instantiate the sensor chips from user-space. See
145	method 4 in Documentation/i2c/instantiating-devices. Possible slave	145	method 4 in Documentation/i2c/instantiating-devices.rst. Possible slave
146	addresses are 0x18, 0x1a, 0x29, 0x2b, 0x4c, or 0x4e. It is likely that	146	addresses are 0x18, 0x1a, 0x29, 0x2b, 0x4c, or 0x4e. It is likely that
147	only temp2 will be correct and temp1 will have to be ignored.	147	only temp2 will be correct and temp1 will have to be ignored.
148		148

Documentation/hwmon/adm1275.rst+1−1

@@ -75,7 +75,7 @@ Usage Notes · 74 unmodified lines
75	-----------	75	-----------
76		76
77	This driver does not auto-detect devices. You will have to instantiate the	77	This driver does not auto-detect devices. You will have to instantiate the
78	devices explicitly. Please see Documentation/i2c/instantiating-devices for	78	devices explicitly. Please see Documentation/i2c/instantiating-devices.rst for
79	details.	79	details.
80		80
81	The ADM1075, unlike many other PMBus devices, does not support internal voltage	81	The ADM1075, unlike many other PMBus devices, does not support internal voltage

Documentation/hwmon/hih6130.rst+1−1

@@ -27,7 +27,7 @@ The devices communicate with the I2C protocol. All sensors are set to the same · 26 unmodified lines
27	I2C address 0x27 by default, so an entry with I2C_BOARD_INFO("hih6130", 0x27)	27	I2C address 0x27 by default, so an entry with I2C_BOARD_INFO("hih6130", 0x27)
28	can be used in the board setup code.	28	can be used in the board setup code.
29		29
30	Please see Documentation/i2c/instantiating-devices for details on how to	30	Please see Documentation/i2c/instantiating-devices.rst for details on how to
31	instantiate I2C devices.	31	instantiate I2C devices.
32		32
33	sysfs-Interface	33	sysfs-Interface

Documentation/hwmon/ibm-cffps.rst+1−1

@@ -17,7 +17,7 @@ Usage Notes · 16 unmodified lines
17	-----------	17	-----------
18		18
19	This driver does not auto-detect devices. You will have to instantiate the	19	This driver does not auto-detect devices. You will have to instantiate the
20	devices explicitly. Please see Documentation/i2c/instantiating-devices for	20	devices explicitly. Please see Documentation/i2c/instantiating-devices.rst for
21	details.	21	details.
22		22
23	Sysfs entries	23	Sysfs entries

Documentation/hwmon/lm25066.rst+1−1

@@ -76,7 +76,7 @@ Usage Notes · 75 unmodified lines
76	-----------	76	-----------
77		77
78	This driver does not auto-detect devices. You will have to instantiate the	78	This driver does not auto-detect devices. You will have to instantiate the
79	devices explicitly. Please see Documentation/i2c/instantiating-devices for	79	devices explicitly. Please see Documentation/i2c/instantiating-devices.rst for
80	details.	80	details.
81		81
82		82

Documentation/hwmon/max16064.rst+1−1

@@ -28,7 +28,7 @@ Usage Notes · 27 unmodified lines
28	-----------	28	-----------
29		29
30	This driver does not auto-detect devices. You will have to instantiate the	30	This driver does not auto-detect devices. You will have to instantiate the
31	devices explicitly. Please see Documentation/i2c/instantiating-devices for	31	devices explicitly. Please see Documentation/i2c/instantiating-devices.rst for
32	details.	32	details.
33		33
34		34

Documentation/hwmon/max16065.rst+1−1

@@ -79,7 +79,7 @@ Usage Notes · 78 unmodified lines
79		79
80	This driver does not probe for devices, since there is no register which	80	This driver does not probe for devices, since there is no register which
81	can be safely used to identify the chip. You will have to instantiate	81	can be safely used to identify the chip. You will have to instantiate
82	the devices explicitly. Please see Documentation/i2c/instantiating-devices for	82	the devices explicitly. Please see Documentation/i2c/instantiating-devices.rst for
83	details.	83	details.
84		84
85	WARNING: Do not access chip registers using the i2cdump command, and do not use	85	WARNING: Do not access chip registers using the i2cdump command, and do not use

Documentation/hwmon/max20751.rst+1−1

@@ -30,7 +30,7 @@ Usage Notes · 29 unmodified lines
30	-----------	30	-----------
31		31
32	This driver does not auto-detect devices. You will have to instantiate the	32	This driver does not auto-detect devices. You will have to instantiate the
33	devices explicitly. Please see Documentation/i2c/instantiating-devices for	33	devices explicitly. Please see Documentation/i2c/instantiating-devices.rst for
34	details.	34	details.
35		35
36		36

Documentation/hwmon/max34440.rst+1−1

@@ -83,7 +83,7 @@ Usage Notes · 82 unmodified lines
83	-----------	83	-----------
84		84
85	This driver does not auto-detect devices. You will have to instantiate the	85	This driver does not auto-detect devices. You will have to instantiate the
86	devices explicitly. Please see Documentation/i2c/instantiating-devices for	86	devices explicitly. Please see Documentation/i2c/instantiating-devices.rst for
87	details.	87	details.
88		88
89	For MAX34446, the value of the currX_crit attribute determines if current or	89	For MAX34446, the value of the currX_crit attribute determines if current or

Documentation/hwmon/max6650.rst+1−1

@@ -55,7 +55,7 @@ Usage notes · 54 unmodified lines
55	-----------	55	-----------
56		56
57	This driver does not auto-detect devices. You will have to instantiate the	57	This driver does not auto-detect devices. You will have to instantiate the
58	devices explicitly. Please see Documentation/i2c/instantiating-devices for	58	devices explicitly. Please see Documentation/i2c/instantiating-devices.rst for
59	details.	59	details.
60		60
61	Module parameters	61	Module parameters

Documentation/hwmon/max8688.rst+1−1

@@ -28,7 +28,7 @@ Usage Notes · 27 unmodified lines
28	-----------	28	-----------
29		29
30	This driver does not auto-detect devices. You will have to instantiate the	30	This driver does not auto-detect devices. You will have to instantiate the
31	devices explicitly. Please see Documentation/i2c/instantiating-devices for	31	devices explicitly. Please see Documentation/i2c/instantiating-devices.rst for
32	details.	32	details.
33		33
34		34

Documentation/hwmon/menf21bmc.rst+1−1

@@ -28,7 +28,7 @@ Usage Notes · 27 unmodified lines
28	This driver is part of the MFD driver named "menf21bmc" and does	28	This driver is part of the MFD driver named "menf21bmc" and does
29	not auto-detect devices.	29	not auto-detect devices.
30	You will have to instantiate the MFD driver explicitly.	30	You will have to instantiate the MFD driver explicitly.
31	Please see Documentation/i2c/instantiating-devices for	31	Please see Documentation/i2c/instantiating-devices.rst for
32	details.	32	details.
33		33
34	Sysfs entries	34	Sysfs entries

Documentation/hwmon/pcf8591.rst+1−1

@@ -68,7 +68,7 @@ Accessing PCF8591 via /sys interface · 67 unmodified lines
68	The PCF8591 is plainly impossible to detect! Thus the driver won't even	68	The PCF8591 is plainly impossible to detect! Thus the driver won't even
69	try. You have to explicitly instantiate the device at the relevant	69	try. You have to explicitly instantiate the device at the relevant
70	address (in the interval [0x48..0x4f]) either through platform data, or	70	address (in the interval [0x48..0x4f]) either through platform data, or
71	using the sysfs interface. See Documentation/i2c/instantiating-devices	71	using the sysfs interface. See Documentation/i2c/instantiating-devices.rst
72	for details.	72	for details.
73		73
74	Directories are being created for each instantiated PCF8591:	74	Directories are being created for each instantiated PCF8591:

Documentation/hwmon/sht3x.rst+1−1

@@ -26,7 +26,7 @@ scaled by 1000, i.e. the value for 31.5 degrees celsius is 31500. · 25 unmodified lines
26		26
27	The device communicates with the I2C protocol. Sensors can have the I2C	27	The device communicates with the I2C protocol. Sensors can have the I2C
28	addresses 0x44 or 0x45, depending on the wiring. See	28	addresses 0x44 or 0x45, depending on the wiring. See
29	Documentation/i2c/instantiating-devices for methods to instantiate the device.	29	Documentation/i2c/instantiating-devices.rst for methods to instantiate the device.
30		30
31	There are two options configurable by means of sht3x_platform_data:	31	There are two options configurable by means of sht3x_platform_data:
32		32

Documentation/hwmon/shtc1.rst+1−1

@@ -36,7 +36,7 @@ humidity is expressed as a percentage. Driver can be used as well for SHTW1 · 35 unmodified lines
36	chip, which has the same electrical interface.	36	chip, which has the same electrical interface.
37		37
38	The device communicates with the I2C protocol. All sensors are set to I2C	38	The device communicates with the I2C protocol. All sensors are set to I2C
39	address 0x70. See Documentation/i2c/instantiating-devices for methods to	39	address 0x70. See Documentation/i2c/instantiating-devices.rst for methods to
40	instantiate the device.	40	instantiate the device.
41		41
42	There are two options configurable by means of shtc1_platform_data:	42	There are two options configurable by means of shtc1_platform_data:

Documentation/hwmon/tmp103.rst+1−1

@@ -30,4 +30,4 @@ The driver provides the common sysfs-interface for temperatures (see · 29 unmodified lines
30	Documentation/hwmon/sysfs-interface.rst under Temperatures).	30	Documentation/hwmon/sysfs-interface.rst under Temperatures).
31		31
32	Please refer how to instantiate this driver:	32	Please refer how to instantiate this driver:
33	Documentation/i2c/instantiating-devices	33	Documentation/i2c/instantiating-devices.rst

Documentation/hwmon/tps40422.rst+1−1

@@ -28,7 +28,7 @@ Usage Notes · 27 unmodified lines
28	-----------	28	-----------
29		29
30	This driver does not auto-detect devices. You will have to instantiate the	30	This driver does not auto-detect devices. You will have to instantiate the
31	devices explicitly. Please see Documentation/i2c/instantiating-devices for	31	devices explicitly. Please see Documentation/i2c/instantiating-devices.rst for
32	details.	32	details.
33		33
34		34

Documentation/hwmon/ucd9000.rst+1−1

@@ -64,7 +64,7 @@ Usage Notes · 63 unmodified lines
64	-----------	64	-----------
65		65
66	This driver does not auto-detect devices. You will have to instantiate the	66	This driver does not auto-detect devices. You will have to instantiate the
67	devices explicitly. Please see Documentation/i2c/instantiating-devices for	67	devices explicitly. Please see Documentation/i2c/instantiating-devices.rst for
68	details.	68	details.
69		69
70		70

Documentation/hwmon/ucd9200.rst+1−1

@@ -40,7 +40,7 @@ Usage Notes · 39 unmodified lines
40	-----------	40	-----------
41		41
42	This driver does not auto-detect devices. You will have to instantiate the	42	This driver does not auto-detect devices. You will have to instantiate the
43	devices explicitly. Please see Documentation/i2c/instantiating-devices for	43	devices explicitly. Please see Documentation/i2c/instantiating-devices.rst for
44	details.	44	details.
45		45
46		46

Documentation/hwmon/via686a.rst+1−1

@@ -40,7 +40,7 @@ all as a 686A. · 39 unmodified lines
40		40
41	The Via 686a southbridge has integrated hardware monitor functionality.	41	The Via 686a southbridge has integrated hardware monitor functionality.
42	It also has an I2C bus, but this driver only supports the hardware monitor.	42	It also has an I2C bus, but this driver only supports the hardware monitor.
43	For the I2C bus driver, see <file:Documentation/i2c/busses/i2c-viapro>	43	For the I2C bus driver, see <file:Documentation/i2c/busses/i2c-viapro.rst>
44		44
45	The Via 686a implements three temperature sensors, two fan rotation speed	45	The Via 686a implements three temperature sensors, two fan rotation speed
46	sensors, five voltage sensors and alarms.	46	sensors, five voltage sensors and alarms.

Documentation/hwmon/zl6100.rst+1−1

@@ -121,7 +121,7 @@ Usage Notes · 120 unmodified lines
121	-----------	121	-----------
122		122
123	This driver does not auto-detect devices. You will have to instantiate the	123	This driver does not auto-detect devices. You will have to instantiate the
124	devices explicitly. Please see Documentation/i2c/instantiating-devices for	124	devices explicitly. Please see Documentation/i2c/instantiating-devices.rst for
125	details.	125	details.
126		126
127	.. warning::	127	.. warning::

Documentation/i2c/busses/i2c-ali1535.rstrenamed from Documentation/i2c/busses/i2c-ali1535+8−5

+=========================
 Kernel driver i2c-ali1535
+=========================
 Supported adapters:
   * Acer Labs, Inc. ALI 1535 (south bridge)
     Datasheet: Now under NDA
 	http://www.ali.com.tw/
 Authors:
-	Frodo Looijaard <frodol@dds.nl>,
+	- Frodo Looijaard <frodol@dds.nl>,
-	Philip Edelbrock <phil@netroedge.com>,
+	- Philip Edelbrock <phil@netroedge.com>,
-	Mark D. Studebaker <mdsxyz123@yahoo.com>,
+	- Mark D. Studebaker <mdsxyz123@yahoo.com>,
-	Dan Eaton <dan.eaton@rocketlogix.com>,
+	- Dan Eaton <dan.eaton@rocketlogix.com>,
-	Stephen Rousset<stephen.rousset@rocketlogix.com>
+	- Stephen Rousset<stephen.rousset@rocketlogix.com>
 Description
 -----------

Documentation/i2c/busses/i2c-ali1563.rstrenamed from Documentation/i2c/busses/i2c-ali1563+3−0

@@ -1,7 +1,10 @@
		1	=========================
1	Kernel driver i2c-ali1563	2	Kernel driver i2c-ali1563
		3	=========================
2		4
3	Supported adapters:	5	Supported adapters:
4	* Acer Labs, Inc. ALI 1563 (south bridge)	6	* Acer Labs, Inc. ALI 1563 (south bridge)
		7
5	Datasheet: Now under NDA	8	Datasheet: Now under NDA
6	http://www.ali.com.tw/	9	http://www.ali.com.tw/
7		10

Documentation/i2c/busses/i2c-ali15x3.rstrenamed from Documentation/i2c/busses/i2c-ali15x3+37−27

@@ -1,20 +1,23 @@
		1	=========================
1	Kernel driver i2c-ali15x3	2	Kernel driver i2c-ali15x3
		3	=========================
2		4
3	Supported adapters:	5	Supported adapters:
4	* Acer Labs, Inc. ALI 1533 and 1543C (south bridge)	6	* Acer Labs, Inc. ALI 1533 and 1543C (south bridge)
		7
5	Datasheet: Now under NDA	8	Datasheet: Now under NDA
6	http://www.ali.com.tw/	9	http://www.ali.com.tw/
7		10
8	Authors:	11	Authors:
9	Frodo Looijaard <frodol@dds.nl>,	12	- Frodo Looijaard <frodol@dds.nl>,
10	Philip Edelbrock <phil@netroedge.com>,	13	- Philip Edelbrock <phil@netroedge.com>,
11	Mark D. Studebaker <mdsxyz123@yahoo.com>	14	- Mark D. Studebaker <mdsxyz123@yahoo.com>
12		15
13	Module Parameters	16	Module Parameters
14	-----------------	17	-----------------
15		18
16	* force_addr: int	19	* force_addr: int
17	Initialize the base address of the i2c controller	20	Initialize the base address of the i2c controller
18		21
19		22
20	Notes	23	Notes
@@ -25,7 +28,9 @@ the BIOS. Does not do a PCI force; the device must still be present in · 4 unmodified lines
25	lspci. Don't use this unless the driver complains that the base address is	28	lspci. Don't use this unless the driver complains that the base address is
26	not set.	29	not set.
27		30
28	Example: 'modprobe i2c-ali15x3 force_addr=0xe800'	31	Example::
		32
		33	modprobe i2c-ali15x3 force_addr=0xe800
29		34
30	SMBus periodically hangs on ASUS P5A motherboards and can only be cleared	35	SMBus periodically hangs on ASUS P5A motherboards and can only be cleared
31	by a power cycle. Cause unknown (see Issues below).	36	by a power cycle. Cause unknown (see Issues below).
@@ -38,47 +43,53 @@ This is the driver for the SMB Host controller on Acer Labs Inc. (ALI) · 6 unmodified lines
38	M1541 and M1543C South Bridges.	43	M1541 and M1543C South Bridges.
39		44
40	The M1543C is a South bridge for desktop systems.	45	The M1543C is a South bridge for desktop systems.
		46
41	The M1541 is a South bridge for portable systems.	47	The M1541 is a South bridge for portable systems.
		48
42	They are part of the following ALI chipsets:	49	They are part of the following ALI chipsets:
43		50
44	* "Aladdin Pro 2" includes the M1621 Slot 1 North bridge with AGP and	51	* "Aladdin Pro 2" includes the M1621 Slot 1 North bridge with AGP and
45	100MHz CPU Front Side bus	52	100MHz CPU Front Side bus
46	* "Aladdin V" includes the M1541 Socket 7 North bridge with AGP and 100MHz	53	* "Aladdin V" includes the M1541 Socket 7 North bridge with AGP and 100MHz
47	CPU Front Side bus	54	CPU Front Side bus
		55
48	Some Aladdin V motherboards:	56	Some Aladdin V motherboards:
49	Asus P5A	57	- Asus P5A
50	Atrend ATC-5220	58	- Atrend ATC-5220
51	BCM/GVC VP1541	59	- BCM/GVC VP1541
52	Biostar M5ALA	60	- Biostar M5ALA
53	Gigabyte GA-5AX (** Generally doesn't work because the BIOS doesn't	61	- Gigabyte GA-5AX (Generally doesn't work because the BIOS doesn't
54	enable the 7101 device! **)	62	enable the 7101 device!)
55	Iwill XA100 Plus	63	- Iwill XA100 Plus
56	Micronics C200	64	- Micronics C200
57	Microstar (MSI) MS-5169	65	- Microstar (MSI) MS-5169
58		66
59	* "Aladdin IV" includes the M1541 Socket 7 North bridge	67	* "Aladdin IV" includes the M1541 Socket 7 North bridge
60	with host bus up to 83.3 MHz.	68	with host bus up to 83.3 MHz.
61		69
62	For an overview of these chips see http://www.acerlabs.com. At this time the	70	For an overview of these chips see http://www.acerlabs.com. At this time the
63	full data sheets on the web site are password protected, however if you	71	full data sheets on the web site are password protected, however if you
64	contact the ALI office in San Jose they may give you the password.	72	contact the ALI office in San Jose they may give you the password.
65		73
66	The M1533/M1543C devices appear as FOUR separate devices on the PCI bus. An	74	The M1533/M1543C devices appear as FOUR separate devices on the PCI bus. An
67	output of lspci will show something similar to the following:	75	output of lspci will show something similar to the following::
68		76
69	00:02.0 USB Controller: Acer Laboratories Inc. M5237 (rev 03)	77	00:02.0 USB Controller: Acer Laboratories Inc. M5237 (rev 03)
70	00:03.0 Bridge: Acer Laboratories Inc. M7101 <= THIS IS THE ONE WE NEED	78	00:03.0 Bridge: Acer Laboratories Inc. M7101 <= THIS IS THE ONE WE NEED
71	00:07.0 ISA bridge: Acer Laboratories Inc. M1533 (rev c3)	79	00:07.0 ISA bridge: Acer Laboratories Inc. M1533 (rev c3)
72	00:0f.0 IDE interface: Acer Laboratories Inc. M5229 (rev c1)	80	00:0f.0 IDE interface: Acer Laboratories Inc. M5229 (rev c1)
73		81
74	IMPORTANT	82	.. important::
75	** If you have a M1533 or M1543C on the board and you get	83
76	** "ali15x3: Error: Can't detect ali15x3!"	84	If you have a M1533 or M1543C on the board and you get
77	** then run lspci.	85	"ali15x3: Error: Can't detect ali15x3!"
78	** If you see the 1533 and 5229 devices but NOT the 7101 device,	86	then run lspci.
79	** then you must enable ACPI, the PMU, SMB, or something similar	87
80	** in the BIOS.	88	If you see the 1533 and 5229 devices but NOT the 7101 device,
81	** The driver won't work if it can't find the M7101 device.	89	then you must enable ACPI, the PMU, SMB, or something similar
		90	in the BIOS.
		91
		92	The driver won't work if it can't find the M7101 device.
82		93
83	The SMB controller is part of the M7101 device, which is an ACPI-compliant	94	The SMB controller is part of the M7101 device, which is an ACPI-compliant
84	Power Management Unit (PMU).	95	Power Management Unit (PMU).
@@ -109,4 +120,3 @@ There may be electrical problems on this board. · 24 unmodified lines
109	On the P5A, the W83781D sensor chip is on both the ISA and	120	On the P5A, the W83781D sensor chip is on both the ISA and
110	SMBus. Therefore the SMBus hangs can generally be avoided	121	SMBus. Therefore the SMBus hangs can generally be avoided
111	by accessing the W83781D on the ISA bus only.	122	by accessing the W83781D on the ISA bus only.
112

Documentation/i2c/busses/i2c-amd-mp2+0−23

@@ -1,23 +0,0 @@
1	Kernel driver i2c-amd-mp2
2
3	Supported adapters:
4	* AMD MP2 PCIe interface
5
6	Datasheet: not publicly available.
7
8	Authors:
9	Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
10	Nehal Shah <nehal-bakulchandra.shah@amd.com>
11	Elie Morisse <syniurge@gmail.com>
12
13	Description
14	-----------
15
16	The MP2 is an ARM processor programmed as an I2C controller and communicating
17	with the x86 host through PCI.
18
19	If you see something like this:
20
21	03:00.7 MP2 I2C controller: Advanced Micro Devices, Inc. [AMD] Device 15e6
22
23	in your 'lspci -v', then this driver is for your device.

Documentation/i2c/busses/i2c-amd-mp2.rst+25−0

@@ -0,0 +1,25 @@
	1	=========================
	2	Kernel driver i2c-amd-mp2
	3	=========================
	4
	5	Supported adapters:
	6	* AMD MP2 PCIe interface
	7
	8	Datasheet: not publicly available.
	9
	10	Authors:
	11	- Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
	12	- Nehal Shah <nehal-bakulchandra.shah@amd.com>
	13	- Elie Morisse <syniurge@gmail.com>
	14
	15	Description
	16	-----------
	17
	18	The MP2 is an ARM processor programmed as an I2C controller and communicating
	19	with the x86 host through PCI.
	20
	21	If you see something like this::
	22
	23	03:00.7 MP2 I2C controller: Advanced Micro Devices, Inc. [AMD] Device 15e6
	24
	25	in your ``lspci -v``, then this driver is for your device.

Documentation/i2c/busses/i2c-amd756.rstrenamed from Documentation/i2c/busses/i2c-amd756+6−2

+========================
 Kernel driver i2c-amd756
+========================
 Supported adapters:
   * AMD 756
   * AMD 766
   * AMD 768
   * AMD 8111
     Datasheets: Publicly available on AMD website
   * nVidia nForce
     Datasheet: Unavailable
 Authors:
-	Frodo Looijaard <frodol@dds.nl>,
+	- Frodo Looijaard <frodol@dds.nl>,
-	Philip Edelbrock <phil@netroedge.com>
+	- Philip Edelbrock <phil@netroedge.com>
 Description
 -----------

Documentation/i2c/busses/i2c-amd8111.rstrenamed from Documentation/i2c/busses/i2c-amd8111+8−6

+=========================
 Kernel driver i2c-adm8111
+=========================
 Supported adapters:
     * AMD-8111 SMBus 2.0 PCI interface
 Description
 -----------
-If you see something like this:
+If you see something like this::
-00:07.2 SMBus: Advanced Micro Devices [AMD] AMD-8111 SMBus 2.0 (rev 02)
+  00:07.2 SMBus: Advanced Micro Devices [AMD] AMD-8111 SMBus 2.0 (rev 02)
-        Subsystem: Advanced Micro Devices [AMD] AMD-8111 SMBus 2.0
+          Subsystem: Advanced Micro Devices [AMD] AMD-8111 SMBus 2.0
-        Flags: medium devsel, IRQ 19
+          Flags: medium devsel, IRQ 19
-        I/O ports at d400 [size=32]
+          I/O ports at d400 [size=32]
-in your 'lspci -v', then this driver is for your chipset.
+in your ``lspci -v``, then this driver is for your chipset.
 Process Call Support
 --------------------

Documentation/i2c/busses/i2c-diolan-u2c.rstrenamed from Documentation/i2c/busses/i2c-diolan-u2c+3−0

@@ -1,7 +1,10 @@
		1	============================
1	Kernel driver i2c-diolan-u2c	2	Kernel driver i2c-diolan-u2c
		3	============================
2		4
3	Supported adapters:	5	Supported adapters:
4	* Diolan U2C-12 I2C-USB adapter	6	* Diolan U2C-12 I2C-USB adapter
		7
5	Documentation:	8	Documentation:
6	http://www.diolan.com/i2c/u2c12.html	9	http://www.diolan.com/i2c/u2c12.html
7		10

Documentation/i2c/busses/i2c-i801.rstrenamed from Documentation/i2c/busses/i2c-i801+21−12

+======================
 Kernel driver i2c-i801
+======================
 Supported adapters:
   * Intel 82801AA and 82801AB (ICH and ICH0 - part of the
   * Intel Comet Lake (PCH)
   * Intel Elkhart Lake (PCH)
   * Intel Tiger Lake (PCH)
    Datasheets: Publicly available at the Intel website
 On Intel Patsburg and later chipsets, both the normal host SMBus controller
 and the additional 'Integrated Device Function' controllers are supported.
 Authors:
-	Mark Studebaker <mdsxyz123@yahoo.com>
+	- Mark Studebaker <mdsxyz123@yahoo.com>
-	Jean Delvare <jdelvare@suse.de>
+	- Jean Delvare <jdelvare@suse.de>
 Module Parameters
 -----------------
 * disable_features (bit vector)
 Disable selected features normally supported by the device. This makes it
 possible to work around possible driver or hardware bugs if the feature in
 question doesn't work as intended for whatever reason. Bit values:
+ ====  =========================================
  0x01  disable SMBus PEC
  0x02  disable the block buffer
  0x08  disable the I2C block read functionality
  0x10  don't use interrupts
  0x20  disable SMBus Host Notify
+ ====  =========================================
 Description
 The ICH chips contain at least SEVEN separate PCI functions in TWO logical
 PCI devices. An output of lspci will show something similar to the
-following:
+following::
   00:1e.0 PCI bridge: Intel Corporation: Unknown device 2418 (rev 01)
   00:1f.0 ISA bridge: Intel Corporation: Unknown device 2410 (rev 01)
 hardware monitoring chip), you need to add your board to the list.
 The motherboard is identified using the subvendor and subdevice IDs of the
-host bridge PCI device. Get yours with "lspci -n -v -s 00:00.0":
+host bridge PCI device. Get yours with ``lspci -n -v -s 00:00.0``::
-00:00.0 Class 0600: 8086:2570 (rev 02)
+  00:00.0 Class 0600: 8086:2570 (rev 02)
-        Subsystem: 1043:80f2
+          Subsystem: 1043:80f2
-        Flags: bus master, fast devsel, latency 0
+          Flags: bus master, fast devsel, latency 0
-        Memory at fc000000 (32-bit, prefetchable) [size=32M]
+          Memory at fc000000 (32-bit, prefetchable) [size=32M]
-        Capabilities: [e4] #09 [2106]
+          Capabilities: [e4] #09 [2106]
-        Capabilities: [a0] AGP version 3.0
+          Capabilities: [a0] AGP version 3.0
 Here the host bridge ID is 2570 (82865G/PE/P), the subvendor ID is 1043
 (Asus) and the subdevice ID is 80f2 (P4P800-X). You can find the symbolic
 anything interesting on your hidden ICH SMBus.
-**********************
+----------------------------------------------------------------------------
 The lm_sensors project gratefully acknowledges the support of Texas
 Instruments in the initial development of this driver.

Documentation/i2c/busses/i2c-ismt.rstrenamed from Documentation/i2c/busses/i2c-ismt+14−6

@@ -1,4 +1,7 @@
		1	======================
1	Kernel driver i2c-ismt	2	Kernel driver i2c-ismt
		3	======================
		4
2		5
3	Supported adapters:	6	Supported adapters:
4	* Intel S12xx series SOCs	7	* Intel S12xx series SOCs
@@ -11,16 +14,21 @@ Module Parameters · 6 unmodified lines
11	-----------------	14	-----------------
12		15
13	* bus_speed (unsigned int)	16	* bus_speed (unsigned int)
		17
14	Allows changing of the bus speed. Normally, the bus speed is set by the BIOS	18	Allows changing of the bus speed. Normally, the bus speed is set by the BIOS
15	and never needs to be changed. However, some SMBus analyzers are too slow for	19	and never needs to be changed. However, some SMBus analyzers are too slow for
16	monitoring the bus during debug, thus the need for this module parameter.	20	monitoring the bus during debug, thus the need for this module parameter.
17	Specify the bus speed in kHz.	21	Specify the bus speed in kHz.
		22
18	Available bus frequency settings:	23	Available bus frequency settings:
19	0 no change	24
20	80 kHz	25	==== =========
21	100 kHz	26	0 no change
22	400 kHz	27	80 kHz
23	1000 kHz	28	100 kHz
		29	400 kHz
		30	1000 kHz
		31	==== =========
24		32
25		33
26	Description	34	Description
@@ -30,7 +38,7 @@ The S12xx series of SOCs have a pair of integrated SMBus 2.0 controllers · 3 unmodified lines
30	targeted primarily at the microserver and storage markets.	38	targeted primarily at the microserver and storage markets.
31		39
32	The S12xx series contain a pair of PCI functions. An output of lspci will show	40	The S12xx series contain a pair of PCI functions. An output of lspci will show
33	something similar to the following:	41	something similar to the following::
34		42
35	00:13.0 System peripheral: Intel Corporation Centerton SMBus 2.0 Controller 0	43	00:13.0 System peripheral: Intel Corporation Centerton SMBus 2.0 Controller 0
36	00:13.1 System peripheral: Intel Corporation Centerton SMBus 2.0 Controller 1	44	00:13.1 System peripheral: Intel Corporation Centerton SMBus 2.0 Controller 1

Documentation/i2c/busses/i2c-mlxcpld.rstrenamed from Documentation/i2c/busses/i2c-mlxcpld+6−0

+==================
 Driver i2c-mlxcpld
+==================
 Author: Michael Shych <michaelsh@mellanox.com>
 This is the Mellanox I2C controller logic, implemented in Lattice CPLD
 device.
 Device supports:
  - Master mode.
  - One physical bus.
  - Write Byte/Block.
 Registers:
+=============== === =======================================================================
 CPBLTY		0x0 - capability reg.
 			Bits [6:5] - transaction length. b01 - 72B is supported,
 			36B in other case.
 			For read transactions address is sent in a separate transaction and
 			specified in the four first bytes (DATA0 - DATA3). Data is read
 			starting from DATA0.
+=============== === =======================================================================

Documentation/i2c/busses/i2c-nforce2.rstrenamed from Documentation/i2c/busses/i2c-nforce2+18−15

+=========================
 Kernel driver i2c-nforce2
+=========================
 Supported adapters:
   * nForce2 MCP                10de:0064
   * nForce2 Ultra 400 MCP      10de:0084
   * nForce3 Pro150 MCP         10de:00D4
   * nForce3 250Gb MCP          10de:00E4
   * nForce4 MCP                10de:0052
   * nForce4 MCP-04             10de:0034
   * nForce MCP51               10de:0264
   * nForce MCP78S              10de:0752
   * nForce MCP79               10de:0AA2
-Datasheet: not publicly available, but seems to be similar to the
+Datasheet:
+           not publicly available, but seems to be similar to the
            AMD-8111 SMBus 2.0 adapter.
 Authors:
-	Hans-Frieder Vogt <hfvogt@gmx.net>,
+	- Hans-Frieder Vogt <hfvogt@gmx.net>,
-	Thomas Leibold <thomas@plx.com>,
+	- Thomas Leibold <thomas@plx.com>,
-        Patrick Dreker <patrick@dreker.de>
+        - Patrick Dreker <patrick@dreker.de>
 Description
 -----------
 i2c-nforce2 is a driver for the SMBuses included in the nVidia nForce2 MCP.
-If your 'lspci -v' listing shows something like the following,
+If your ``lspci -v`` listing shows something like the following::
-00:01.1 SMBus: nVidia Corporation: Unknown device 0064 (rev a2)
+  00:01.1 SMBus: nVidia Corporation: Unknown device 0064 (rev a2)
-        Subsystem: Asustek Computer, Inc.: Unknown device 0c11
+          Subsystem: Asustek Computer, Inc.: Unknown device 0c11
-        Flags: 66Mhz, fast devsel, IRQ 5
+          Flags: 66Mhz, fast devsel, IRQ 5
-        I/O ports at c000 [size=32]
+          I/O ports at c000 [size=32]
-        Capabilities: <available only to root>
+          Capabilities: <available only to root>
 then this driver should support the SMBuses of your motherboard.

Documentation/i2c/busses/i2c-nvidia-gpu.rstrenamed from Documentation/i2c/busses/i2c-nvidia-gpu+4−2

@@ -1,4 +1,6 @@
		1	============================
1	Kernel driver i2c-nvidia-gpu	2	Kernel driver i2c-nvidia-gpu
		3	============================
2		4
3	Datasheet: not publicly available.	5	Datasheet: not publicly available.
4		6
@@ -11,8 +13,8 @@ Description · 6 unmodified lines
11	i2c-nvidia-gpu is a driver for I2C controller included in NVIDIA Turing	13	i2c-nvidia-gpu is a driver for I2C controller included in NVIDIA Turing
12	and later GPUs and it is used to communicate with Type-C controller on GPUs.	14	and later GPUs and it is used to communicate with Type-C controller on GPUs.
13		15
14	If your 'lspci -v' listing shows something like the following,	16	If your ``lspci -v`` listing shows something like the following::
15		17
16	01:00.3 Serial bus controller [0c80]: NVIDIA Corporation Device 1ad9 (rev a1)	18	01:00.3 Serial bus controller [0c80]: NVIDIA Corporation Device 1ad9 (rev a1)
17		19
18	then this driver should support the I2C controller of your GPU.	20	then this driver should support the I2C controller of your GPU.

Documentation/i2c/busses/i2c-ocores.rstrenamed from Documentation/i2c/busses/i2c-ocores+12−10

+========================
 Kernel driver i2c-ocores
+========================
 Supported adapters:
   * OpenCores.org I2C controller by Richard Herveille (see datasheet link)
 There is also a possibility to attach a list of i2c_board_info which
 the i2c-ocores driver will add to the bus upon creation.
-E.G. something like:
+E.G. something like::
-static struct resource ocores_resources[] = {
+  static struct resource ocores_resources[] = {
 	[0] = {
 		.start	= MYI2C_BASEADDR,
 		.end	= MYI2C_BASEADDR + 8,
 		.end	= MYI2C_IRQ,
 		.flags	= IORESOURCE_IRQ,
 	},
-};
+  };
-/* optional board info */
+  /* optional board info */
-struct i2c_board_info ocores_i2c_board_info[] = {
+  struct i2c_board_info ocores_i2c_board_info[] = {
 	{
 		I2C_BOARD_INFO("tsc2003", 0x48),
 		.platform_data = &tsc2003_platform_data,
 		I2C_BOARD_INFO("adv7180", 0x42 >> 1),
 		.irq = ADV_IRQ
 	}
-};
+  };
-static struct ocores_i2c_platform_data myi2c_data = {
+  static struct ocores_i2c_platform_data myi2c_data = {
 	.regstep	= 2,		/* two bytes between registers */
 	.clock_khz	= 50000,	/* input clock of 50MHz */
 	.devices	= ocores_i2c_board_info, /* optional table of devices */
 	.num_devices	= ARRAY_SIZE(ocores_i2c_board_info), /* table size */
-};
+  };
-static struct platform_device myi2c = {
+  static struct platform_device myi2c = {
 	.name			= "ocores-i2c",
 	.dev = {
 		.platform_data	= &myi2c_data,
 	},
 	.num_resources		= ARRAY_SIZE(ocores_resources),
 	.resource		= ocores_resources,
-};
+  };

Documentation/i2c/busses/i2c-parport+0−178

@@ -1,178 +0,0 @@
1	Kernel driver i2c-parport
2
3	Author: Jean Delvare <jdelvare@suse.de>
4
5	This is a unified driver for several i2c-over-parallel-port adapters,
6	such as the ones made by Philips, Velleman or ELV. This driver is
7	meant as a replacement for the older, individual drivers:
8	* i2c-philips-par
9	* i2c-elv
10	* i2c-velleman
11	* video/i2c-parport (NOT the same as this one, dedicated to home brew
12	teletext adapters)
13
14	It currently supports the following devices:
15	* (type=0) Philips adapter
16	* (type=1) home brew teletext adapter
17	* (type=2) Velleman K8000 adapter
18	* (type=3) ELV adapter
19	* (type=4) Analog Devices ADM1032 evaluation board
20	* (type=5) Analog Devices evaluation boards: ADM1025, ADM1030, ADM1031
21	* (type=6) Barco LPT->DVI (K5800236) adapter
22	* (type=7) One For All JP1 parallel port adapter
23	* (type=8) VCT-jig
24
25	These devices use different pinout configurations, so you have to tell
26	the driver what you have, using the type module parameter. There is no
27	way to autodetect the devices. Support for different pinout configurations
28	can be easily added when needed.
29
30	Earlier kernels defaulted to type=0 (Philips). But now, if the type
31	parameter is missing, the driver will simply fail to initialize.
32
33	SMBus alert support is available on adapters which have this line properly
34	connected to the parallel port's interrupt pin.
35
36
37	Building your own adapter
38	-------------------------
39
40	If you want to build you own i2c-over-parallel-port adapter, here is
41	a sample electronics schema (credits go to Sylvain Munaut):
42
43	Device PC
44	Side ___________________Vdd (+) Side
45	\| \| \|
46	--- --- ---
47	\| \| \| \| \| \|
48	\|R\| \|R\| \|R\|
49	\| \| \| \| \| \|
50	--- --- ---
51	\| \| \|
52	\| \| /\| \|
53	SCL ----------x--------o \|-----------x------------------- pin 2
54	\| \\| \| \|
55	\| \| \|
56	\| \|\ \| \|
57	SDA ----------x----x---\| o---x--------------------------- pin 13
58	\| \|/ \|
59	\| \|
60	\| /\| \|
61	---------o \|----------------x-------------- pin 3
62	\\| \| \|
63	\| \|
64	--- ---
65	\| \| \| \|
66	\|R\| \|R\|
67	\| \| \| \|
68	--- ---
69	\| \|
70	### ###
71	GND GND
72
73	Remarks:
74	- This is the exact pinout and electronics used on the Analog Devices
75	evaluation boards.
76	/\|
77	- All inverters -o \|- must be 74HC05, they must be open collector output.
78	\\|
79	- All resitors are 10k.
80	- Pins 18-25 of the parallel port connected to GND.
81	- Pins 4-9 (D2-D7) could be used as VDD is the driver drives them high.
82	The ADM1032 evaluation board uses D4-D7. Beware that the amount of
83	current you can draw from the parallel port is limited. Also note that
84	all connected lines MUST BE driven at the same state, else you'll short
85	circuit the output buffers! So plugging the I2C adapter after loading
86	the i2c-parport module might be a good safety since data line state
87	prior to init may be unknown.
88	- This is 5V!
89	- Obviously you cannot read SCL (so it's not really standard-compliant).
90	Pretty easy to add, just copy the SDA part and use another input pin.
91	That would give (ELV compatible pinout):
92
93
94	Device PC
95	Side ______________________________Vdd (+) Side
96	\| \| \| \|
97	--- --- --- ---
98	\| \| \| \| \| \| \| \|
99	\|R\| \|R\| \|R\| \|R\|
100	\| \| \| \| \| \| \| \|
101	--- --- --- ---
102	\| \| \| \|
103	\| \| \|\ \| \|
104	SCL ----------x--------x--\| o---x------------------------ pin 15
105	\| \| \|/ \|
106	\| \| \|
107	\| \| /\| \|
108	\| ---o \|-------------x-------------- pin 2
109	\| \\| \| \|
110	\| \| \|
111	\| \| \|
112	\| \|\ \| \|
113	SDA ---------------x---x--\| o--------x------------------- pin 10
114	\| \|/ \|
115	\| \|
116	\| /\| \|
117	---o \|------------------x--------- pin 3
118	\\| \| \|
119	\| \|
120	--- ---
121	\| \| \| \|
122	\|R\| \|R\|
123	\| \| \| \|
124	--- ---
125	\| \|
126	### ###
127	GND GND
128
129
130	If possible, you should use the same pinout configuration as existing
131	adapters do, so you won't even have to change the code.
132
133
134	Similar (but different) drivers
135	-------------------------------
136
137	This driver is NOT the same as the i2c-pport driver found in the i2c
138	package. The i2c-pport driver makes use of modern parallel port features so
139	that you don't need additional electronics. It has other restrictions
140	however, and was not ported to Linux 2.6 (yet).
141
142	This driver is also NOT the same as the i2c-pcf-epp driver found in the
143	lm_sensors package. The i2c-pcf-epp driver doesn't use the parallel port as
144	an I2C bus directly. Instead, it uses it to control an external I2C bus
145	master. That driver was not ported to Linux 2.6 (yet) either.
146
147
148	Legacy documentation for Velleman adapter
149	-----------------------------------------
150
151	Useful links:
152	Velleman http://www.velleman.be/
153	Velleman K8000 Howto http://howto.htlw16.ac.at/k8000-howto.html
154
155	The project has lead to new libs for the Velleman K8000 and K8005:
156	LIBK8000 v1.99.1 and LIBK8005 v0.21
157	With these libs, you can control the K8000 interface card and the K8005
158	stepper motor card with the simple commands which are in the original
159	Velleman software, like SetIOchannel, ReadADchannel, SendStepCCWFull and
160	many more, using /dev/velleman.
161	http://home.wanadoo.nl/hihihi/libk8000.htm
162	http://home.wanadoo.nl/hihihi/libk8005.htm
163	http://struyve.mine.nu:8080/index.php?block=k8000
164	http://sourceforge.net/projects/libk8005/
165
166
167	One For All JP1 parallel port adapter
168	-------------------------------------
169
170	The JP1 project revolves around a set of remote controls which expose
171	the I2C bus their internal configuration EEPROM lives on via a 6 pin
172	jumper in the battery compartment. More details can be found at:
173
174	http://www.hifi-remote.com/jp1/
175
176	Details of the simple parallel port hardware can be found at:
177
178	http://www.hifi-remote.com/jp1/hardware.shtml

Documentation/i2c/busses/i2c-parport-light.rstrenamed from Documentation/i2c/busses/i2c-parport-light+5−3

@@ -1,13 +1,15 @@
		1	===============================
1	Kernel driver i2c-parport-light	2	Kernel driver i2c-parport-light
		3	===============================
2		4
3	Author: Jean Delvare <jdelvare@suse.de>	5	Author: Jean Delvare <jdelvare@suse.de>
4		6
5	This driver is a light version of i2c-parport. It doesn't depend	7	This driver is a light version of i2c-parport. It doesn't depend
6	on the parport driver, and uses direct I/O access instead. This might be	8	on the parport driver, and uses direct I/O access instead. This might be
7	preferred on embedded systems where wasting memory for the clean but heavy	9	preferred on embedded systems where wasting memory for the clean but heavy
8	parport handling is not an option. The drawback is a reduced portability	10	parport handling is not an option. The drawback is a reduced portability
9	and the impossibility to daisy-chain other parallel port devices.	11	and the impossibility to daisy-chain other parallel port devices.
10		12
11	Please see i2c-parport for documentation.	13	Please see i2c-parport for documentation.
12		14
13	Module parameters:	15	Module parameters:

Documentation/i2c/busses/i2c-parport.rst+190−0

@@ -0,0 +1,190 @@
	1	=========================
	2	Kernel driver i2c-parport
	3	=========================
	4
	5	Author: Jean Delvare <jdelvare@suse.de>
	6
	7	This is a unified driver for several i2c-over-parallel-port adapters,
	8	such as the ones made by Philips, Velleman or ELV. This driver is
	9	meant as a replacement for the older, individual drivers:
	10
	11	* i2c-philips-par
	12	* i2c-elv
	13	* i2c-velleman
	14	* video/i2c-parport
	15	(NOT the same as this one, dedicated to home brew teletext adapters)
	16
	17	It currently supports the following devices:
	18
	19	* (type=0) Philips adapter
	20	* (type=1) home brew teletext adapter
	21	* (type=2) Velleman K8000 adapter
	22	* (type=3) ELV adapter
	23	* (type=4) Analog Devices ADM1032 evaluation board
	24	* (type=5) Analog Devices evaluation boards: ADM1025, ADM1030, ADM1031
	25	* (type=6) Barco LPT->DVI (K5800236) adapter
	26	* (type=7) One For All JP1 parallel port adapter
	27	* (type=8) VCT-jig
	28
	29	These devices use different pinout configurations, so you have to tell
	30	the driver what you have, using the type module parameter. There is no
	31	way to autodetect the devices. Support for different pinout configurations
	32	can be easily added when needed.
	33
	34	Earlier kernels defaulted to type=0 (Philips). But now, if the type
	35	parameter is missing, the driver will simply fail to initialize.
	36
	37	SMBus alert support is available on adapters which have this line properly
	38	connected to the parallel port's interrupt pin.
	39
	40
	41	Building your own adapter
	42	-------------------------
	43
	44	If you want to build you own i2c-over-parallel-port adapter, here is
	45	a sample electronics schema (credits go to Sylvain Munaut)::
	46
	47	Device PC
	48	Side ___________________Vdd (+) Side
	49	\| \| \|
	50	--- --- ---
	51	\| \| \| \| \| \|
	52	\|R\| \|R\| \|R\|
	53	\| \| \| \| \| \|
	54	--- --- ---
	55	\| \| \|
	56	\| \| /\| \|
	57	SCL ----------x--------o \|-----------x------------------- pin 2
	58	\| \\| \| \|
	59	\| \| \|
	60	\| \|\ \| \|
	61	SDA ----------x----x---\| o---x--------------------------- pin 13
	62	\| \|/ \|
	63	\| \|
	64	\| /\| \|
	65	---------o \|----------------x-------------- pin 3
	66	\\| \| \|
	67	\| \|
	68	--- ---
	69	\| \| \| \|
	70	\|R\| \|R\|
	71	\| \| \| \|
	72	--- ---
	73	\| \|
	74	### ###
	75	GND GND
	76
	77	Remarks:
	78	- This is the exact pinout and electronics used on the Analog Devices
	79	evaluation boards.
	80	- All inverters::
	81
	82	/\|
	83	-o \|-
	84	\\|
	85
	86	must be 74HC05, they must be open collector output.
	87	- All resitors are 10k.
	88	- Pins 18-25 of the parallel port connected to GND.
	89	- Pins 4-9 (D2-D7) could be used as VDD is the driver drives them high.
	90	The ADM1032 evaluation board uses D4-D7. Beware that the amount of
	91	current you can draw from the parallel port is limited. Also note that
	92	all connected lines MUST BE driven at the same state, else you'll short
	93	circuit the output buffers! So plugging the I2C adapter after loading
	94	the i2c-parport module might be a good safety since data line state
	95	prior to init may be unknown.
	96	- This is 5V!
	97	- Obviously you cannot read SCL (so it's not really standard-compliant).
	98	Pretty easy to add, just copy the SDA part and use another input pin.
	99	That would give (ELV compatible pinout)::
	100
	101
	102	Device PC
	103	Side ______________________________Vdd (+) Side
	104	\| \| \| \|
	105	--- --- --- ---
	106	\| \| \| \| \| \| \| \|
	107	\|R\| \|R\| \|R\| \|R\|
	108	\| \| \| \| \| \| \| \|
	109	--- --- --- ---
	110	\| \| \| \|
	111	\| \| \|\ \| \|
	112	SCL ----------x--------x--\| o---x------------------------ pin 15
	113	\| \| \|/ \|
	114	\| \| \|
	115	\| \| /\| \|
	116	\| ---o \|-------------x-------------- pin 2
	117	\| \\| \| \|
	118	\| \| \|
	119	\| \| \|
	120	\| \|\ \| \|
	121	SDA ---------------x---x--\| o--------x------------------- pin 10
	122	\| \|/ \|
	123	\| \|
	124	\| /\| \|
	125	---o \|------------------x--------- pin 3
	126	\\| \| \|
	127	\| \|
	128	--- ---
	129	\| \| \| \|
	130	\|R\| \|R\|
	131	\| \| \| \|
	132	--- ---
	133	\| \|
	134	### ###
	135	GND GND
	136
	137
	138	If possible, you should use the same pinout configuration as existing
	139	adapters do, so you won't even have to change the code.
	140
	141
	142	Similar (but different) drivers
	143	-------------------------------
	144
	145	This driver is NOT the same as the i2c-pport driver found in the i2c
	146	package. The i2c-pport driver makes use of modern parallel port features so
	147	that you don't need additional electronics. It has other restrictions
	148	however, and was not ported to Linux 2.6 (yet).
	149
	150	This driver is also NOT the same as the i2c-pcf-epp driver found in the
	151	lm_sensors package. The i2c-pcf-epp driver doesn't use the parallel port as
	152	an I2C bus directly. Instead, it uses it to control an external I2C bus
	153	master. That driver was not ported to Linux 2.6 (yet) either.
	154
	155
	156	Legacy documentation for Velleman adapter
	157	-----------------------------------------
	158
	159	Useful links:
	160
	161	- Velleman http://www.velleman.be/
	162	- Velleman K8000 Howto http://howto.htlw16.ac.at/k8000-howto.html
	163
	164	The project has lead to new libs for the Velleman K8000 and K8005:
	165
	166	LIBK8000 v1.99.1 and LIBK8005 v0.21
	167
	168	With these libs, you can control the K8000 interface card and the K8005
	169	stepper motor card with the simple commands which are in the original
	170	Velleman software, like SetIOchannel, ReadADchannel, SendStepCCWFull and
	171	many more, using /dev/velleman.
	172
	173	- http://home.wanadoo.nl/hihihi/libk8000.htm
	174	- http://home.wanadoo.nl/hihihi/libk8005.htm
	175	- http://struyve.mine.nu:8080/index.php?block=k8000
	176	- http://sourceforge.net/projects/libk8005/
	177
	178
	179	One For All JP1 parallel port adapter
	180	-------------------------------------
	181
	182	The JP1 project revolves around a set of remote controls which expose
	183	the I2C bus their internal configuration EEPROM lives on via a 6 pin
	184	jumper in the battery compartment. More details can be found at:
	185
	186	http://www.hifi-remote.com/jp1/
	187
	188	Details of the simple parallel port hardware can be found at:
	189
	190	http://www.hifi-remote.com/jp1/hardware.shtml

Documentation/i2c/busses/i2c-pca-isa.rstrenamed from Documentation/i2c/busses/i2c-pca-isa+6−3

@@ -1,6 +1,9 @@
		1	=========================
1	Kernel driver i2c-pca-isa	2	Kernel driver i2c-pca-isa
		3	=========================
2		4
3	Supported adapters:	5	Supported adapters:
		6
4	This driver supports ISA boards using the Philips PCA 9564	7	This driver supports ISA boards using the Philips PCA 9564
5	Parallel bus to I2C bus controller	8	Parallel bus to I2C bus controller
6		9
@@ -10,11 +13,11 @@ Module Parameters · 3 unmodified lines
10	-----------------	13	-----------------
11		14
12	* base int	15	* base int
13	I/O base address	16	I/O base address
14	* irq int	17	* irq int
15	IRQ interrupt	18	IRQ interrupt
16	* clock int	19	* clock int
17	Clock rate as described in table 1 of PCA9564 datasheet	20	Clock rate as described in table 1 of PCA9564 datasheet
18		21
19	Description	22	Description
20	-----------	23	-----------

Documentation/i2c/busses/i2c-piix4.rstrenamed from Documentation/i2c/busses/i2c-piix4+10−8

+=======================
 Kernel driver i2c-piix4
+=======================
 Supported adapters:
   * Intel 82371AB PIIX4 and PIIX4E
   * Standard Microsystems (SMSC) SLC90E66 (Victory66) southbridge
     Datasheet: Publicly available at the SMSC website http://www.smsc.com
 Authors:
-	Frodo Looijaard <frodol@dds.nl>
+	- Frodo Looijaard <frodol@dds.nl>
-	Philip Edelbrock <phil@netroedge.com>
+	- Philip Edelbrock <phil@netroedge.com>
 Module Parameters
 The PIIX4 (properly known as the 82371AB) is an Intel chip with a lot of
 functionality. Among other things, it implements the PCI bus. One of its
 minor functions is implementing a System Management Bus. This is a true
 SMBus - you can not access it on I2C levels. The good news is that it
 natively understands SMBus commands and you do not have to worry about
 timing problems. The bad news is that non-SMBus devices connected to it can
 confuse it mightily. Yes, this is known to happen...
-Do 'lspci -v' and see whether it contains an entry like this:
+Do ``lspci -v`` and see whether it contains an entry like this::
-0000:00:02.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 02)
+  0000:00:02.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 02)
-	     Flags: medium devsel, IRQ 9
+	       Flags: medium devsel, IRQ 9
 Bus and device numbers may differ, but the function number must be
 identical (like many PCI devices, the PIIX4 incorporates a number of
    device is located at 00:0f.0.
 2) Now you just need to change the value in 0xD2 register. Get it first with
    command: lspci -xxx -s 00:0f.0
-   If the value is 0x3 then you need to change it to 0x1
+   If the value is 0x3 then you need to change it to 0x1:
    setpci  -s 00:0f.0 d2.b=1
 Please note that you don't need to do that in all cases, just when the SMBus is

Documentation/i2c/busses/i2c-sis5595.rstrenamed from Documentation/i2c/busses/i2c-sis5595+14−5

+=========================
 Kernel driver i2c-sis5595
+=========================
 Authors:
-	Frodo Looijaard <frodol@dds.nl>,
+	- Frodo Looijaard <frodol@dds.nl>,
-        Mark D. Studebaker <mdsxyz123@yahoo.com>,
+        - Mark D. Studebaker <mdsxyz123@yahoo.com>,
-	Philip Edelbrock <phil@netroedge.com>
+	- Philip Edelbrock <phil@netroedge.com>
 Supported adapters:
   * Silicon Integrated Systems Corp. SiS5595 Southbridge
 Note: all have mfr. ID 0x1039.
+   =========            ======
    SUPPORTED            PCI ID
+   =========            ======
         5595            0008
+   =========            ======
    Note: these chips contain a 0008 device which is incompatible with the
          5595. We recognize these by the presence of the listed
          "blacklist" PCI ID and refuse to load.
+   =============        ======          ================
    NOT SUPPORTED        PCI ID          BLACKLIST PCI ID
+   =============        ======          ================
          540            0008            0540
          550            0008            0550
         5513            0008            5511
          735            0008            0735
          745            0008            0745
          746            0008            0746
+   =============        ======          ================
 Module Parameters
 -----------------
-* force_addr=0xaddr	Set the I/O base address. Useful for boards
+==================	=====================================================
+force_addr=0xaddr	Set the I/O base address. Useful for boards
 			that don't set the address in the BIOS. Does not do a
 			PCI force; the device must still be present in lspci.
 			Don't use this unless the driver complains that the
 			base address is not set.
+==================	=====================================================
 Description
 -----------
 chip, you want the sis5595 driver for those, not this driver. This driver
 is a BUS driver, not a CHIP driver. A BUS driver is used by other CHIP
 drivers to access chips on the bus.

Documentation/i2c/busses/i2c-sis630+0−58

@@ -1,58 +0,0 @@
1	Kernel driver i2c-sis630
2
3	Supported adapters:
4	* Silicon Integrated Systems Corp (SiS)
5	630 chipset (Datasheet: available at http://www.sfr-fresh.com/linux)
6	730 chipset
7	964 chipset
8	* Possible other SiS chipsets ?
9
10	Author: Alexander Malysh <amalysh@web.de>
11	Amaury Decrême <amaury.decreme@gmail.com> - SiS964 support
12
13	Module Parameters
14	-----------------
15
16	* force = [1\|0] Forcibly enable the SIS630. DANGEROUS!
17	This can be interesting for chipsets not named
18	above to check if it works for you chipset, but DANGEROUS!
19
20	* high_clock = [1\|0] Forcibly set Host Master Clock to 56KHz (default,
21	what your BIOS use). DANGEROUS! This should be a bit
22	faster, but freeze some systems (i.e. my Laptop).
23	SIS630/730 chip only.
24
25
26	Description
27	-----------
28
29	This SMBus only driver is known to work on motherboards with the above
30	named chipsets.
31
32	If you see something like this:
33
34	00:00.0 Host bridge: Silicon Integrated Systems [SiS] 630 Host (rev 31)
35	00:01.0 ISA bridge: Silicon Integrated Systems [SiS] 85C503/5513
36
37	or like this:
38
39	00:00.0 Host bridge: Silicon Integrated Systems [SiS] 730 Host (rev 02)
40	00:01.0 ISA bridge: Silicon Integrated Systems [SiS] 85C503/5513
41
42	or like this:
43
44	00:00.0 Host bridge: Silicon Integrated Systems [SiS] 760/M760 Host (rev 02)
45	00:02.0 ISA bridge: Silicon Integrated Systems [SiS] SiS964 [MuTIOL Media IO]
46	LPC Controller (rev 36)
47
48	in your 'lspci' output , then this driver is for your chipset.
49
50	Thank You
51	---------
52	Philip Edelbrock <phil@netroedge.com>
53	- testing SiS730 support
54	Mark M. Hoffman <mhoffman@lightlink.com>
55	- bug fixes
56
57	To anyone else which I forgot here ;), thanks!
58

Documentation/i2c/busses/i2c-sis630.rst+63−0

@@ -0,0 +1,63 @@
	1	========================
	2	Kernel driver i2c-sis630
	3	========================
	4
	5	Supported adapters:
	6	* Silicon Integrated Systems Corp (SiS)
	7	630 chipset (Datasheet: available at http://www.sfr-fresh.com/linux)
	8	730 chipset
	9	964 chipset
	10	* Possible other SiS chipsets ?
	11
	12	Author:
	13	- Alexander Malysh <amalysh@web.de>
	14	- Amaury Decrême <amaury.decreme@gmail.com> - SiS964 support
	15
	16	Module Parameters
	17	-----------------
	18
	19	================== =====================================================
	20	force = [1\|0] Forcibly enable the SIS630. DANGEROUS!
	21	This can be interesting for chipsets not named
	22	above to check if it works for you chipset,
	23	but DANGEROUS!
	24
	25	high_clock = [1\|0] Forcibly set Host Master Clock to 56KHz (default,
	26	what your BIOS use). DANGEROUS! This should be a bit
	27	faster, but freeze some systems (i.e. my Laptop).
	28	SIS630/730 chip only.
	29	================== =====================================================
	30
	31
	32	Description
	33	-----------
	34
	35	This SMBus only driver is known to work on motherboards with the above
	36	named chipsets.
	37
	38	If you see something like this::
	39
	40	00:00.0 Host bridge: Silicon Integrated Systems [SiS] 630 Host (rev 31)
	41	00:01.0 ISA bridge: Silicon Integrated Systems [SiS] 85C503/5513
	42
	43	or like this::
	44
	45	00:00.0 Host bridge: Silicon Integrated Systems [SiS] 730 Host (rev 02)
	46	00:01.0 ISA bridge: Silicon Integrated Systems [SiS] 85C503/5513
	47
	48	or like this::
	49
	50	00:00.0 Host bridge: Silicon Integrated Systems [SiS] 760/M760 Host (rev 02)
	51	00:02.0 ISA bridge: Silicon Integrated Systems [SiS] SiS964 [MuTIOL Media IO]
	52	LPC Controller (rev 36)
	53
	54	in your ``lspci`` output , then this driver is for your chipset.
	55
	56	Thank You
	57	---------
	58	Philip Edelbrock <phil@netroedge.com>
	59	- testing SiS730 support
	60	Mark M. Hoffman <mhoffman@lightlink.com>
	61	- bug fixes
	62
	63	To anyone else which I forgot here ;), thanks!

Documentation/i2c/busses/i2c-sis96x.rstrenamed from Documentation/i2c/busses/i2c-sis96x+20−11

+========================
 Kernel driver i2c-sis96x
+========================
 Replaces 2.4.x i2c-sis645
 Supported adapters:
   * Silicon Integrated Systems Corp (SiS)
     Any combination of these host bridges:
 	645, 645DX (aka 646), 648, 650, 651, 655, 735, 745, 746
     and these south bridges:
-    	961, 962, 963(L)
+	961, 962, 963(L)
 Author: Mark M. Hoffman <mhoffman@lightlink.com>
 place. Thanks to Alexander Malysh <amalysh@web.de> for providing the
 SiS630 datasheet (and  driver).
-The command "lspci" as root should produce something like these lines:
+The command ``lspci`` as root should produce something like these lines::
-00:00.0 Host bridge: Silicon Integrated Systems [SiS]: Unknown device 0645
+  00:00.0 Host bridge: Silicon Integrated Systems [SiS]: Unknown device 0645
-00:02.0 ISA bridge: Silicon Integrated Systems [SiS] 85C503/5513
+  00:02.0 ISA bridge: Silicon Integrated Systems [SiS] 85C503/5513
-00:02.1 SMBus: Silicon Integrated Systems [SiS]: Unknown device 0016
+  00:02.1 SMBus: Silicon Integrated Systems [SiS]: Unknown device 0016
-or perhaps this...
+or perhaps this::
-00:00.0 Host bridge: Silicon Integrated Systems [SiS]: Unknown device 0645
+  00:00.0 Host bridge: Silicon Integrated Systems [SiS]: Unknown device 0645
-00:02.0 ISA bridge: Silicon Integrated Systems [SiS]: Unknown device 0961
+  00:02.0 ISA bridge: Silicon Integrated Systems [SiS]: Unknown device 0961
-00:02.1 SMBus: Silicon Integrated Systems [SiS]: Unknown device 0016
+  00:02.1 SMBus: Silicon Integrated Systems [SiS]: Unknown device 0016
 (kernel versions later than 2.4.18 may fill in the "Unknown"s)
 ------
 * The driver does not support SMBus block reads/writes; I may add them if a
-scenario is found where they're needed.
+  scenario is found where they're needed.
 Thank You
 Mark D. Studebaker <mdsxyz123@yahoo.com>
  - design hints and bug fixes
 Alexander Maylsh <amalysh@web.de>
  - ditto, plus an important datasheet... almost the one I really wanted
 Hans-Günter Lütke Uphues <hg_lu@t-online.de>
  - patch for SiS735
 Robert Zwerus <arzie@dds.nl>
  - testing for SiS645DX
 Kianusch Sayah Karadji <kianusch@sk-tech.net>
  - patch for SiS645DX/962
 Ken Healy
  - patch for SiS655
 To anyone else who has written w/ feedback, thanks!

Documentation/i2c/busses/i2c-taos-evm.rstrenamed from Documentation/i2c/busses/i2c-taos-evm+5−3

+==========================
 Kernel driver i2c-taos-evm
+==========================
 Author: Jean Delvare <jdelvare@suse.de>
 In order to use this driver, you'll need the serport driver, and the
 inputattach tool, which is part of the input-utils package. The following
 commands will tell the kernel that you have a TAOS EVM on the first
-serial port:
+serial port::
-# modprobe serport
+  # modprobe serport
-# inputattach --taos-evm /dev/ttyS0
+  # inputattach --taos-evm /dev/ttyS0
 Technical details

Documentation/i2c/busses/i2c-via.rstrenamed from Documentation/i2c/busses/i2c-via+17−11

@@ -1,4 +1,6 @@
		1	=====================
1	Kernel driver i2c-via	2	Kernel driver i2c-via
		3	=====================
2		4
3	Supported adapters:	5	Supported adapters:
4	* VIA Technologies, InC. VT82C586B	6	* VIA Technologies, InC. VT82C586B
@@ -12,23 +14,27 @@ Description · 7 unmodified lines
12	i2c-via is an i2c bus driver for motherboards with VIA chipset.	14	i2c-via is an i2c bus driver for motherboards with VIA chipset.
13		15
14	The following VIA pci chipsets are supported:	16	The following VIA pci chipsets are supported:
15	- MVP3, VP3, VP2/97, VPX/97	17	- MVP3, VP3, VP2/97, VPX/97
16	- others with South bridge VT82C586B	18	- others with South bridge VT82C586B
17		19
18	Your lspci listing must show this :	20	Your ``lspci`` listing must show this ::
19		21
20	Bridge: VIA Technologies, Inc. VT82C586B ACPI (rev 10)	22	Bridge: VIA Technologies, Inc. VT82C586B ACPI (rev 10)
21		23
22	Problems?	24	Problems?
23		25	---------
24	Q: You have VT82C586B on the motherboard, but not in the listing.
25
26	A: Go to your BIOS setup, section PCI devices or similar.
27	Turn USB support on, and try again.
28		26
29	Q: No error messages, but still i2c doesn't seem to work.	27	Q:
		28	You have VT82C586B on the motherboard, but not in the listing.
30		29
31	A: This can happen. This driver uses the pins VIA recommends in their	30	A:
		31	Go to your BIOS setup, section PCI devices or similar.
		32	Turn USB support on, and try again.
		33
		34	Q:
		35	No error messages, but still i2c doesn't seem to work.
		36
		37	A:
		38	This can happen. This driver uses the pins VIA recommends in their
32	datasheets, but there are several ways the motherboard manufacturer	39	datasheets, but there are several ways the motherboard manufacturer
33	can actually wire the lines.	40	can actually wire the lines.
34

Documentation/i2c/busses/i2c-viapro.rstrenamed from Documentation/i2c/busses/i2c-viapro+8−4

+========================
 Kernel driver i2c-viapro
+========================
 Supported adapters:
   * VIA Technologies, Inc. VT82C596A/B
     Datasheet: available on http://linux.via.com.tw
 Authors:
-	Kyösti Mälkki <kmalkki@cc.hut.fi>,
+	- Kyösti Mälkki <kmalkki@cc.hut.fi>,
-	Mark D. Studebaker <mdsxyz123@yahoo.com>,
+	- Mark D. Studebaker <mdsxyz123@yahoo.com>,
-	Jean Delvare <jdelvare@suse.de>
+	- Jean Delvare <jdelvare@suse.de>
 Module Parameters
 -----------------
 i2c-viapro is a true SMBus host driver for motherboards with one of the
 supported VIA south bridges.
-Your lspci -n listing must show one of these :
+Your ``lspci -n`` listing must show one of these :
+ ================   ======================
  device 1106:3050   (VT82C596A function 3)
  device 1106:3051   (VT82C596B function 3)
  device 1106:3057   (VT82C686 function 4)
  device 1106:8353   (VX800/VX820)
  device 1106:8409   (VX855/VX875)
  device 1106:8410   (VX900)
+ ================   ======================
 If none of these show up, you should look in the BIOS for settings like
 enable ACPI / SMBus or even USB.

Documentation/i2c/busses/index.rst+33−0

@@ -0,0 +1,33 @@
	1	. SPDX-License-Identifier: GPL-2.0
	2
	3	===============
	4	I2C Bus Drivers
	5	===============
	6
	7	.. toctree::
	8	:maxdepth: 1
	9
	10	i2c-ali1535
	11	i2c-ali1563
	12	i2c-ali15x3
	13	i2c-amd756
	14	i2c-amd8111
	15	i2c-amd-mp2
	16	i2c-diolan-u2c
	17	i2c-i801
	18	i2c-ismt
	19	i2c-mlxcpld
	20	i2c-nforce2
	21	i2c-nvidia-gpu
	22	i2c-ocores
	23	i2c-parport-light
	24	i2c-parport
	25	i2c-pca-isa
	26	i2c-piix4
	27	i2c-sis5595
	28	i2c-sis630
	29	i2c-sis96x
	30	i2c-taos-evm
	31	i2c-viapro
	32	i2c-via
	33	scx200_acb

Documentation/i2c/busses/scx200_acb.rstrenamed from Documentation/i2c/busses/scx200_acb+7−2

+========================
 Kernel driver scx200_acb
+========================
 Author: Christer Weinigel <wingel@nano-system.com>
 The SC1100 WRAP boards are known to use base addresses 0x810 and 0x820.
 If the scx200_acb driver is built into the kernel, add the following
-parameter to your boot command line:
+parameter to your boot command line::
   scx200_acb.base=0x810,0x820
 If the scx200_acb driver is built as a module, add the following line to
-a configuration file in /etc/modprobe.d/ instead:
+a configuration file in /etc/modprobe.d/ instead::
   options scx200_acb base=0x810,0x820

Documentation/i2c/dev-interface.rstrenamed from Documentation/i2c/dev-interface+55−49

Documentation/i2c/dma-considerations.rstrenamed from Documentation/i2c/DMA-considerations+0−0

File renamed without changes.

Documentation/i2c/fault-codes.rstrenamed from Documentation/i2c/fault-codes+4−1

+=====================
+I2C/SMBUS Fault Codes
+=====================
 This is a summary of the most important conventions for use of fault
 codes in the I2C/SMBus stack.
 	when a slave stretches clocks too far.  I2C has no such
 	timeouts, but it's normal for I2C adapters to impose some
 	arbitrary limits (much longer than SMBus!) too.

Documentation/i2c/functionality.rstrenamed from Documentation/i2c/functionality+15−7

+=======================
+I2C/SMBus Functionality
+=======================
 INTRODUCTION
 ------------
 Because not every I2C or SMBus adapter implements everything in the
 I2C specifications, a client can not trust that everything it needs
 is implemented when it is given the option to attach to an adapter:
 the client needs some way to check whether an adapter has the needed
 functionality.
 FUNCTIONALITY CONSTANTS
 For the most up-to-date list of functionality constants, please check
 <uapi/linux/i2c.h>!
+  =============================== ==============================================
   I2C_FUNC_I2C                    Plain i2c-level commands (Pure SMBus
                                   adapters typically can not do these)
   I2C_FUNC_10BIT_ADDR             Handles the 10-bit address extensions
   I2C_FUNC_SMBUS_WRITE_BLOCK_DATA Handles the SMBus write_block_data command
   I2C_FUNC_SMBUS_READ_I2C_BLOCK   Handles the SMBus read_i2c_block_data command
   I2C_FUNC_SMBUS_WRITE_I2C_BLOCK  Handles the SMBus write_i2c_block_data command
+  =============================== ==============================================
 A few combinations of the above flags are also defined for your convenience:
+  =========================       ======================================
   I2C_FUNC_SMBUS_BYTE             Handles the SMBus read_byte
                                   and write_byte commands
   I2C_FUNC_SMBUS_BYTE_DATA        Handles the SMBus read_byte_data
   I2C_FUNC_SMBUS_EMUL             Handles all SMBus commands that can be
                                   emulated by a real I2C adapter (using
                                   the transparent emulation layer)
+  =========================       ======================================
 In kernel versions prior to 3.5 I2C_FUNC_NOSTART was implemented as
 part of I2C_FUNC_PROTOCOL_MANGLING.
 ----------------------
 When you write a new adapter driver, you will have to implement a
-function callback `functionality'. Typical implementations are given
+function callback ``functionality``. Typical implementations are given
 below.
 A typical SMBus-only adapter would list all the SMBus transactions it
-supports. This example comes from the i2c-piix4 driver:
+supports. This example comes from the i2c-piix4 driver::
   static u32 piix4_func(struct i2c_adapter *adapter)
   {
   }
 A typical full-I2C adapter would use the following (from the i2c-pxa
-driver):
+driver)::
   static u32 i2c_pxa_functionality(struct i2c_adapter *adap)
   {
 Before a client tries to attach to an adapter, or even do tests to check
 whether one of the devices it supports is present on an adapter, it should
 check whether the needed functionality is present. The typical way to do
-this is (from the lm75 driver):
+this is (from the lm75 driver)::
   static int lm75_detect(...)
   {
 to use the /dev interface. You will still have to check whether the
 functionality you need is supported, of course. This is done using
 the I2C_FUNCS ioctl. An example, adapted from the i2cdetect program, is
-below:
+below::
   int file;
   if (file = open("/dev/i2c-0", O_RDWR) < 0) {

Documentation/i2c/gpio-fault-injection.rstrenamed from Documentation/i2c/gpio-fault-injection+6−6

Documentation/i2c/i2c-protocol.rstrenamed from Documentation/i2c/i2c-protocol+19−9

+============
+I2C Protocol
+============
 This document describes the i2c protocol. Or will, when it is finished :-)
 Key to symbols
 ==============
+=============== =============================================================
 S     (1 bit) : Start bit
 P     (1 bit) : Stop bit
 Rd/Wr (1 bit) : Read/Write bit. Rd equals 1, Wr equals 0.
                 for 16 bit data.
 Count (8 bits): A data byte containing the length of a block operation.
-[..]: Data sent by I2C device, as opposed to data sent by the host adapter.
+[..]:           Data sent by I2C device, as opposed to data sent by the
+                host adapter.
+=============== =============================================================
 Simple send transaction
-======================
+=======================
-This corresponds to i2c_master_send.
+This corresponds to i2c_master_send::
   S Addr Wr [A] Data [A] Data [A] ... [A] Data [A] P
 Simple receive transaction
-===========================
+==========================
-This corresponds to i2c_master_recv
+This corresponds to i2c_master_recv::
   S Addr Rd [A] [Data] A [Data] A ... A [Data] NA P
 Combined transactions
-====================
+=====================
 This corresponds to i2c_transfer
 They are just like the above transactions, but instead of a stop bit P
 a start bit S is sent and the transaction continues. An example of
-a byte read, followed by a byte write:
+a byte read, followed by a byte write::
   S Addr Rd [A] [Data] NA S Addr Wr [A] Data [A] P
 I2C_M_NOSTART:
     In a combined transaction, no 'S Addr Wr/Rd [A]' is generated at some
     point. For example, setting I2C_M_NOSTART on the second partial message
-    generates something like:
+    generates something like::
       S Addr Rd [A] [Data] NA Data [A] P
     If you set the I2C_M_NOSTART variable for the first partial message,
     we do not generate Addr, but we do generate the startbit S. This will
     probably confuse all other clients on your bus, so don't try this.
 I2C_M_REV_DIR_ADDR:
     This toggles the Rd/Wr flag. That is, if you want to do a write, but
     need to emit an Rd instead of a Wr, or vice versa, you set this
-    flag. For example:
+    flag. For example::
       S Addr Rd [A] Data [A] Data [A] ... [A] Data [A] P
 I2C_M_STOP:

Documentation/i2c/i2c-stub.rstrenamed from Documentation/i2c/i2c-stub+11−9

-MODULE: i2c-stub
+========
+i2c-stub
+========
-DESCRIPTION:
+Description
+===========
 This module is a very simple fake I2C/SMBus driver.  It implements six
 types of SMBus commands: write quick, (r/w) byte, (r/w) byte data, (r/w)
 return the number of bytes selected with the largest write so far.
 The typical use-case is like this:
 	1. load this module
 	2. use i2cset (from the i2c-tools project) to pre-load some data
 	3. load the target chip driver module
 There's a script named i2c-stub-from-dump in the i2c-tools package which
 can load register values automatically from a chip dump.
-PARAMETERS:
+Parameters
+==========
 int chip_addr[10]:
 	The SMBus addresses to emulate chips at.
 	value 0x1f0000 would only enable the quick, byte and byte data
 	commands.
-u8 bank_reg[10]
+u8 bank_reg[10], u8 bank_mask[10], u8 bank_start[10], u8 bank_end[10]:
-u8 bank_mask[10]
-u8 bank_start[10]
-u8 bank_end[10]:
 	Optional bank settings. They tell which bits in which register
 	select the active bank, as well as the range of banked registers.
-CAVEATS:
+Caveats
+=======
 If your target driver polls some byte or word waiting for it to change, the
 stub could lock it up.  Use i2cset to unlock it.
 If you spam it hard enough, printk can be lossy.  This module really wants
 something like relayfs.

Documentation/i2c/i2c-topology.rstrenamed from Documentation/i2c/i2c-topology+44−24

+============
 I2C topology
 ============
    that has to be operated before the device can be accessed.
 Etc
+===
 These constructs are represented as i2c adapter trees by Linux, where
 each adapter has a parent adapter (except the root adapter) and zero or
 useful to know if a mux is mux-locked or if it is parent-locked. The
 following list was correct at the time of writing:
-In drivers/i2c/muxes/
+In drivers/i2c/muxes/:
+======================    =============================================
 i2c-arb-gpio-challenge    Parent-locked
 i2c-mux-gpio              Normally parent-locked, mux-locked iff
                           all involved gpio pins are controlled by the
                           all involved pinctrl devices are controlled
                           by the same i2c root adapter that they mux.
 i2c-mux-reg               Parent-locked
+======================    =============================================
+In drivers/iio/:
-In drivers/iio/
+======================    =============================================
 gyro/mpu3050              Mux-locked
 imu/inv_mpu6050/          Mux-locked
+======================    =============================================
-In drivers/media/
+In drivers/media/:
+=======================   =============================================
 dvb-frontends/lgdt3306a   Mux-locked
 dvb-frontends/m88ds3103   Parent-locked
 dvb-frontends/rtl2830     Parent-locked
 dvb-frontends/rtl2832     Mux-locked
 dvb-frontends/si2168      Mux-locked
 usb/cx231xx/              Parent-locked
+=======================   =============================================
 Mux-locked muxes
 stages of the transaction. This has the benefit that the mux driver
 may be easier and cleaner to implement, but it has some caveats.
+==== =====================================================================
 ML1. If you build a topology with a mux-locked mux being the parent
      of a parent-locked mux, this might break the expectation from the
      parent-locked mux that the root adapter is locked during the
      Otherwise garbage may appear on the bus as seen from devices
      behind the mux, when an unrelated i2c transfer is in flight during
      the non-i2c mux-changing operation.
+==== =====================================================================
 Mux-locked Example
 ------------------
+::
                    .----------.     .--------.
     .--------.     |   mux-   |-----| dev D1 |
     |  root  |--+--|  locked  |     '--------'
 __i2c_transfer), or a deadlock will follow. There are a couple of
 caveats.
+==== ====================================================================
 PL1. If you build a topology with a parent-locked mux being the child
      of another mux, this might break a possible assumption from the
      child mux that the root adapter is unused between its select op
      caused by these subsystems are unlocked. This can be convoluted to
      accomplish, maybe even impossible if an acceptably clean solution
      is sought.
+==== ====================================================================
 Parent-locked Example
 ---------------------
+::
                    .----------.     .--------.
     .--------.     |  parent- |-----| dev D1 |
     |  root  |--+--|  locked  |     '--------'
 When there is an access to D1, this happens:
- 1. Someone issues an i2c-transfer to D1.
+ 1.  Someone issues an i2c-transfer to D1.
- 2. M1 locks muxes on its parent (the root adapter in this case).
+ 2.  M1 locks muxes on its parent (the root adapter in this case).
- 3. M1 locks its parent adapter.
+ 3.  M1 locks its parent adapter.
- 4. M1 calls ->select to ready the mux.
+ 4.  M1 calls ->select to ready the mux.
- 5. If M1 does any i2c-transfers (on this root adapter) as part of
+ 5.  If M1 does any i2c-transfers (on this root adapter) as part of
-    its select, those transfers must be unlocked i2c-transfers so
+     its select, those transfers must be unlocked i2c-transfers so
-    that they do not deadlock the root adapter.
+     that they do not deadlock the root adapter.
- 6. M1 feeds the i2c-transfer from step 1 to the root adapter as an
+ 6.  M1 feeds the i2c-transfer from step 1 to the root adapter as an
-    unlocked i2c-transfer, so that it does not deadlock the parent
+     unlocked i2c-transfer, so that it does not deadlock the parent
-    adapter.
+     adapter.
- 7. M1 calls ->deselect, if it has one.
+ 7.  M1 calls ->deselect, if it has one.
- 8. Same rules as in step 5, but for ->deselect.
+ 8.  Same rules as in step 5, but for ->deselect.
- 9. M1 unlocks its parent adapter.
+ 9.  M1 unlocks its parent adapter.
-10. M1 unlocks muxes on its parent.
+ 10. M1 unlocks muxes on its parent.
 This means that accesses to both D2 and D3 are locked out for the full
 Parent-locked mux as parent of parent-locked mux
 ------------------------------------------------
-This is a useful topology, but it can be bad.
+This is a useful topology, but it can be bad::
                    .----------.     .----------.     .--------.
     .--------.     |  parent- |-----|  parent- |-----| dev D1 |
 Mux-locked mux as parent of mux-locked mux
 ------------------------------------------
-This is a good topology.
+This is a good topology::
                    .----------.     .----------.     .--------.
     .--------.     |   mux-   |-----|   mux-   |-----| dev D1 |
 Mux-locked mux as parent of parent-locked mux
 ---------------------------------------------
-This is probably a bad topology.
+This is probably a bad topology::
                    .----------.     .----------.     .--------.
     .--------.     |   mux-   |-----|  parent- |-----| dev D1 |
 Parent-locked mux as parent of mux-locked mux
 ---------------------------------------------
-This is a good topology.
+This is a good topology::
                    .----------.     .----------.     .--------.
     .--------.     |  parent- |-----|   mux-   |-----| dev D1 |
 Two mux-locked sibling muxes
 ----------------------------
-This is a good topology.
+This is a good topology::
                                     .--------.
                    .----------.  .--| dev D1 |
 Two parent-locked sibling muxes
 -------------------------------
-This is a good topology.
+This is a good topology::
                                     .--------.
                    .----------.  .--| dev D1 |
 Mux-locked and parent-locked sibling muxes
 ------------------------------------------
-This is a good topology.
+This is a good topology::
                                     .--------.
                    .----------.  .--| dev D1 |

Documentation/i2c/index.rst+37−0

@@ -0,0 +1,37 @@
	1	. SPDX-License-Identifier: GPL-2.0
	2
	3	===================
	4	I2C/SMBus Subsystem
	5	===================
	6
	7	.. toctree::
	8	:maxdepth: 1
	9
	10	dev-interface
	11	dma-considerations
	12	fault-codes
	13	functionality
	14	gpio-fault-injection
	15	i2c-protocol
	16	i2c-stub
	17	i2c-topology
	18	instantiating-devices
	19	old-module-parameters
	20	slave-eeprom-backend
	21	slave-interface
	22	smbus-protocol
	23	summary
	24	ten-bit-addresses
	25	upgrading-clients
	26	writing-clients
	27
	28	muxes/i2c-mux-gpio
	29
	30	busses/index
	31
	32	.. only:: subproject and html
	33
	34	Indices
	35	=======
	36
	37	* :ref:`genindex`

Documentation/i2c/instantiating-devices.rstrenamed from Documentation/i2c/instantiating-devices+25−20

Documentation/i2c/muxes/i2c-mux-gpio.rstrenamed from Documentation/i2c/muxes/i2c-mux-gpio+14−12

+==========================
 Kernel driver i2c-mux-gpio
+==========================
 Author: Peter Korsgaard <peter.korsgaard@barco.com>
 i2c-mux-gpio is an i2c mux driver providing access to I2C bus segments
 from a master I2C bus and a hardware MUX controlled through GPIO pins.
-E.G.:
+E.G.::
   ----------              ----------  Bus segment 1   - - - - -
  |          | SCL/SDA    |          |-------------- |           |
 to control it. See include/linux/platform_data/i2c-mux-gpio.h for details.
 E.G. something like this for a MUX providing 4 bus segments
-controlled through 3 GPIO pins:
+controlled through 3 GPIO pins::
-#include <linux/platform_data/i2c-mux-gpio.h>
+  #include <linux/platform_data/i2c-mux-gpio.h>
-#include <linux/platform_device.h>
+  #include <linux/platform_device.h>
-static const unsigned myboard_gpiomux_gpios[] = {
+  static const unsigned myboard_gpiomux_gpios[] = {
 	AT91_PIN_PC26, AT91_PIN_PC25, AT91_PIN_PC24
-};
+  };
-static const unsigned myboard_gpiomux_values[] = {
+  static const unsigned myboard_gpiomux_values[] = {
 	0, 1, 2, 3
-};
+  };
-static struct i2c_mux_gpio_platform_data myboard_i2cmux_data = {
+  static struct i2c_mux_gpio_platform_data myboard_i2cmux_data = {
 	.parent		= 1,
 	.base_nr	= 2, /* optional */
 	.values		= myboard_gpiomux_values,
 	.gpios		= myboard_gpiomux_gpios,
 	.n_gpios	= ARRAY_SIZE(myboard_gpiomux_gpios),
 	.idle		= 4, /* optional */
-};
+  };
-static struct platform_device myboard_i2cmux = {
+  static struct platform_device myboard_i2cmux = {
 	.name		= "i2c-mux-gpio",
 	.id		= 0,
 	.dev		= {
 		.platform_data	= &myboard_i2cmux_data,
 	},
-};
+  };
 If you don't know the absolute GPIO pin numbers at registration time,
 you can instead provide a chip name (.chip_name) and relative GPIO pin

Documentation/i2c/old-module-parameters.rstrenamed from Documentation/i2c/old-module-parameters+16−11

@@ -1,3 +1,4 @@
		1	=================================================
1	I2C device driver binding control from user-space	2	I2C device driver binding control from user-space
2	=================================================	3	=================================================
3		4
@@ -19,23 +20,27 @@ Below is a mapping from the old module parameters to the new interface. · 15 unmodified lines
19	Attaching a driver to an I2C device	20	Attaching a driver to an I2C device
20	-----------------------------------	21	-----------------------------------
21		22
22	Old method (module parameters):	23	Old method (module parameters)::
23	# modprobe <driver> probe=1,0x2d	24
24	# modprobe <driver> force=1,0x2d	25	# modprobe <driver> probe=1,0x2d
25	# modprobe <driver> force_<device>=1,0x2d	26	# modprobe <driver> force=1,0x2d
		27	# modprobe <driver> force_<device>=1,0x2d
		28
		29	New method (sysfs interface)::
26		30
27	New method (sysfs interface):	31	# echo <device> 0x2d > /sys/bus/i2c/devices/i2c-1/new_device
28	# echo <device> 0x2d > /sys/bus/i2c/devices/i2c-1/new_device
29		32
30	Preventing a driver from attaching to an I2C device	33	Preventing a driver from attaching to an I2C device
31	---------------------------------------------------	34	---------------------------------------------------
32		35
33	Old method (module parameters):	36	Old method (module parameters)::
34	# modprobe <driver> ignore=1,0x2f	37
		38	# modprobe <driver> ignore=1,0x2f
		39
		40	New method (sysfs interface)::
35		41
36	New method (sysfs interface):	42	# echo dummy 0x2f > /sys/bus/i2c/devices/i2c-1/new_device
37	# echo dummy 0x2f > /sys/bus/i2c/devices/i2c-1/new_device	43	# modprobe <driver>
38	# modprobe <driver>
39		44
40	Of course, it is important to instantiate the "dummy" device before loading	45	Of course, it is important to instantiate the "dummy" device before loading
41	the driver. The dummy device will be handled by i2c-core itself, preventing	46	the driver. The dummy device will be handled by i2c-core itself, preventing

Documentation/i2c/slave-eeprom-backend.rstrenamed from Documentation/i2c/slave-eeprom-backend+2−2

@@ -1,3 +1,4 @@
		1	==============================
1	Linux I2C slave eeprom backend	2	Linux I2C slave eeprom backend
2	==============================	3	==============================
3		4
@@ -5,10 +6,9 @@ by Wolfram Sang <wsa@sang-engineering.com> in 2014-15 · 1 unmodified line
5		6
6	This is a proof-of-concept backend which acts like an EEPROM on the connected	7	This is a proof-of-concept backend which acts like an EEPROM on the connected
7	I2C bus. The memory contents can be modified from userspace via this file	8	I2C bus. The memory contents can be modified from userspace via this file
8	located in sysfs:	9	located in sysfs::
9		10
10	/sys/bus/i2c/devices/<device-directory>/slave-eeprom	11	/sys/bus/i2c/devices/<device-directory>/slave-eeprom
11		12
12	As of 2015, Linux doesn't support poll on binary sysfs files, so there is no	13	As of 2015, Linux doesn't support poll on binary sysfs files, so there is no
13	notification when another master changed the content.	14	notification when another master changed the content.
14

Documentation/i2c/slave-interface.rstrenamed from Documentation/i2c/slave-interface+19−14

@@ -1,3 +1,4 @@
		1	=====================================
1	Linux I2C slave interface description	2	Linux I2C slave interface description
2	=====================================	3	=====================================
3		4
@@ -12,7 +13,7 @@ EEPROM, the Linux I2C slave can access the content via sysfs and handle data as · 8 unmodified lines
12	needed. The backend driver and the I2C bus driver communicate via events. Here	13	needed. The backend driver and the I2C bus driver communicate via events. Here
13	is a small graph visualizing the data flow and the means by which data is	14	is a small graph visualizing the data flow and the means by which data is
14	transported. The dotted line marks only one example. The backend could also	15	transported. The dotted line marks only one example. The backend could also
15	use a character device, be in-kernel only, or something completely different:	16	use a character device, be in-kernel only, or something completely different::
16		17
17		18
18	e.g. sysfs I2C slave events I/O registers	19	e.g. sysfs I2C slave events I/O registers
@@ -35,7 +36,7 @@ them as described in the document 'instantiating-devices'. The only difference · 16 unmodified lines
35	is that i2c slave backends have their own address space. So, you have to add	36	is that i2c slave backends have their own address space. So, you have to add
36	0x1000 to the address you would originally request. An example for	37	0x1000 to the address you would originally request. An example for
37	instantiating the slave-eeprom driver from userspace at the 7 bit address 0x64	38	instantiating the slave-eeprom driver from userspace at the 7 bit address 0x64
38	on bus 1:	39	on bus 1::
39		40
40	# echo slave-24c02 0x1064 > /sys/bus/i2c/devices/i2c-1/new_device	41	# echo slave-24c02 0x1064 > /sys/bus/i2c/devices/i2c-1/new_device
41		42
@@ -54,7 +55,7 @@ drivers and writing backends will be given. · 12 unmodified lines
54	I2C slave events	55	I2C slave events
55	----------------	56	----------------
56		57
57	The bus driver sends an event to the backend using the following function:	58	The bus driver sends an event to the backend using the following function::
58		59
59	ret = i2c_slave_event(client, event, &val)	60	ret = i2c_slave_event(client, event, &val)
60		61
@@ -69,8 +70,9 @@ Event types: · 8 unmodified lines
69		70
70	* I2C_SLAVE_WRITE_REQUESTED (mandatory)	71	* I2C_SLAVE_WRITE_REQUESTED (mandatory)
71		72
72	'val': unused	73	'val': unused
73	'ret': always 0	74
		75	'ret': always 0
74		76
75	Another I2C master wants to write data to us. This event should be sent once	77	Another I2C master wants to write data to us. This event should be sent once
76	our own address and the write bit was detected. The data did not arrive yet, so	78	our own address and the write bit was detected. The data did not arrive yet, so
@@ -79,8 +81,9 @@ to be done, though. · 2 unmodified lines
79		81
80	* I2C_SLAVE_READ_REQUESTED (mandatory)	82	* I2C_SLAVE_READ_REQUESTED (mandatory)
81		83
82	'val': backend returns first byte to be sent	84	'val': backend returns first byte to be sent
83	'ret': always 0	85
		86	'ret': always 0
84		87
85	Another I2C master wants to read data from us. This event should be sent once	88	Another I2C master wants to read data from us. This event should be sent once
86	our own address and the read bit was detected. After returning, the bus driver	89	our own address and the read bit was detected. After returning, the bus driver
@@ -88,8 +91,9 @@ should transmit the first byte. · 1 unmodified line
88		91
89	* I2C_SLAVE_WRITE_RECEIVED (mandatory)	92	* I2C_SLAVE_WRITE_RECEIVED (mandatory)
90		93
91	'val': bus driver delivers received byte	94	'val': bus driver delivers received byte
92	'ret': 0 if the byte should be acked, some errno if the byte should be nacked	95
		96	'ret': 0 if the byte should be acked, some errno if the byte should be nacked
93		97
94	Another I2C master has sent a byte to us which needs to be set in 'val'. If 'ret'	98	Another I2C master has sent a byte to us which needs to be set in 'val'. If 'ret'
95	is zero, the bus driver should ack this byte. If 'ret' is an errno, then the byte	99	is zero, the bus driver should ack this byte. If 'ret' is an errno, then the byte
@@ -97,8 +101,9 @@ should be nacked. · 1 unmodified line
97		101
98	* I2C_SLAVE_READ_PROCESSED (mandatory)	102	* I2C_SLAVE_READ_PROCESSED (mandatory)
99		103
100	'val': backend returns next byte to be sent	104	'val': backend returns next byte to be sent
101	'ret': always 0	105
		106	'ret': always 0
102		107
103	The bus driver requests the next byte to be sent to another I2C master in	108	The bus driver requests the next byte to be sent to another I2C master in
104	'val'. Important: This does not mean that the previous byte has been acked, it	109	'val'. Important: This does not mean that the previous byte has been acked, it
@@ -111,8 +116,9 @@ your backend, though. · 6 unmodified lines
111		116
112	* I2C_SLAVE_STOP (mandatory)	117	* I2C_SLAVE_STOP (mandatory)
113		118
114	'val': unused	119	'val': unused
115	'ret': always 0	120
		121	'ret': always 0
116		122
117	A stop condition was received. This can happen anytime and the backend should	123	A stop condition was received. This can happen anytime and the backend should
118	reset its state machine for I2C transfers to be able to receive new requests.	124	reset its state machine for I2C transfers to be able to receive new requests.
@@ -190,4 +196,3 @@ this time of writing. Some points to keep in mind when using buffers: · 71 unmodified lines
190	* A master can send STOP at any time. For partially transferred buffers, this	196	* A master can send STOP at any time. For partially transferred buffers, this
191	means additional code to handle this exception. Such code tends to be	197	means additional code to handle this exception. Such code tends to be
192	error-prone.	198	error-prone.
193

Documentation/i2c/smbus-protocol.rstrenamed from Documentation/i2c/smbus-protocol+52−34

@@ -1,3 +1,4 @@
		1	======================
1	SMBus Protocol Summary	2	SMBus Protocol Summary
2	======================	3	======================
3		4
@@ -27,17 +28,18 @@ Each transaction type corresponds to a functionality flag. Before calling a · 23 unmodified lines
27	transaction function, a device driver should always check (just once) for	28	transaction function, a device driver should always check (just once) for
28	the corresponding functionality flag to ensure that the underlying I2C	29	the corresponding functionality flag to ensure that the underlying I2C
29	adapter supports the transaction in question. See	30	adapter supports the transaction in question. See
30	<file:Documentation/i2c/functionality> for the details.	31	<file:Documentation/i2c/functionality.rst> for the details.
31		32
32		33
33	Key to symbols	34	Key to symbols
34	==============	35	==============
35		36
		37	=============== =============================================================
36	S (1 bit) : Start bit	38	S (1 bit) : Start bit
37	P (1 bit) : Stop bit	39	P (1 bit) : Stop bit
38	Rd/Wr (1 bit) : Read/Write bit. Rd equals 1, Wr equals 0.	40	Rd/Wr (1 bit) : Read/Write bit. Rd equals 1, Wr equals 0.
39	A, NA (1 bit) : Accept and reverse accept bit.	41	A, NA (1 bit) : Accept and reverse accept bit.
40	Addr (7 bits): I2C 7 bit address. Note that this can be expanded as usual to	42	Addr (7 bits): I2C 7 bit address. Note that this can be expanded as usual to
41	get a 10 bit I2C address.	43	get a 10 bit I2C address.
42	Comm (8 bits): Command byte, a data byte which often selects a register on	44	Comm (8 bits): Command byte, a data byte which often selects a register on
43	the device.	45	the device.
@@ -45,15 +47,17 @@ Data (8 bits): A plain data byte. Sometimes, I write DataLow, DataHigh · 1 unmodified line
45	for 16 bit data.	47	for 16 bit data.
46	Count (8 bits): A data byte containing the length of a block operation.	48	Count (8 bits): A data byte containing the length of a block operation.
47		49
48	[..]: Data sent by I2C device, as opposed to data sent by the host adapter.	50	[..]: Data sent by I2C device, as opposed to data sent by the host
		51	adapter.
		52	=============== =============================================================
49		53
50		54
51	SMBus Quick Command	55	SMBus Quick Command
52	===================	56	===================
53		57
54	This sends a single bit to the device, at the place of the Rd/Wr bit.	58	This sends a single bit to the device, at the place of the Rd/Wr bit::
55		59
56	A Addr Rd/Wr [A] P	60	A Addr Rd/Wr [A] P
57		61
58	Functionality flag: I2C_FUNC_SMBUS_QUICK	62	Functionality flag: I2C_FUNC_SMBUS_QUICK
59		63
@@ -64,9 +68,9 @@ SMBus Receive Byte: i2c_smbus_read_byte() · 4 unmodified lines
64	This reads a single byte from a device, without specifying a device	68	This reads a single byte from a device, without specifying a device
65	register. Some devices are so simple that this interface is enough; for	69	register. Some devices are so simple that this interface is enough; for
66	others, it is a shorthand if you want to read the same register as in	70	others, it is a shorthand if you want to read the same register as in
67	the previous SMBus command.	71	the previous SMBus command::
68		72
69	S Addr Rd [A] [Data] NA P	73	S Addr Rd [A] [Data] NA P
70		74
71	Functionality flag: I2C_FUNC_SMBUS_READ_BYTE	75	Functionality flag: I2C_FUNC_SMBUS_READ_BYTE
72		76
@@ -77,7 +81,9 @@ SMBus Send Byte: i2c_smbus_write_byte() · 4 unmodified lines
77	This operation is the reverse of Receive Byte: it sends a single byte	81	This operation is the reverse of Receive Byte: it sends a single byte
78	to a device. See Receive Byte for more information.	82	to a device. See Receive Byte for more information.
79		83
80	S Addr Wr [A] Data [A] P	84	::
		85
		86	S Addr Wr [A] Data [A] P
81		87
82	Functionality flag: I2C_FUNC_SMBUS_WRITE_BYTE	88	Functionality flag: I2C_FUNC_SMBUS_WRITE_BYTE
83		89
@@ -86,9 +92,9 @@ SMBus Read Byte: i2c_smbus_read_byte_data() · 2 unmodified lines
86	============================================	92	============================================
87		93
88	This reads a single byte from a device, from a designated register.	94	This reads a single byte from a device, from a designated register.
89	The register is specified through the Comm byte.	95	The register is specified through the Comm byte::
90		96
91	S Addr Wr [A] Comm [A] S Addr Rd [A] [Data] NA P	97	S Addr Wr [A] Comm [A] S Addr Rd [A] [Data] NA P
92		98
93	Functionality flag: I2C_FUNC_SMBUS_READ_BYTE_DATA	99	Functionality flag: I2C_FUNC_SMBUS_READ_BYTE_DATA
94		100
@@ -98,9 +104,9 @@ SMBus Read Word: i2c_smbus_read_word_data() · 3 unmodified lines
98		104
99	This operation is very like Read Byte; again, data is read from a	105	This operation is very like Read Byte; again, data is read from a
100	device, from a designated register that is specified through the Comm	106	device, from a designated register that is specified through the Comm
101	byte. But this time, the data is a complete word (16 bits).	107	byte. But this time, the data is a complete word (16 bits)::
102		108
103	S Addr Wr [A] Comm [A] S Addr Rd [A] [DataLow] A [DataHigh] NA P	109	S Addr Wr [A] Comm [A] S Addr Rd [A] [DataLow] A [DataHigh] NA P
104		110
105	Functionality flag: I2C_FUNC_SMBUS_READ_WORD_DATA	111	Functionality flag: I2C_FUNC_SMBUS_READ_WORD_DATA
106		112
@@ -116,7 +122,9 @@ This writes a single byte to a device, to a designated register. The · 9 unmodified lines
116	register is specified through the Comm byte. This is the opposite of	122	register is specified through the Comm byte. This is the opposite of
117	the Read Byte operation.	123	the Read Byte operation.
118		124
119	S Addr Wr [A] Comm [A] Data [A] P	125	::
		126
		127	S Addr Wr [A] Comm [A] Data [A] P
120		128
121	Functionality flag: I2C_FUNC_SMBUS_WRITE_BYTE_DATA	129	Functionality flag: I2C_FUNC_SMBUS_WRITE_BYTE_DATA
122		130
@@ -126,9 +134,9 @@ SMBus Write Word: i2c_smbus_write_word_data() · 3 unmodified lines
126		134
127	This is the opposite of the Read Word operation. 16 bits	135	This is the opposite of the Read Word operation. 16 bits
128	of data is written to a device, to the designated register that is	136	of data is written to a device, to the designated register that is
129	specified through the Comm byte.	137	specified through the Comm byte.::
130		138
131	S Addr Wr [A] Comm [A] DataLow [A] DataHigh [A] P	139	S Addr Wr [A] Comm [A] DataLow [A] DataHigh [A] P
132		140
133	Functionality flag: I2C_FUNC_SMBUS_WRITE_WORD_DATA	141	Functionality flag: I2C_FUNC_SMBUS_WRITE_WORD_DATA
134		142
@@ -141,10 +149,10 @@ SMBus Process Call: · 6 unmodified lines
141	===================	149	===================
142		150
143	This command selects a device register (through the Comm byte), sends	151	This command selects a device register (through the Comm byte), sends
144	16 bits of data to it, and reads 16 bits of data in return.	152	16 bits of data to it, and reads 16 bits of data in return::
145		153
146	S Addr Wr [A] Comm [A] DataLow [A] DataHigh [A]	154	S Addr Wr [A] Comm [A] DataLow [A] DataHigh [A]
147	S Addr Rd [A] [DataLow] A [DataHigh] NA P	155	S Addr Rd [A] [DataLow] A [DataHigh] NA P
148		156
149	Functionality flag: I2C_FUNC_SMBUS_PROC_CALL	157	Functionality flag: I2C_FUNC_SMBUS_PROC_CALL
150		158
@@ -152,12 +160,14 @@ Functionality flag: I2C_FUNC_SMBUS_PROC_CALL · 1 unmodified line
152	SMBus Block Read: i2c_smbus_read_block_data()	160	SMBus Block Read: i2c_smbus_read_block_data()
153	==============================================	161	==============================================
154		162
155	This command reads a block of up to 32 bytes from a device, from a	163	This command reads a block of up to 32 bytes from a device, from a
156	designated register that is specified through the Comm byte. The amount	164	designated register that is specified through the Comm byte. The amount
157	of data is specified by the device in the Count byte.	165	of data is specified by the device in the Count byte.
158		166
159	S Addr Wr [A] Comm [A]	167	::
160	S Addr Rd [A] [Count] A [Data] A [Data] A ... A [Data] NA P	168
		169	S Addr Wr [A] Comm [A]
		170	S Addr Rd [A] [Count] A [Data] A [Data] A ... A [Data] NA P
161		171
162	Functionality flag: I2C_FUNC_SMBUS_READ_BLOCK_DATA	172	Functionality flag: I2C_FUNC_SMBUS_READ_BLOCK_DATA
163		173
@@ -165,11 +175,13 @@ Functionality flag: I2C_FUNC_SMBUS_READ_BLOCK_DATA · 1 unmodified line
165	SMBus Block Write: i2c_smbus_write_block_data()	175	SMBus Block Write: i2c_smbus_write_block_data()
166	================================================	176	================================================
167		177
168	The opposite of the Block Read command, this writes up to 32 bytes to	178	The opposite of the Block Read command, this writes up to 32 bytes to
169	a device, to a designated register that is specified through the	179	a device, to a designated register that is specified through the
170	Comm byte. The amount of data is specified in the Count byte.	180	Comm byte. The amount of data is specified in the Count byte.
171		181
172	S Addr Wr [A] Comm [A] Count [A] Data [A] Data [A] ... [A] Data [A] P	182	::
		183
		184	S Addr Wr [A] Comm [A] Count [A] Data [A] Data [A] ... [A] Data [A] P
173		185
174	Functionality flag: I2C_FUNC_SMBUS_WRITE_BLOCK_DATA	186	Functionality flag: I2C_FUNC_SMBUS_WRITE_BLOCK_DATA
175		187
@@ -181,10 +193,10 @@ SMBus Block Write - Block Read Process Call was introduced in · 5 unmodified lines
181	Revision 2.0 of the specification.	193	Revision 2.0 of the specification.
182		194
183	This command selects a device register (through the Comm byte), sends	195	This command selects a device register (through the Comm byte), sends
184	1 to 31 bytes of data to it, and reads 1 to 31 bytes of data in return.	196	1 to 31 bytes of data to it, and reads 1 to 31 bytes of data in return::
185		197
186	S Addr Wr [A] Comm [A] Count [A] Data [A] ...	198	S Addr Wr [A] Comm [A] Count [A] Data [A] ...
187	S Addr Rd [A] [Count] A [Data] ... A P	199	S Addr Rd [A] [Count] A [Data] ... A P
188		200
189	Functionality flag: I2C_FUNC_SMBUS_BLOCK_PROC_CALL	201	Functionality flag: I2C_FUNC_SMBUS_BLOCK_PROC_CALL
190		202
@@ -197,9 +209,12 @@ SMBus host acting as a slave. · 6 unmodified lines
197	It is the same form as Write Word, with the command code replaced by the	209	It is the same form as Write Word, with the command code replaced by the
198	alerting device's address.	210	alerting device's address.
199		211
200	[S] [HostAddr] [Wr] A [DevAddr] A [DataLow] A [DataHigh] A [P]	212	::
		213
		214	[S] [HostAddr] [Wr] A [DevAddr] A [DataLow] A [DataHigh] A [P]
201		215
202	This is implemented in the following way in the Linux kernel:	216	This is implemented in the following way in the Linux kernel:
		217
203	* I2C bus drivers which support SMBus Host Notify should report	218	* I2C bus drivers which support SMBus Host Notify should report
204	I2C_FUNC_SMBUS_HOST_NOTIFY.	219	I2C_FUNC_SMBUS_HOST_NOTIFY.
205	* I2C bus drivers trigger SMBus Host Notify by a call to	220	* I2C bus drivers trigger SMBus Host Notify by a call to
@@ -241,6 +256,7 @@ single interrupt pin on the SMBus master, while still allowing the master · 35 unmodified lines
241	to know which slave triggered the interrupt.	256	to know which slave triggered the interrupt.
242		257
243	This is implemented the following way in the Linux kernel:	258	This is implemented the following way in the Linux kernel:
		259
244	* I2C bus drivers which support SMBus alert should call	260	* I2C bus drivers which support SMBus alert should call
245	i2c_setup_smbus_alert() to setup SMBus alert support.	261	i2c_setup_smbus_alert() to setup SMBus alert support.
246	* I2C drivers for devices which can trigger SMBus alerts should implement	262	* I2C drivers for devices which can trigger SMBus alerts should implement
@@ -261,11 +277,11 @@ but the SMBus layer places a limit of 32 bytes. · 14 unmodified lines
261	I2C Block Read: i2c_smbus_read_i2c_block_data()	277	I2C Block Read: i2c_smbus_read_i2c_block_data()
262	================================================	278	================================================
263		279
264	This command reads a block of bytes from a device, from a	280	This command reads a block of bytes from a device, from a
265	designated register that is specified through the Comm byte.	281	designated register that is specified through the Comm byte::
266		282
267	S Addr Wr [A] Comm [A]	283	S Addr Wr [A] Comm [A]
268	S Addr Rd [A] [Data] A [Data] A ... A [Data] NA P	284	S Addr Rd [A] [Data] A [Data] A ... A [Data] NA P
269		285
270	Functionality flag: I2C_FUNC_SMBUS_READ_I2C_BLOCK	286	Functionality flag: I2C_FUNC_SMBUS_READ_I2C_BLOCK
271		287
@@ -273,11 +289,13 @@ Functionality flag: I2C_FUNC_SMBUS_READ_I2C_BLOCK · 1 unmodified line
273	I2C Block Write: i2c_smbus_write_i2c_block_data()	289	I2C Block Write: i2c_smbus_write_i2c_block_data()
274	==================================================	290	==================================================
275		291
276	The opposite of the Block Read command, this writes bytes to	292	The opposite of the Block Read command, this writes bytes to
277	a device, to a designated register that is specified through the	293	a device, to a designated register that is specified through the
278	Comm byte. Note that command lengths of 0, 2, or more bytes are	294	Comm byte. Note that command lengths of 0, 2, or more bytes are
279	supported as they are indistinguishable from data.	295	supported as they are indistinguishable from data.
280		296
281	S Addr Wr [A] Comm [A] Data [A] Data [A] ... [A] Data [A] P	297	::
		298
		299	S Addr Wr [A] Comm [A] Data [A] Data [A] ... [A] Data [A] P
282		300
283	Functionality flag: I2C_FUNC_SMBUS_WRITE_I2C_BLOCK	301	Functionality flag: I2C_FUNC_SMBUS_WRITE_I2C_BLOCK

Documentation/i2c/summary.rstrenamed from Documentation/i2c/summary+4−2

+=============
 I2C and SMBus
 =============
 I2C (pronounce: I squared C) is a protocol developed by Philips. It is a
 slow two-wire protocol (variable speed, up to 400 kHz), with a high speed
 extension (3.4 MHz).  It provides an inexpensive bus for connecting many
 types of devices with infrequent or low bandwidth communications needs.
 Terminology
 ===========
-When we talk about I2C, we use the following terms:
+When we talk about I2C, we use the following terms::
   Bus    -> Algorithm
             Adapter
   Device -> Driver

Documentation/i2c/ten-bit-addresses.rstrenamed from Documentation/i2c/ten-bit-addresses+5−0

+=====================
+I2C Ten-bit Addresses
+=====================
 The I2C protocol knows about two kinds of device addresses: normal 7 bit
 addresses, and an extended set of 10 bit addresses. The sets of addresses
 do not intersect: the 7 bit address 0x10 is not the same as the 10 bit
 The current 10 bit address support is minimal. It should work, however
 you can expect some problems along the way:
 * Not all bus drivers support 10-bit addresses. Some don't because the
   hardware doesn't support them (SMBus doesn't require 10-bit address
   support for example), some don't because nobody bothered adding the

Documentation/i2c/upgrading-clients.rstrenamed from Documentation/i2c/upgrading-clients+105−99

@@ -1,3 +1,4 @@
		1	=================================================
1	Upgrading I2C Drivers to the new 2.6 Driver Model	2	Upgrading I2C Drivers to the new 2.6 Driver Model
2	=================================================	3	=================================================
3		4
@@ -13,21 +14,22 @@ the old to the new new binding methods. · 9 unmodified lines
13	Example old-style driver	14	Example old-style driver
14	------------------------	15	------------------------
15		16
		17	::
16		18
17	struct example_state {	19	struct example_state {
18	struct i2c_client client;	20	struct i2c_client client;
19	....	21	....
20	};	22	};
21		23
22	static struct i2c_driver example_driver;	24	static struct i2c_driver example_driver;
23		25
24	static unsigned short ignore[] = { I2C_CLIENT_END };	26	static unsigned short ignore[] = { I2C_CLIENT_END };
25	static unsigned short normal_addr[] = { OUR_ADDR, I2C_CLIENT_END };	27	static unsigned short normal_addr[] = { OUR_ADDR, I2C_CLIENT_END };
26		28
27	I2C_CLIENT_INSMOD;	29	I2C_CLIENT_INSMOD;
28		30
29	static int example_attach(struct i2c_adapter *adap, int addr, int kind)	31	static int example_attach(struct i2c_adapter *adap, int addr, int kind)
30	{	32	{
31	struct example_state *state;	33	struct example_state *state;
32	struct device dev = &adap->dev; / to use for dev_ reports */	34	struct device dev = &adap->dev; / to use for dev_ reports */
33	int ret;	35	int ret;
@@ -59,31 +61,31 @@ static int example_attach(struct i2c_adapter *adap, int addr, int kind) · 25 unmodified lines
59	dev_info(dev, "example client created\n");	61	dev_info(dev, "example client created\n");
60		62
61	return 0;	63	return 0;
62	}	64	}
63		65
64	static int example_detach(struct i2c_client *client)	66	static int example_detach(struct i2c_client *client)
65	{	67	{
66	struct example_state *state = i2c_get_clientdata(client);	68	struct example_state *state = i2c_get_clientdata(client);
67		69
68	i2c_detach_client(client);	70	i2c_detach_client(client);
69	kfree(state);	71	kfree(state);
70	return 0;	72	return 0;
71	}	73	}
72		74
73	static int example_attach_adapter(struct i2c_adapter *adap)	75	static int example_attach_adapter(struct i2c_adapter *adap)
74	{	76	{
75	return i2c_probe(adap, &addr_data, example_attach);	77	return i2c_probe(adap, &addr_data, example_attach);
76	}	78	}
77		79
78	static struct i2c_driver example_driver = {	80	static struct i2c_driver example_driver = {
79	.driver = {	81	.driver = {
80	.owner = THIS_MODULE,	82	.owner = THIS_MODULE,
81	.name = "example",	83	.name = "example",
82	.pm = &example_pm_ops,	84	.pm = &example_pm_ops,
83	},	85	},
84	.attach_adapter = example_attach_adapter,	86	.attach_adapter = example_attach_adapter,
85	.detach_client = example_detach,	87	.detach_client = example_detach,
86	};	88	};
87		89
88		90
89	Updating the client	91	Updating the client
@@ -93,38 +95,38 @@ The new style binding model will check against a list of supported · 3 unmodified lines
93	devices and their associated address supplied by the code registering	95	devices and their associated address supplied by the code registering
94	the busses. This means that the driver .attach_adapter and	96	the busses. This means that the driver .attach_adapter and
95	.detach_client methods can be removed, along with the addr_data,	97	.detach_client methods can be removed, along with the addr_data,
96	as follows:	98	as follows::
97		99
98	- static struct i2c_driver example_driver;	100	- static struct i2c_driver example_driver;
99		101
100	- static unsigned short ignore[] = { I2C_CLIENT_END };	102	- static unsigned short ignore[] = { I2C_CLIENT_END };
101	- static unsigned short normal_addr[] = { OUR_ADDR, I2C_CLIENT_END };	103	- static unsigned short normal_addr[] = { OUR_ADDR, I2C_CLIENT_END };
102		104
103	- I2C_CLIENT_INSMOD;	105	- I2C_CLIENT_INSMOD;
104		106
105	- static int example_attach_adapter(struct i2c_adapter *adap)	107	- static int example_attach_adapter(struct i2c_adapter *adap)
106	- {	108	- {
107	- return i2c_probe(adap, &addr_data, example_attach);	109	- return i2c_probe(adap, &addr_data, example_attach);
108	- }	110	- }
109		111
110	static struct i2c_driver example_driver = {	112	static struct i2c_driver example_driver = {
111	- .attach_adapter = example_attach_adapter,	113	- .attach_adapter = example_attach_adapter,
112	- .detach_client = example_detach,	114	- .detach_client = example_detach,
113	}	115	}
114		116
115	Add the probe and remove methods to the i2c_driver, as so:	117	Add the probe and remove methods to the i2c_driver, as so::
116		118
117	static struct i2c_driver example_driver = {	119	static struct i2c_driver example_driver = {
118	+ .probe = example_probe,	120	+ .probe = example_probe,
119	+ .remove = example_remove,	121	+ .remove = example_remove,
120	}	122	}
121		123
122	Change the example_attach method to accept the new parameters	124	Change the example_attach method to accept the new parameters
123	which include the i2c_client that it will be working with:	125	which include the i2c_client that it will be working with::
124		126
125	- static int example_attach(struct i2c_adapter *adap, int addr, int kind)	127	- static int example_attach(struct i2c_adapter *adap, int addr, int kind)
126	+ static int example_probe(struct i2c_client *client,	128	+ static int example_probe(struct i2c_client *client,
127	+ const struct i2c_device_id *id)	129	+ const struct i2c_device_id *id)
128		130
129	Change the name of example_attach to example_probe to align it with the	131	Change the name of example_attach to example_probe to align it with the
130	i2c_driver entry names. The rest of the probe routine will now need to be	132	i2c_driver entry names. The rest of the probe routine will now need to be
@@ -132,57 +134,59 @@ changed as the i2c_client has already been setup for use. · 1 unmodified line
132		134
133	The necessary client fields have already been setup before	135	The necessary client fields have already been setup before
134	the probe function is called, so the following client setup	136	the probe function is called, so the following client setup
135	can be removed:	137	can be removed::
136		138
137	- example->client.addr = addr;	139	- example->client.addr = addr;
138	- example->client.flags = 0;	140	- example->client.flags = 0;
139	- example->client.adapter = adap;	141	- example->client.adapter = adap;
140	-	142	-
141	- strscpy(client->i2c_client.name, "example", sizeof(client->i2c_client.name));	143	- strscpy(client->i2c_client.name, "example", sizeof(client->i2c_client.name));
142		144
143	The i2c_set_clientdata is now:	145	The i2c_set_clientdata is now::
144		146
145	- i2c_set_clientdata(&state->client, state);	147	- i2c_set_clientdata(&state->client, state);
146	+ i2c_set_clientdata(client, state);	148	+ i2c_set_clientdata(client, state);
147		149
148	The call to i2c_attach_client is no longer needed, if the probe	150	The call to i2c_attach_client is no longer needed, if the probe
149	routine exits successfully, then the driver will be automatically	151	routine exits successfully, then the driver will be automatically
150	attached by the core. Change the probe routine as so:	152	attached by the core. Change the probe routine as so::
151		153
152	- ret = i2c_attach_client(&state->i2c_client);	154	- ret = i2c_attach_client(&state->i2c_client);
153	- if (ret < 0) {	155	- if (ret < 0) {
154	- dev_err(dev, "failed to attach client\n");	156	- dev_err(dev, "failed to attach client\n");
155	- kfree(state);	157	- kfree(state);
156	- return ret;	158	- return ret;
157	- }	159	- }
158		160
159		161
160	Remove the storage of 'struct i2c_client' from the 'struct example_state'	162	Remove the storage of 'struct i2c_client' from the 'struct example_state'
161	as we are provided with the i2c_client in our example_probe. Instead we	163	as we are provided with the i2c_client in our example_probe. Instead we
162	store a pointer to it for when it is needed.	164	store a pointer to it for when it is needed.
163		165
164	struct example_state {	166	::
165	- struct i2c_client client;	167
166	+ struct i2c_client *client;	168	struct example_state {
		169	- struct i2c_client client;
		170	+ struct i2c_client *client;
167		171
168	the new i2c client as so:	172	the new i2c client as so::
169		173
170	- struct device dev = &adap->dev; / to use for dev_ reports */	174	- struct device dev = &adap->dev; / to use for dev_ reports */
171	+ struct device dev = &i2c_client->dev; / to use for dev_ reports */	175	+ struct device dev = &i2c_client->dev; / to use for dev_ reports */
172		176
173	And remove the change after our client is attached, as the driver no	177	And remove the change after our client is attached, as the driver no
174	longer needs to register a new client structure with the core:	178	longer needs to register a new client structure with the core::
175		179
176	- dev = &state->i2c_client.dev;	180	- dev = &state->i2c_client.dev;
177		181
178	In the probe routine, ensure that the new state has the client stored	182	In the probe routine, ensure that the new state has the client stored
179	in it:	183	in it::
180		184
181	static int example_probe(struct i2c_client *i2c_client,	185	static int example_probe(struct i2c_client *i2c_client,
182	const struct i2c_device_id *id)	186	const struct i2c_device_id *id)
183	{	187	{
184	struct example_state *state;	188	struct example_state *state;
185	struct device *dev = &i2c_client->dev;	189	struct device *dev = &i2c_client->dev;
186	int ret;	190	int ret;
187		191
188	state = kzalloc(sizeof(struct example_state), GFP_KERNEL);	192	state = kzalloc(sizeof(struct example_state), GFP_KERNEL);
@@ -191,48 +195,50 @@ static int example_probe(struct i2c_client *i2c_client, · 2 unmodified lines
191	return -ENOMEM;	195	return -ENOMEM;
192	}	196	}
193		197
194	+ state->client = i2c_client;	198	+ state->client = i2c_client;
195		199
196	Update the detach method, by changing the name to _remove and	200	Update the detach method, by changing the name to _remove and
197	to delete the i2c_detach_client call. It is possible that you	201	to delete the i2c_detach_client call. It is possible that you
198	can also remove the ret variable as it is not needed for any	202	can also remove the ret variable as it is not needed for any
199	of the core functions.	203	of the core functions.
200		204
201	- static int example_detach(struct i2c_client *client)	205	::
202	+ static int example_remove(struct i2c_client *client)	206
203	{	207	- static int example_detach(struct i2c_client *client)
		208	+ static int example_remove(struct i2c_client *client)
		209	{
204	struct example_state *state = i2c_get_clientdata(client);	210	struct example_state *state = i2c_get_clientdata(client);
205		211
206	- i2c_detach_client(client);	212	- i2c_detach_client(client);
207		213
208	And finally ensure that we have the correct ID table for the i2c-core	214	And finally ensure that we have the correct ID table for the i2c-core
209	and other utilities:	215	and other utilities::
210		216
211	+ struct i2c_device_id example_idtable[] = {	217	+ struct i2c_device_id example_idtable[] = {
212	+ { "example", 0 },	218	+ { "example", 0 },
213	+ { }	219	+ { }
214	+};	220	+};
215	+	221	+
216	+MODULE_DEVICE_TABLE(i2c, example_idtable);	222	+MODULE_DEVICE_TABLE(i2c, example_idtable);
217		223
218	static struct i2c_driver example_driver = {	224	static struct i2c_driver example_driver = {
219	.driver = {	225	.driver = {
220	.owner = THIS_MODULE,	226	.owner = THIS_MODULE,
221	.name = "example",	227	.name = "example",
222	},	228	},
223	+ .id_table = example_ids,	229	+ .id_table = example_ids,
224		230
225		231
226	Our driver should now look like this:	232	Our driver should now look like this::
227		233
228	struct example_state {	234	struct example_state {
229	struct i2c_client *client;	235	struct i2c_client *client;
230	....	236	....
231	};	237	};
232		238
233	static int example_probe(struct i2c_client *client,	239	static int example_probe(struct i2c_client *client,
234	const struct i2c_device_id *id)	240	const struct i2c_device_id *id)
235	{	241	{
236	struct example_state *state;	242	struct example_state *state;
237	struct device *dev = &client->dev;	243	struct device *dev = &client->dev;
238		244
@@ -250,25 +256,25 @@ static int example_probe(struct i2c_client *client, · 11 unmodified lines
250	dev_info(dev, "example client created\n");	256	dev_info(dev, "example client created\n");
251		257
252	return 0;	258	return 0;
253	}	259	}
254		260
255	static int example_remove(struct i2c_client *client)	261	static int example_remove(struct i2c_client *client)
256	{	262	{
257	struct example_state *state = i2c_get_clientdata(client);	263	struct example_state *state = i2c_get_clientdata(client);
258		264
259	kfree(state);	265	kfree(state);
260	return 0;	266	return 0;
261	}	267	}
262		268
263	static struct i2c_device_id example_idtable[] = {	269	static struct i2c_device_id example_idtable[] = {
264	{ "example", 0 },	270	{ "example", 0 },
265	{ }	271	{ }
266	};	272	};
267		273
268	MODULE_DEVICE_TABLE(i2c, example_idtable);	274	MODULE_DEVICE_TABLE(i2c, example_idtable);
269		275
270	static struct i2c_driver example_driver = {	276	static struct i2c_driver example_driver = {
271	.driver = {	277	.driver = {
272	.owner = THIS_MODULE,	278	.owner = THIS_MODULE,
273	.name = "example",	279	.name = "example",
274	.pm = &example_pm_ops,	280	.pm = &example_pm_ops,
@@ -276,4 +282,4 @@ static struct i2c_driver example_driver = { · 1 unmodified line
276	.id_table = example_idtable,	282	.id_table = example_idtable,
277	.probe = example_probe,	283	.probe = example_probe,
278	.remove = example_remove,	284	.remove = example_remove,
279	};	285	};

Documentation/i2c/writing-clients.rstrenamed from Documentation/i2c/writing-clients+58−36

@@ -1,3 +1,7 @@
		1	===================
		2	Writing I2C Clients
		3	===================
		4
1	This is a small guide for those who want to write kernel drivers for I2C	5	This is a small guide for those who want to write kernel drivers for I2C
2	or SMBus devices, using Linux as the protocol host/master (not slave).	6	or SMBus devices, using Linux as the protocol host/master (not slave).
3		7
@@ -12,7 +16,7 @@ General remarks · 8 unmodified lines
12	Try to keep the kernel namespace as clean as possible. The best way to	16	Try to keep the kernel namespace as clean as possible. The best way to
13	do this is to use a unique prefix for all global symbols. This is	17	do this is to use a unique prefix for all global symbols. This is
14	especially important for exported symbols, but it is a good idea to do	18	especially important for exported symbols, but it is a good idea to do
15	it for non-exported symbols too. We will use the prefix `foo_' in this	19	it for non-exported symbols too. We will use the prefix ``foo_`` in this
16	tutorial.	20	tutorial.
17		21
18		22
@@ -25,15 +29,17 @@ routines, and should be zero-initialized except for fields with data you · 6 unmodified lines
25	provide. A client structure holds device-specific information like the	29	provide. A client structure holds device-specific information like the
26	driver model device node, and its I2C address.	30	driver model device node, and its I2C address.
27		31
28	static struct i2c_device_id foo_idtable[] = {	32	::
		33
		34	static struct i2c_device_id foo_idtable[] = {
29	{ "foo", my_id_for_foo },	35	{ "foo", my_id_for_foo },
30	{ "bar", my_id_for_bar },	36	{ "bar", my_id_for_bar },
31	{ }	37	{ }
32	};	38	};
33		39
34	MODULE_DEVICE_TABLE(i2c, foo_idtable);	40	MODULE_DEVICE_TABLE(i2c, foo_idtable);
35		41
36	static struct i2c_driver foo_driver = {	42	static struct i2c_driver foo_driver = {
37	.driver = {	43	.driver = {
38	.name = "foo",	44	.name = "foo",
39	.pm = &foo_pm_ops, /* optional */	45	.pm = &foo_pm_ops, /* optional */
@@ -49,7 +55,7 @@ static struct i2c_driver foo_driver = { · 9 unmodified lines
49		55
50	.shutdown = foo_shutdown, /* optional */	56	.shutdown = foo_shutdown, /* optional */
51	.command = foo_command, /* optional, deprecated */	57	.command = foo_command, /* optional, deprecated */
52	}	58	}
53		59
54	The name field is the driver name, and must not contain spaces. It	60	The name field is the driver name, and must not contain spaces. It
55	should match the module name (if the driver can be compiled as a module),	61	should match the module name (if the driver can be compiled as a module),
@@ -64,16 +70,18 @@ below. · 8 unmodified lines
64	Extra client data	70	Extra client data
65	=================	71	=================
66		72
67	Each client structure has a special `data' field that can point to any	73	Each client structure has a special ``data`` field that can point to any
68	structure at all. You should use this to keep device-specific data.	74	structure at all. You should use this to keep device-specific data.
69		75
		76	::
		77
70	/* store the value */	78	/* store the value */
71	void i2c_set_clientdata(struct i2c_client client, void data);	79	void i2c_set_clientdata(struct i2c_client client, void data);
72		80
73	/* retrieve the value */	81	/* retrieve the value */
74	void i2c_get_clientdata(const struct i2c_client client);	82	void i2c_get_clientdata(const struct i2c_client client);
75		83
76	Note that starting with kernel 2.6.34, you don't have to set the `data' field	84	Note that starting with kernel 2.6.34, you don't have to set the ``data`` field
77	to NULL in remove() or if probe() failed anymore. The i2c-core does this	85	to NULL in remove() or if probe() failed anymore. The i2c-core does this
78	automatically on these occasions. Those are also the only times the core will	86	automatically on these occasions. Those are also the only times the core will
79	touch this field.	87	touch this field.
@@ -92,25 +100,25 @@ but many chips have some kind of register-value idea that can easily · 12 unmodified lines
92	be encapsulated.	100	be encapsulated.
93		101
94	The below functions are simple examples, and should not be copied	102	The below functions are simple examples, and should not be copied
95	literally.	103	literally::
96		104
97	int foo_read_value(struct i2c_client *client, u8 reg)	105	int foo_read_value(struct i2c_client *client, u8 reg)
98	{	106	{
99	if (reg < 0x10) /* byte-sized register */	107	if (reg < 0x10) /* byte-sized register */
100	return i2c_smbus_read_byte_data(client, reg);	108	return i2c_smbus_read_byte_data(client, reg);
101	else /* word-sized register */	109	else /* word-sized register */
102	return i2c_smbus_read_word_data(client, reg);	110	return i2c_smbus_read_word_data(client, reg);
103	}	111	}
104		112
105	int foo_write_value(struct i2c_client *client, u8 reg, u16 value)	113	int foo_write_value(struct i2c_client *client, u8 reg, u16 value)
106	{	114	{
107	if (reg == 0x10) /* Impossible to write - driver error! */	115	if (reg == 0x10) /* Impossible to write - driver error! */
108	return -EINVAL;	116	return -EINVAL;
109	else if (reg < 0x10) /* byte-sized register */	117	else if (reg < 0x10) /* byte-sized register */
110	return i2c_smbus_write_byte_data(client, reg, value);	118	return i2c_smbus_write_byte_data(client, reg, value);
111	else /* word-sized register */	119	else /* word-sized register */
112	return i2c_smbus_write_word_data(client, reg, value);	120	return i2c_smbus_write_word_data(client, reg, value);
113	}	121	}
114		122
115		123
116	Probing and attaching	124	Probing and attaching
@@ -145,6 +153,8 @@ I2C device drivers using this binding model work just like any other · 28 unmodified lines
145	kind of driver in Linux: they provide a probe() method to bind to	153	kind of driver in Linux: they provide a probe() method to bind to
146	those devices, and a remove() method to unbind.	154	those devices, and a remove() method to unbind.
147		155
		156	::
		157
148	static int foo_probe(struct i2c_client *client,	158	static int foo_probe(struct i2c_client *client,
149	const struct i2c_device_id *id);	159	const struct i2c_device_id *id);
150	static int foo_remove(struct i2c_client *client);	160	static int foo_remove(struct i2c_client *client);
@@ -240,37 +250,41 @@ When the kernel is booted, or when your foo driver module is inserted, · 89 unmodified lines
240	you have to do some initializing. Fortunately, just registering the	250	you have to do some initializing. Fortunately, just registering the
241	driver module is usually enough.	251	driver module is usually enough.
242		252
243	static int __init foo_init(void)	253	::
244	{	254
		255	static int __init foo_init(void)
		256	{
245	return i2c_add_driver(&foo_driver);	257	return i2c_add_driver(&foo_driver);
246	}	258	}
247	module_init(foo_init);	259	module_init(foo_init);
248		260
249	static void __exit foo_cleanup(void)	261	static void __exit foo_cleanup(void)
250	{	262	{
251	i2c_del_driver(&foo_driver);	263	i2c_del_driver(&foo_driver);
252	}	264	}
253	module_exit(foo_cleanup);	265	module_exit(foo_cleanup);
254		266
255	The module_i2c_driver() macro can be used to reduce above code.	267	The module_i2c_driver() macro can be used to reduce above code.
256		268
257	module_i2c_driver(foo_driver);	269	module_i2c_driver(foo_driver);
258		270
259	Note that some functions are marked by `__init'. These functions can	271	Note that some functions are marked by ``__init``. These functions can
260	be removed after kernel booting (or module loading) is completed.	272	be removed after kernel booting (or module loading) is completed.
261	Likewise, functions marked by `__exit' are dropped by the compiler when	273	Likewise, functions marked by ``__exit`` are dropped by the compiler when
262	the code is built into the kernel, as they would never be called.	274	the code is built into the kernel, as they would never be called.
263		275
264		276
265	Driver Information	277	Driver Information
266	==================	278	==================
267		279
268	/* Substitute your own name and email address */	280	::
269	MODULE_AUTHOR("Frodo Looijaard <frodol@dds.nl>"
270	MODULE_DESCRIPTION("Driver for Barf Inc. Foo I2C devices");
271		281
272	/* a few non-GPL license types are also allowed */	282	/* Substitute your own name and email address */
273	MODULE_LICENSE("GPL");	283	MODULE_AUTHOR("Frodo Looijaard <frodol@dds.nl>"
		284	MODULE_DESCRIPTION("Driver for Barf Inc. Foo I2C devices");
		285
		286	/* a few non-GPL license types are also allowed */
		287	MODULE_LICENSE("GPL");
274		288
275		289
276	Power Management	290	Power Management
@@ -323,6 +337,8 @@ commands, but only some of them understand plain I2C! · 46 unmodified lines
323	Plain I2C communication	337	Plain I2C communication
324	-----------------------	338	-----------------------
325		339
		340	::
		341
326	int i2c_master_send(struct i2c_client client, const char buf,	342	int i2c_master_send(struct i2c_client client, const char buf,
327	int count);	343	int count);
328	int i2c_master_recv(struct i2c_client client, char buf, int count);	344	int i2c_master_recv(struct i2c_client client, char buf, int count);
@@ -334,6 +350,8 @@ to read/write (must be less than the length of the buffer, also should be · 5 unmodified lines
334	less than 64k since msg.len is u16.) Returned is the actual number of bytes	350	less than 64k since msg.len is u16.) Returned is the actual number of bytes
335	read/written.	351	read/written.
336		352
		353	::
		354
337	int i2c_transfer(struct i2c_adapter adap, struct i2c_msg msg,	355	int i2c_transfer(struct i2c_adapter adap, struct i2c_msg msg,
338	int num);	356	int num);
339		357
@@ -343,13 +361,15 @@ stop bit is sent between transaction. The i2c_msg structure contains · 3 unmodified lines
343	for each message the client address, the number of bytes of the message	361	for each message the client address, the number of bytes of the message
344	and the message data itself.	362	and the message data itself.
345		363
346	You can read the file `i2c-protocol' for more information about the	364	You can read the file ``i2c-protocol`` for more information about the
347	actual I2C protocol.	365	actual I2C protocol.
348		366
349		367
350	SMBus communication	368	SMBus communication
351	-------------------	369	-------------------
352		370
		371	::
		372
353	s32 i2c_smbus_xfer(struct i2c_adapter *adapter, u16 addr,	373	s32 i2c_smbus_xfer(struct i2c_adapter *adapter, u16 addr,
354	unsigned short flags, char read_write, u8 command,	374	unsigned short flags, char read_write, u8 command,
355	int size, union i2c_smbus_data *data);	375	int size, union i2c_smbus_data *data);
@@ -357,6 +377,8 @@ SMBus communication · 1 unmodified line
357	This is the generic SMBus function. All functions below are implemented	377	This is the generic SMBus function. All functions below are implemented
358	in terms of it. Never use this function directly!	378	in terms of it. Never use this function directly!
359		379
		380	::
		381
360	s32 i2c_smbus_read_byte(struct i2c_client *client);	382	s32 i2c_smbus_read_byte(struct i2c_client *client);
361	s32 i2c_smbus_write_byte(struct i2c_client *client, u8 value);	383	s32 i2c_smbus_write_byte(struct i2c_client *client, u8 value);
362	s32 i2c_smbus_read_byte_data(struct i2c_client *client, u8 command);	384	s32 i2c_smbus_read_byte_data(struct i2c_client *client, u8 command);
@@ -376,7 +398,7 @@ in terms of it. Never use this function directly! · 13 unmodified lines
376	const u8 *values);	398	const u8 *values);
377		399
378	These ones were removed from i2c-core because they had no users, but could	400	These ones were removed from i2c-core because they had no users, but could
379	be added back later if needed:	401	be added back later if needed::
380		402
381	s32 i2c_smbus_write_quick(struct i2c_client *client, u8 value);	403	s32 i2c_smbus_write_quick(struct i2c_client *client, u8 value);
382	s32 i2c_smbus_process_call(struct i2c_client *client,	404	s32 i2c_smbus_process_call(struct i2c_client *client,
@@ -389,7 +411,7 @@ transactions return 0 on success; the 'read' transactions return the read · 6 unmodified lines
389	value, except for block transactions, which return the number of values	411	value, except for block transactions, which return the number of values
390	read. The block buffers need not be longer than 32 bytes.	412	read. The block buffers need not be longer than 32 bytes.
391		413
392	You can read the file `smbus-protocol' for more information about the	414	You can read the file ``smbus-protocol`` for more information about the
393	actual SMBus protocol.	415	actual SMBus protocol.
394		416
395		417
@@ -397,7 +419,7 @@ General purpose routines · 1 unmodified line
397	========================	419	========================
398		420
399	Below all general purpose routines are listed, that were not mentioned	421	Below all general purpose routines are listed, that were not mentioned
400	before.	422	before::
401		423
402	/* Return the adapter number for a specific adapter */	424	/* Return the adapter number for a specific adapter */
403	int i2c_adapter_id(struct i2c_adapter *adap);	425	int i2c_adapter_id(struct i2c_adapter *adap);

Documentation/index.rst+1−0

@@ -104,6 +104,7 @@ needed). · 103 unmodified lines
104	fb/index	104	fb/index
105	fpga/index	105	fpga/index
106	hid/index	106	hid/index
		107	i2c/index
107	iio/index	108	iio/index
108	infiniband/index	109	infiniband/index
109	leds/index	110	leds/index

Documentation/spi/spi-sc18is602+1−1

@@ -17,7 +17,7 @@ kernel's SPI core subsystem. · 16 unmodified lines
17		17
18	The driver does not probe for supported chips, since the SI18IS602/603 does not	18	The driver does not probe for supported chips, since the SI18IS602/603 does not
19	support Chip ID registers. You will have to instantiate the devices explicitly.	19	support Chip ID registers. You will have to instantiate the devices explicitly.
20	Please see Documentation/i2c/instantiating-devices for details.	20	Please see Documentation/i2c/instantiating-devices.rst for details.
21		21
22		22
23	Usage Notes	23	Usage Notes

MAINTAINERS+24−24

@@ -666,7 +666,7 @@ ALI1563 I2C DRIVER · 665 unmodified lines
666	M: Rudolf Marek <r.marek@assembler.cz>	666	M: Rudolf Marek <r.marek@assembler.cz>
667	L: linux-i2c@vger.kernel.org	667	L: linux-i2c@vger.kernel.org
668	S: Maintained	668	S: Maintained
669	F: Documentation/i2c/busses/i2c-ali1563	669	F: Documentation/i2c/busses/i2c-ali1563.rst
670	F: drivers/i2c/busses/i2c-ali1563.c	670	F: drivers/i2c/busses/i2c-ali1563.c
671		671
672	ALLEGRO DVT VIDEO IP CORE DRIVER	672	ALLEGRO DVT VIDEO IP CORE DRIVER
@@ -6741,7 +6741,7 @@ L: linux-i2c@vger.kernel.org · 6068 unmodified lines
6741	S: Supported	6741	S: Supported
6742	F: drivers/i2c/muxes/i2c-mux-gpio.c	6742	F: drivers/i2c/muxes/i2c-mux-gpio.c
6743	F: include/linux/platform_data/i2c-mux-gpio.h	6743	F: include/linux/platform_data/i2c-mux-gpio.h
6744	F: Documentation/i2c/muxes/i2c-mux-gpio	6744	F: Documentation/i2c/muxes/i2c-mux-gpio.rst
6745		6745
6746	GENERIC HDLC (WAN) DRIVERS	6746	GENERIC HDLC (WAN) DRIVERS
6747	M: Krzysztof Halasa <khc@pm.waw.pl>	6747	M: Krzysztof Halasa <khc@pm.waw.pl>
@@ -7497,14 +7497,14 @@ I2C CONTROLLER DRIVER FOR NVIDIA GPU · 749 unmodified lines
7497	M: Ajay Gupta <ajayg@nvidia.com>	7497	M: Ajay Gupta <ajayg@nvidia.com>
7498	L: linux-i2c@vger.kernel.org	7498	L: linux-i2c@vger.kernel.org
7499	S: Maintained	7499	S: Maintained
7500	F: Documentation/i2c/busses/i2c-nvidia-gpu	7500	F: Documentation/i2c/busses/i2c-nvidia-gpu.rst
7501	F: drivers/i2c/busses/i2c-nvidia-gpu.c	7501	F: drivers/i2c/busses/i2c-nvidia-gpu.c
7502		7502
7503	I2C MUXES	7503	I2C MUXES
7504	M: Peter Rosin <peda@axentia.se>	7504	M: Peter Rosin <peda@axentia.se>
7505	L: linux-i2c@vger.kernel.org	7505	L: linux-i2c@vger.kernel.org
7506	S: Maintained	7506	S: Maintained
7507	F: Documentation/i2c/i2c-topology	7507	F: Documentation/i2c/i2c-topology.rst
7508	F: Documentation/i2c/muxes/	7508	F: Documentation/i2c/muxes/
7509	F: Documentation/devicetree/bindings/i2c/i2c-mux*	7509	F: Documentation/devicetree/bindings/i2c/i2c-mux*
7510	F: Documentation/devicetree/bindings/i2c/i2c-arb*	7510	F: Documentation/devicetree/bindings/i2c/i2c-arb*
@@ -7524,8 +7524,8 @@ I2C OVER PARALLEL PORT · 13 unmodified lines
7524	M: Jean Delvare <jdelvare@suse.com>	7524	M: Jean Delvare <jdelvare@suse.com>
7525	L: linux-i2c@vger.kernel.org	7525	L: linux-i2c@vger.kernel.org
7526	S: Maintained	7526	S: Maintained
7527	F: Documentation/i2c/busses/i2c-parport	7527	F: Documentation/i2c/busses/i2c-parport.rst
7528	F: Documentation/i2c/busses/i2c-parport-light	7528	F: Documentation/i2c/busses/i2c-parport-light.rst
7529	F: drivers/i2c/busses/i2c-parport.c	7529	F: drivers/i2c/busses/i2c-parport.c
7530	F: drivers/i2c/busses/i2c-parport-light.c	7530	F: drivers/i2c/busses/i2c-parport-light.c
7531		7531
@@ -7559,7 +7559,7 @@ I2C-TAOS-EVM DRIVER · 27 unmodified lines
7559	M: Jean Delvare <jdelvare@suse.com>	7559	M: Jean Delvare <jdelvare@suse.com>
7560	L: linux-i2c@vger.kernel.org	7560	L: linux-i2c@vger.kernel.org
7561	S: Maintained	7561	S: Maintained
7562	F: Documentation/i2c/busses/i2c-taos-evm	7562	F: Documentation/i2c/busses/i2c-taos-evm.rst
7563	F: drivers/i2c/busses/i2c-taos-evm.c	7563	F: drivers/i2c/busses/i2c-taos-evm.c
7564		7564
7565	I2C-TINY-USB DRIVER	7565	I2C-TINY-USB DRIVER
@@ -7573,19 +7573,19 @@ I2C/SMBUS CONTROLLER DRIVERS FOR PC · 7 unmodified lines
7573	M: Jean Delvare <jdelvare@suse.com>	7573	M: Jean Delvare <jdelvare@suse.com>
7574	L: linux-i2c@vger.kernel.org	7574	L: linux-i2c@vger.kernel.org
7575	S: Maintained	7575	S: Maintained
7576	F: Documentation/i2c/busses/i2c-ali1535	7576	F: Documentation/i2c/busses/i2c-ali1535.rst
7577	F: Documentation/i2c/busses/i2c-ali1563	7577	F: Documentation/i2c/busses/i2c-ali1563.rst
7578	F: Documentation/i2c/busses/i2c-ali15x3	7578	F: Documentation/i2c/busses/i2c-ali15x3.rst
7579	F: Documentation/i2c/busses/i2c-amd756	7579	F: Documentation/i2c/busses/i2c-amd756.rst
7580	F: Documentation/i2c/busses/i2c-amd8111	7580	F: Documentation/i2c/busses/i2c-amd8111.rst
7581	F: Documentation/i2c/busses/i2c-i801	7581	F: Documentation/i2c/busses/i2c-i801.rst
7582	F: Documentation/i2c/busses/i2c-nforce2	7582	F: Documentation/i2c/busses/i2c-nforce2.rst
7583	F: Documentation/i2c/busses/i2c-piix4	7583	F: Documentation/i2c/busses/i2c-piix4.rst
7584	F: Documentation/i2c/busses/i2c-sis5595	7584	F: Documentation/i2c/busses/i2c-sis5595.rst
7585	F: Documentation/i2c/busses/i2c-sis630	7585	F: Documentation/i2c/busses/i2c-sis630.rst
7586	F: Documentation/i2c/busses/i2c-sis96x	7586	F: Documentation/i2c/busses/i2c-sis96x.rst
7587	F: Documentation/i2c/busses/i2c-via	7587	F: Documentation/i2c/busses/i2c-via.rst
7588	F: Documentation/i2c/busses/i2c-viapro	7588	F: Documentation/i2c/busses/i2c-viapro.rst
7589	F: drivers/i2c/busses/i2c-ali1535.c	7589	F: drivers/i2c/busses/i2c-ali1535.c
7590	F: drivers/i2c/busses/i2c-ali1563.c	7590	F: drivers/i2c/busses/i2c-ali1563.c
7591	F: drivers/i2c/busses/i2c-ali15x3.c	7591	F: drivers/i2c/busses/i2c-ali15x3.c
@@ -7614,7 +7614,7 @@ M: Seth Heasley <seth.heasley@intel.com> · 22 unmodified lines
7614	M: Neil Horman <nhorman@tuxdriver.com>	7614	M: Neil Horman <nhorman@tuxdriver.com>
7615	L: linux-i2c@vger.kernel.org	7615	L: linux-i2c@vger.kernel.org
7616	F: drivers/i2c/busses/i2c-ismt.c	7616	F: drivers/i2c/busses/i2c-ismt.c
7617	F: Documentation/i2c/busses/i2c-ismt	7617	F: Documentation/i2c/busses/i2c-ismt.rst
7618		7618
7619	I2C/SMBUS STUB DRIVER	7619	I2C/SMBUS STUB DRIVER
7620	M: Jean Delvare <jdelvare@suse.com>	7620	M: Jean Delvare <jdelvare@suse.com>
@@ -10355,7 +10355,7 @@ L: linux-i2c@vger.kernel.org · 2734 unmodified lines
10355	S: Supported	10355	S: Supported
10356	F: drivers/i2c/busses/i2c-mlxcpld.c	10356	F: drivers/i2c/busses/i2c-mlxcpld.c
10357	F: drivers/i2c/muxes/i2c-mux-mlxcpld.c	10357	F: drivers/i2c/muxes/i2c-mux-mlxcpld.c
10358	F: Documentation/i2c/busses/i2c-mlxcpld	10358	F: Documentation/i2c/busses/i2c-mlxcpld.rst
10359		10359
10360	MELLANOX MLXCPLD LED DRIVER	10360	MELLANOX MLXCPLD LED DRIVER
10361	M: Vadim Pasternak <vadimp@mellanox.com>	10361	M: Vadim Pasternak <vadimp@mellanox.com>
@@ -11976,7 +11976,7 @@ M: Andrew Lunn <andrew@lunn.ch> · 1614 unmodified lines
11976	L: linux-i2c@vger.kernel.org	11976	L: linux-i2c@vger.kernel.org
11977	S: Maintained	11977	S: Maintained
11978	F: Documentation/devicetree/bindings/i2c/i2c-ocores.txt	11978	F: Documentation/devicetree/bindings/i2c/i2c-ocores.txt
11979	F: Documentation/i2c/busses/i2c-ocores	11979	F: Documentation/i2c/busses/i2c-ocores.rst
11980	F: drivers/i2c/busses/i2c-ocores.c	11980	F: drivers/i2c/busses/i2c-ocores.c
11981	F: include/linux/platform_data/i2c-ocores.h	11981	F: include/linux/platform_data/i2c-ocores.h
11982		11982
@@ -14280,7 +14280,7 @@ F: net/sctp/ · 2297 unmodified lines
14280	SCx200 CPU SUPPORT	14280	SCx200 CPU SUPPORT
14281	M: Jim Cromie <jim.cromie@gmail.com>	14281	M: Jim Cromie <jim.cromie@gmail.com>
14282	S: Odd Fixes	14282	S: Odd Fixes
14283	F: Documentation/i2c/busses/scx200_acb	14283	F: Documentation/i2c/busses/scx200_acb.rst
14284	F: arch/x86/platform/scx200/	14284	F: arch/x86/platform/scx200/
14285	F: drivers/watchdog/scx200_wdt.c	14285	F: drivers/watchdog/scx200_wdt.c
14286	F: drivers/i2c/busses/scx200*	14286	F: drivers/i2c/busses/scx200*

drivers/hwmon/atxp1.c+1−1

@@ -5,7 +5,7 @@ · 4 unmodified lines
5	*	5	*
6	* The ATXP1 can reside on I2C addresses 0x37 or 0x4e. The chip is	6	* The ATXP1 can reside on I2C addresses 0x37 or 0x4e. The chip is
7	* not auto-detected by the driver and must be instantiated explicitly.	7	* not auto-detected by the driver and must be instantiated explicitly.
8	* See Documentation/i2c/instantiating-devices for more information.	8	* See Documentation/i2c/instantiating-devices.rst for more information.
9	*/	9	*/
10		10
11	#include <linux/kernel.h>	11	#include <linux/kernel.h>

drivers/hwmon/smm665.c+1−1

@@ -197,7 +197,7 @@ static int smm665_read_adc(struct smm665_data *data, int adc) · 196 unmodified lines
197	if (rv != -ENXIO) {	197	if (rv != -ENXIO) {
198	/*	198	/*
199	* We expect ENXIO to reflect NACK	199	* We expect ENXIO to reflect NACK
200	* (per Documentation/i2c/fault-codes).	200	* (per Documentation/i2c/fault-codes.rst).
201	* Everything else is an error.	201	* Everything else is an error.
202	*/	202	*/
203	dev_dbg(&client->dev,	203	dev_dbg(&client->dev,

drivers/i2c/Kconfig+2−2

@@ -54,7 +54,7 @@ config I2C_CHARDEV · 53 unmodified lines
54	Say Y here to use i2c-* device files, usually found in the /dev	54	Say Y here to use i2c-* device files, usually found in the /dev
55	directory on your system. They make it possible to have user-space	55	directory on your system. They make it possible to have user-space
56	programs use the I2C bus. Information on how to do this is	56	programs use the I2C bus. Information on how to do this is
57	contained in the file <file:Documentation/i2c/dev-interface>.	57	contained in the file <file:Documentation/i2c/dev-interface.rst>.
58		58
59	This support is also available as a module. If so, the module	59	This support is also available as a module. If so, the module
60	will be called i2c-dev.	60	will be called i2c-dev.
@@ -107,7 +107,7 @@ config I2C_STUB · 46 unmodified lines
107	especially for certain kinds of sensor chips.	107	especially for certain kinds of sensor chips.
108		108
109	If you do build this module, be sure to read the notes and warnings	109	If you do build this module, be sure to read the notes and warnings
110	in <file:Documentation/i2c/i2c-stub>.	110	in <file:Documentation/i2c/i2c-stub.rst>.
111		111
112	If you don't know what to do here, definitely say N.	112	If you don't know what to do here, definitely say N.
113		113

drivers/i2c/busses/Kconfig+1−1

@@ -1206,7 +1206,7 @@ config I2C_PARPORT · 1205 unmodified lines
1206	and makes it easier to add support for new devices.	1206	and makes it easier to add support for new devices.
1207		1207
1208	An adapter type parameter is now mandatory. Please read the file	1208	An adapter type parameter is now mandatory. Please read the file
1209	Documentation/i2c/busses/i2c-parport for details.	1209	Documentation/i2c/busses/i2c-parport.rst for details.
1210		1210
1211	Another driver exists, named i2c-parport-light, which doesn't depend	1211	Another driver exists, named i2c-parport-light, which doesn't depend
1212	on the parport driver. This is meant for embedded systems. Don't say	1212	on the parport driver. This is meant for embedded systems. Don't say

drivers/i2c/busses/i2c-i801.c+1−1

@@ -77,7 +77,7 @@ · 76 unmodified lines
77	* SMBus Host Notify yes	77	* SMBus Host Notify yes
78	* Interrupt processing yes	78	* Interrupt processing yes
79	*	79	*
80	* See the file Documentation/i2c/busses/i2c-i801 for details.	80	* See the file Documentation/i2c/busses/i2c-i801.rst for details.
81	*/	81	*/
82		82
83	#include <linux/interrupt.h>	83	#include <linux/interrupt.h>

drivers/i2c/busses/i2c-taos-evm.c+1−1

@@ -125,7 +125,7 @@ static int taos_smbus_xfer(struct i2c_adapter *adapter, u16 addr, · 124 unmodified lines
125	/*	125	/*
126	* Voluntarily dropping error code of kstrtou8 since all	126	* Voluntarily dropping error code of kstrtou8 since all
127	* error code that it could return are invalid according	127	* error code that it could return are invalid according
128	* to Documentation/i2c/fault-codes.	128	* to Documentation/i2c/fault-codes.rst.
129	*/	129	*/
130	if (kstrtou8(p + 1, 16, &data->byte))	130	if (kstrtou8(p + 1, 16, &data->byte))
131	return -EPROTO;	131	return -EPROTO;

drivers/i2c/i2c-core-base.c+2−2

@@ -2206,7 +2206,7 @@ static int i2c_detect_address(struct i2c_client *temp_client, · 2205 unmodified lines
2206	dev_warn(&adapter->dev,	2206	dev_warn(&adapter->dev,
2207	"This adapter will soon drop class based instantiation of devices. "	2207	"This adapter will soon drop class based instantiation of devices. "
2208	"Please make sure client 0x%02x gets instantiated by other means. "	2208	"Please make sure client 0x%02x gets instantiated by other means. "
2209	"Check 'Documentation/i2c/instantiating-devices' for details.\n",	2209	"Check 'Documentation/i2c/instantiating-devices.rst' for details.\n",
2210	info.addr);	2210	info.addr);
2211		2211
2212	dev_dbg(&adapter->dev, "Creating %s at 0x%02x\n",	2212	dev_dbg(&adapter->dev, "Creating %s at 0x%02x\n",
@@ -2236,7 +2236,7 @@ static int i2c_detect(struct i2c_adapter adapter, struct i2c_driver driver) · 23 unmodified lines
2236	if (adapter->class == I2C_CLASS_DEPRECATED) {	2236	if (adapter->class == I2C_CLASS_DEPRECATED) {
2237	dev_dbg(&adapter->dev,	2237	dev_dbg(&adapter->dev,
2238	"This adapter dropped support for I2C classes and won't auto-detect %s devices anymore. "	2238	"This adapter dropped support for I2C classes and won't auto-detect %s devices anymore. "
2239	"If you need it, check 'Documentation/i2c/instantiating-devices' for alternatives.\n",	2239	"If you need it, check 'Documentation/i2c/instantiating-devices.rst' for alternatives.\n",
2240	driver->driver.name);	2240	driver->driver.name);
2241	return 0;	2241	return 0;
2242	}	2242	}

drivers/iio/dummy/iio_simple_dummy.c+1−1

@@ -693,7 +693,7 @@ static int iio_dummy_remove(struct iio_sw_device *swd) · 692 unmodified lines
693	* Varies depending on bus type of the device. As there is no device	693	* Varies depending on bus type of the device. As there is no device
694	* here, call probe directly. For information on device registration	694	* here, call probe directly. For information on device registration
695	* i2c:	695	* i2c:
696	* Documentation/i2c/writing-clients	696	* Documentation/i2c/writing-clients.rst
697	* spi:	697	* spi:
698	* Documentation/spi/spi-summary	698	* Documentation/spi/spi-summary
699	*/	699	*/

drivers/rtc/rtc-ds1374.c+1−1

@@ -14,7 +14,7 @@ · 13 unmodified lines
14	*/	14	*/
15	/*	15	/*
16	* It would be more efficient to use i2c msgs/i2c_transfer directly but, as	16	* It would be more efficient to use i2c msgs/i2c_transfer directly but, as
17	* recommened in .../Documentation/i2c/writing-clients section	17	* recommended in .../Documentation/i2c/writing-clients.rst section
18	* "Sending and receiving", using SMBus level communication is preferred.	18	* "Sending and receiving", using SMBus level communication is preferred.
19	*/	19	*/
20		20

include/linux/i2c.h+1−1

@@ -521,7 +521,7 @@ i2c_register_board_info(int busnum, struct i2c_board_info const *info, · 520 unmodified lines
521	*	521	*
522	* The return codes from the @master_xfer{_atomic} fields should indicate the	522	* The return codes from the @master_xfer{_atomic} fields should indicate the
523	* type of error code that occurred during the transfer, as documented in the	523	* type of error code that occurred during the transfer, as documented in the
524	* Kernel Documentation file Documentation/i2c/fault-codes.	524	* Kernel Documentation file Documentation/i2c/fault-codes.rst.
525	*/	525	*/
526	struct i2c_algorithm {	526	struct i2c_algorithm {
527	/*	527	/*

docs: i2c: convert to ReST and add to driver-api bookset

Keyboard shortcuts

General

Issues and pull requests

Issues, pull requests and Inbox

Repository code

@@ -1,3 +1,7 @@
		1	====================
		2	I2C Device Interface
		3	====================
		4
1	Usually, i2c devices are controlled by a kernel driver. But it is also	5	Usually, i2c devices are controlled by a kernel driver. But it is also
2	possible to access all devices on an adapter from userspace, through	6	possible to access all devices on an adapter from userspace, through
3	the /dev interface. You need to load module i2c-dev for this.	7	the /dev interface. You need to load module i2c-dev for this.
@@ -18,7 +22,7 @@ C example · 14 unmodified lines
18	=========	22	=========
19		23
20	So let's say you want to access an i2c adapter from a C program.	24	So let's say you want to access an i2c adapter from a C program.
21	First, you need to include these two headers:	25	First, you need to include these two headers::
22		26
23	#include <linux/i2c-dev.h>	27	#include <linux/i2c-dev.h>
24	#include <i2c/smbus.h>	28	#include <i2c/smbus.h>
@@ -28,7 +32,7 @@ inspect /sys/class/i2c-dev/ or run "i2cdetect -l" to decide this. · 3 unmodified lines
28	Adapter numbers are assigned somewhat dynamically, so you can not	32	Adapter numbers are assigned somewhat dynamically, so you can not
29	assume much about them. They can even change from one boot to the next.	33	assume much about them. They can even change from one boot to the next.
30		34
31	Next thing, open the device file, as follows:	35	Next thing, open the device file, as follows::
32		36
33	int file;	37	int file;
34	int adapter_nr = 2; /* probably dynamically determined */	38	int adapter_nr = 2; /* probably dynamically determined */
@@ -42,7 +46,7 @@ Next thing, open the device file, as follows: · 7 unmodified lines
42	}	46	}
43		47
44	When you have opened the device, you must specify with what device	48	When you have opened the device, you must specify with what device
45	address you want to communicate:	49	address you want to communicate::
46		50
47	int addr = 0x40; /* The I2C address */	51	int addr = 0x40; /* The I2C address */
48		52
@@ -53,7 +57,7 @@ address you want to communicate: · 4 unmodified lines
53		57
54	Well, you are all set up now. You can now use SMBus commands or plain	58	Well, you are all set up now. You can now use SMBus commands or plain
55	I2C to communicate with your device. SMBus commands are preferred if	59	I2C to communicate with your device. SMBus commands are preferred if
56	the device supports them. Both are illustrated below.	60	the device supports them. Both are illustrated below::
57		61
58	__u8 reg = 0x10; /* Device register to access */	62	__u8 reg = 0x10; /* Device register to access */
59	__s32 res;	63	__s32 res;
@@ -100,35 +104,35 @@ Full interface description · 40 unmodified lines
100		104
101	The following IOCTLs are defined:	105	The following IOCTLs are defined:
102		106
103	ioctl(file, I2C_SLAVE, long addr)	107	``ioctl(file, I2C_SLAVE, long addr)``
104	Change slave address. The address is passed in the 7 lower bits of the	108	Change slave address. The address is passed in the 7 lower bits of the
105	argument (except for 10 bit addresses, passed in the 10 lower bits in this	109	argument (except for 10 bit addresses, passed in the 10 lower bits in this
106	case).	110	case).
107		111
108	ioctl(file, I2C_TENBIT, long select)	112	``ioctl(file, I2C_TENBIT, long select)``
109	Selects ten bit addresses if select not equals 0, selects normal 7 bit	113	Selects ten bit addresses if select not equals 0, selects normal 7 bit
110	addresses if select equals 0. Default 0. This request is only valid	114	addresses if select equals 0. Default 0. This request is only valid
111	if the adapter has I2C_FUNC_10BIT_ADDR.	115	if the adapter has I2C_FUNC_10BIT_ADDR.
112		116
113	ioctl(file, I2C_PEC, long select)	117	``ioctl(file, I2C_PEC, long select)``
114	Selects SMBus PEC (packet error checking) generation and verification	118	Selects SMBus PEC (packet error checking) generation and verification
115	if select not equals 0, disables if select equals 0. Default 0.	119	if select not equals 0, disables if select equals 0. Default 0.
116	Used only for SMBus transactions. This request only has an effect if the	120	Used only for SMBus transactions. This request only has an effect if the
117	the adapter has I2C_FUNC_SMBUS_PEC; it is still safe if not, it just	121	the adapter has I2C_FUNC_SMBUS_PEC; it is still safe if not, it just
118	doesn't have any effect.	122	doesn't have any effect.
119		123
120	ioctl(file, I2C_FUNCS, unsigned long *funcs)	124	``ioctl(file, I2C_FUNCS, unsigned long *funcs)``
121	Gets the adapter functionality and puts it in *funcs.	125	Gets the adapter functionality and puts it in ``*funcs``.
122		126
123	ioctl(file, I2C_RDWR, struct i2c_rdwr_ioctl_data *msgset)	127	``ioctl(file, I2C_RDWR, struct i2c_rdwr_ioctl_data *msgset)``
124	Do combined read/write transaction without stop in between.	128	Do combined read/write transaction without stop in between.
125	Only valid if the adapter has I2C_FUNC_I2C. The argument is	129	Only valid if the adapter has I2C_FUNC_I2C. The argument is
126	a pointer to a	130	a pointer to a::
127		131
128	struct i2c_rdwr_ioctl_data {	132	struct i2c_rdwr_ioctl_data {
129	struct i2c_msg msgs; / ptr to array of simple messages */	133	struct i2c_msg msgs; / ptr to array of simple messages */
130	int nmsgs; /* number of messages to exchange */	134	int nmsgs; /* number of messages to exchange */
131	}	135	}
132		136
133	The msgs[] themselves contain further pointers into data buffers.	137	The msgs[] themselves contain further pointers into data buffers.
134	The function will write or read data to or from that buffers depending	138	The function will write or read data to or from that buffers depending
@@ -136,8 +140,8 @@ ioctl(file, I2C_RDWR, struct i2c_rdwr_ioctl_data *msgset) · 1 unmodified line
136	The slave address and whether to use ten bit address mode has to be	140	The slave address and whether to use ten bit address mode has to be
137	set in each message, overriding the values set with the above ioctl's.	141	set in each message, overriding the values set with the above ioctl's.
138		142
139	ioctl(file, I2C_SMBUS, struct i2c_smbus_ioctl_data *args)	143	``ioctl(file, I2C_SMBUS, struct i2c_smbus_ioctl_data *args)``
140	If possible, use the provided i2c_smbus_* methods described below instead	144	If possible, use the provided ``i2c_smbus_*`` methods described below instead
141	of issuing direct ioctls.	145	of issuing direct ioctls.
142		146
143	You can do plain i2c transactions by using read(2) and write(2) calls.	147	You can do plain i2c transactions by using read(2) and write(2) calls.
@@ -145,7 +149,8 @@ You do not need to pass the address byte; instead, set it through · 1 unmodified line
145	ioctl I2C_SLAVE before you try to access the device.	149	ioctl I2C_SLAVE before you try to access the device.
146		150
147	You can do SMBus level transactions (see documentation file smbus-protocol	151	You can do SMBus level transactions (see documentation file smbus-protocol
148	for details) through the following functions:	152	for details) through the following functions::
		153
149	__s32 i2c_smbus_write_quick(int file, __u8 value);	154	__s32 i2c_smbus_write_quick(int file, __u8 value);
150	__s32 i2c_smbus_read_byte(int file);	155	__s32 i2c_smbus_read_byte(int file);
151	__s32 i2c_smbus_write_byte(int file, __u8 value);	156	__s32 i2c_smbus_write_byte(int file, __u8 value);
@@ -157,6 +162,7 @@ for details) through the following functions: · 5 unmodified lines
157	__s32 i2c_smbus_read_block_data(int file, __u8 command, __u8 *values);	162	__s32 i2c_smbus_read_block_data(int file, __u8 command, __u8 *values);
158	__s32 i2c_smbus_write_block_data(int file, __u8 command, __u8 length,	163	__s32 i2c_smbus_write_block_data(int file, __u8 command, __u8 length,
159	__u8 *values);	164	__u8 *values);
		165
160	All these transactions return -1 on failure; you can read errno to see	166	All these transactions return -1 on failure; you can read errno to see
161	what happened. The 'write' transactions return 0 on success; the	167	what happened. The 'write' transactions return 0 on success; the
162	'read' transactions return the read value, except for read_block, which	168	'read' transactions return the read value, except for read_block, which
@@ -174,39 +180,39 @@ Implementation details · 11 unmodified lines
174	For the interested, here's the code flow which happens inside the kernel	180	For the interested, here's the code flow which happens inside the kernel
175	when you use the /dev interface to I2C:	181	when you use the /dev interface to I2C:
176		182
177	1* Your program opens /dev/i2c-N and calls ioctl() on it, as described in	183	1) Your program opens /dev/i2c-N and calls ioctl() on it, as described in
178	section "C example" above.	184	section "C example" above.
179		185
180	2* These open() and ioctl() calls are handled by the i2c-dev kernel	186	2) These open() and ioctl() calls are handled by the i2c-dev kernel
181	driver: see i2c-dev.c:i2cdev_open() and i2c-dev.c:i2cdev_ioctl(),	187	driver: see i2c-dev.c:i2cdev_open() and i2c-dev.c:i2cdev_ioctl(),
182	respectively. You can think of i2c-dev as a generic I2C chip driver	188	respectively. You can think of i2c-dev as a generic I2C chip driver
183	that can be programmed from user-space.	189	that can be programmed from user-space.
184		190
185	3* Some ioctl() calls are for administrative tasks and are handled by	191	3) Some ioctl() calls are for administrative tasks and are handled by
186	i2c-dev directly. Examples include I2C_SLAVE (set the address of the	192	i2c-dev directly. Examples include I2C_SLAVE (set the address of the
187	device you want to access) and I2C_PEC (enable or disable SMBus error	193	device you want to access) and I2C_PEC (enable or disable SMBus error
188	checking on future transactions.)	194	checking on future transactions.)
189		195
190	4* Other ioctl() calls are converted to in-kernel function calls by	196	4) Other ioctl() calls are converted to in-kernel function calls by
191	i2c-dev. Examples include I2C_FUNCS, which queries the I2C adapter	197	i2c-dev. Examples include I2C_FUNCS, which queries the I2C adapter
192	functionality using i2c.h:i2c_get_functionality(), and I2C_SMBUS, which	198	functionality using i2c.h:i2c_get_functionality(), and I2C_SMBUS, which
193	performs an SMBus transaction using i2c-core-smbus.c:i2c_smbus_xfer().	199	performs an SMBus transaction using i2c-core-smbus.c:i2c_smbus_xfer().
194		200
195	The i2c-dev driver is responsible for checking all the parameters that	201	The i2c-dev driver is responsible for checking all the parameters that
196	come from user-space for validity. After this point, there is no	202	come from user-space for validity. After this point, there is no
197	difference between these calls that came from user-space through i2c-dev	203	difference between these calls that came from user-space through i2c-dev
198	and calls that would have been performed by kernel I2C chip drivers	204	and calls that would have been performed by kernel I2C chip drivers
199	directly. This means that I2C bus drivers don't need to implement	205	directly. This means that I2C bus drivers don't need to implement
200	anything special to support access from user-space.	206	anything special to support access from user-space.
201		207
202	5* These i2c.h functions are wrappers to the actual implementation of	208	5) These i2c.h functions are wrappers to the actual implementation of
203	your I2C bus driver. Each adapter must declare callback functions	209	your I2C bus driver. Each adapter must declare callback functions
204	implementing these standard calls. i2c.h:i2c_get_functionality() calls	210	implementing these standard calls. i2c.h:i2c_get_functionality() calls
205	i2c_adapter.algo->functionality(), while	211	i2c_adapter.algo->functionality(), while
206	i2c-core-smbus.c:i2c_smbus_xfer() calls either	212	i2c-core-smbus.c:i2c_smbus_xfer() calls either
207	adapter.algo->smbus_xfer() if it is implemented, or if not,	213	adapter.algo->smbus_xfer() if it is implemented, or if not,
208	i2c-core-smbus.c:i2c_smbus_xfer_emulated() which in turn calls	214	i2c-core-smbus.c:i2c_smbus_xfer_emulated() which in turn calls
209	i2c_adapter.algo->master_xfer().	215	i2c_adapter.algo->master_xfer().
210		216
211	After your I2C bus driver has processed these requests, execution runs	217	After your I2C bus driver has processed these requests, execution runs
212	up the call chain, with almost no processing done, except by i2c-dev to	218	up the call chain, with almost no processing done, except by i2c-dev to

@@ -104,10 +104,10 @@ There doesn't need to be a device at this address because arbitration lost · 103 unmodified lines
104	should be detected beforehand. Also note, that SCL going down is monitored	104	should be detected beforehand. Also note, that SCL going down is monitored
105	using interrupts, so the interrupt latency might cause the first bits to be not	105	using interrupts, so the interrupt latency might cause the first bits to be not
106	corrupted. A good starting point for using this fault injector on an otherwise	106	corrupted. A good starting point for using this fault injector on an otherwise
107	idle bus is:	107	idle bus is::
108		108
109	# echo 200 > lose_arbitration &	109	# echo 200 > lose_arbitration &
110	# i2cget -y <bus_to_test> 0x3f	110	# i2cget -y <bus_to_test> 0x3f
111		111
112	Panic during transfer	112	Panic during transfer
113	=====================	113	=====================
@@ -127,10 +127,10 @@ The calling process will then sleep and wait for the next bus clock. The · 13 unmodified lines
127	process is interruptible, though.	127	process is interruptible, though.
128		128
129	Start of a transfer is detected by waiting for SCL going down by the master	129	Start of a transfer is detected by waiting for SCL going down by the master
130	under test. A good starting point for using this fault injector is:	130	under test. A good starting point for using this fault injector is::
131		131
132	# echo 0 > inject_panic &	132	# echo 0 > inject_panic &
133	# i2cget -y <bus_to_test> <some_address>	133	# i2cget -y <bus_to_test> <some_address>
134		134
135	Note that there doesn't need to be a device listening to the address you are	135	Note that there doesn't need to be a device listening to the address you are
136	using. Results may vary depending on that, though.	136	using. Results may vary depending on that, though.

@@ -1,3 +1,4 @@
		1	==============================
1	How to instantiate I2C devices	2	How to instantiate I2C devices
2	==============================	3	==============================
3		4
@@ -17,9 +18,9 @@ which is known in advance. It is thus possible to pre-declare the I2C · 13 unmodified lines
17	devices which live on this bus. This is done with an array of struct	18	devices which live on this bus. This is done with an array of struct
18	i2c_board_info which is registered by calling i2c_register_board_info().	19	i2c_board_info which is registered by calling i2c_register_board_info().
19		20
20	Example (from omap2 h4):	21	Example (from omap2 h4)::
21		22
22	static struct i2c_board_info h4_i2c_board_info[] __initdata = {	23	static struct i2c_board_info h4_i2c_board_info[] __initdata = {
23	{	24	{
24	I2C_BOARD_INFO("isp1301_omap", 0x2d),	25	I2C_BOARD_INFO("isp1301_omap", 0x2d),
25	.irq = OMAP_GPIO_IRQ(125),	26	.irq = OMAP_GPIO_IRQ(125),
@@ -32,15 +33,15 @@ static struct i2c_board_info h4_i2c_board_info[] __initdata = { · 6 unmodified lines
32	I2C_BOARD_INFO("24c01", 0x57),	33	I2C_BOARD_INFO("24c01", 0x57),
33	.platform_data = &m24c01,	34	.platform_data = &m24c01,
34	},	35	},
35	};	36	};
36		37
37	static void __init omap_h4_init(void)	38	static void __init omap_h4_init(void)
38	{	39	{
39	(...)	40	(...)
40	i2c_register_board_info(1, h4_i2c_board_info,	41	i2c_register_board_info(1, h4_i2c_board_info,
41	ARRAY_SIZE(h4_i2c_board_info));	42	ARRAY_SIZE(h4_i2c_board_info));
42	(...)	43	(...)
43	}	44	}
44		45
45	The above code declares 3 devices on I2C bus 1, including their respective	46	The above code declares 3 devices on I2C bus 1, including their respective
46	addresses and custom data needed by their drivers. When the I2C bus in	47	addresses and custom data needed by their drivers. When the I2C bus in
@@ -57,7 +58,7 @@ Method 1b: Declare the I2C devices via devicetree · 10 unmodified lines
57	This method has the same implications as method 1a. The declaration of I2C	58	This method has the same implications as method 1a. The declaration of I2C
58	devices is here done via devicetree as subnodes of the master controller.	59	devices is here done via devicetree as subnodes of the master controller.
59		60
60	Example:	61	Example::
61		62
62	i2c1: i2c@400a0000 {	63	i2c1: i2c@400a0000 {
63	/* ... master properties skipped ... */	64	/* ... master properties skipped ... */
@@ -99,20 +100,20 @@ bus in advance, so the method 1 described above can't be used. Instead, · 35 unmodified lines
99	you can instantiate your I2C devices explicitly. This is done by filling	100	you can instantiate your I2C devices explicitly. This is done by filling
100	a struct i2c_board_info and calling i2c_new_device().	101	a struct i2c_board_info and calling i2c_new_device().
101		102
102	Example (from the sfe4001 network driver):	103	Example (from the sfe4001 network driver)::
103		104
104	static struct i2c_board_info sfe4001_hwmon_info = {	105	static struct i2c_board_info sfe4001_hwmon_info = {
105	I2C_BOARD_INFO("max6647", 0x4e),	106	I2C_BOARD_INFO("max6647", 0x4e),
106	};	107	};
107		108
108	int sfe4001_init(struct efx_nic *efx)	109	int sfe4001_init(struct efx_nic *efx)
109	{	110	{
110	(...)	111	(...)
111	efx->board_info.hwmon_client =	112	efx->board_info.hwmon_client =
112	i2c_new_device(&efx->i2c_adap, &sfe4001_hwmon_info);	113	i2c_new_device(&efx->i2c_adap, &sfe4001_hwmon_info);
113		114
114	(...)	115	(...)
115	}	116	}
116		117
117	The above code instantiates 1 I2C device on the I2C bus which is on the	118	The above code instantiates 1 I2C device on the I2C bus which is on the
118	network adapter in question.	119	network adapter in question.
@@ -124,12 +125,12 @@ it may have different addresses from one board to the next (manufacturer · 5 unmodified lines
124	changing its design without notice). In this case, you can call	125	changing its design without notice). In this case, you can call
125	i2c_new_probed_device() instead of i2c_new_device().	126	i2c_new_probed_device() instead of i2c_new_device().
126		127
127	Example (from the nxp OHCI driver):	128	Example (from the nxp OHCI driver)::
128		129
129	static const unsigned short normal_i2c[] = { 0x2c, 0x2d, I2C_CLIENT_END };	130	static const unsigned short normal_i2c[] = { 0x2c, 0x2d, I2C_CLIENT_END };
130		131
131	static int usb_hcd_nxp_probe(struct platform_device *pdev)	132	static int usb_hcd_nxp_probe(struct platform_device *pdev)
132	{	133	{
133	(...)	134	(...)
134	struct i2c_adapter *i2c_adap;	135	struct i2c_adapter *i2c_adap;
135	struct i2c_board_info i2c_info;	136	struct i2c_board_info i2c_info;
@@ -142,7 +143,7 @@ static int usb_hcd_nxp_probe(struct platform_device *pdev) · 6 unmodified lines
142	normal_i2c, NULL);	143	normal_i2c, NULL);
143	i2c_put_adapter(i2c_adap);	144	i2c_put_adapter(i2c_adap);
144	(...)	145	(...)
145	}	146	}
146		147
147	The above code instantiates up to 1 I2C device on the I2C bus which is on	148	The above code instantiates up to 1 I2C device on the I2C bus which is on
148	the OHCI adapter in question. It first tries at address 0x2c, if nothing	149	the OHCI adapter in question. It first tries at address 0x2c, if nothing
@@ -172,6 +173,7 @@ explicitly. Instead, i2c-core will probe for such devices as soon as their · 23 unmodified lines
172	drivers are loaded, and if any is found, an I2C device will be	173	drivers are loaded, and if any is found, an I2C device will be
173	instantiated automatically. In order to prevent any misbehavior of this	174	instantiated automatically. In order to prevent any misbehavior of this
174	mechanism, the following restrictions apply:	175	mechanism, the following restrictions apply:
		176
175	* The I2C device driver must implement the detect() method, which	177	* The I2C device driver must implement the detect() method, which
176	identifies a supported device by reading from arbitrary registers.	178	identifies a supported device by reading from arbitrary registers.
177	* Only buses which are likely to have a supported device and agree to be	179	* Only buses which are likely to have a supported device and agree to be
@@ -189,6 +191,7 @@ first. · 11 unmodified lines
189	Those of you familiar with the i2c subsystem of 2.4 kernels and early 2.6	191	Those of you familiar with the i2c subsystem of 2.4 kernels and early 2.6
190	kernels will find out that this method 3 is essentially similar to what	192	kernels will find out that this method 3 is essentially similar to what
191	was done there. Two significant differences are:	193	was done there. Two significant differences are:
		194
192	* Probing is only one way to instantiate I2C devices now, while it was the	195	* Probing is only one way to instantiate I2C devices now, while it was the
193	only way back then. Where possible, methods 1 and 2 should be preferred.	196	only way back then. Where possible, methods 1 and 2 should be preferred.
194	Method 3 should only be used when there is no other way, as it can have	197	Method 3 should only be used when there is no other way, as it can have
@@ -224,11 +227,13 @@ device. As no two devices can live at the same address on a given I2C · 29 unmodified lines
224	segment, the address is sufficient to uniquely identify the device to be	227	segment, the address is sufficient to uniquely identify the device to be
225	deleted.	228	deleted.
226		229
227	Example:	230	Example::
228	# echo eeprom 0x50 > /sys/bus/i2c/devices/i2c-3/new_device	231
		232	# echo eeprom 0x50 > /sys/bus/i2c/devices/i2c-3/new_device
229		233
230	While this interface should only be used when in-kernel device declaration	234	While this interface should only be used when in-kernel device declaration
231	can't be done, there is a variety of cases where it can be helpful:	235	can't be done, there is a variety of cases where it can be helpful:
		236
232	* The I2C driver usually detects devices (method 3 above) but the bus	237	* The I2C driver usually detects devices (method 3 above) but the bus
233	segment your device lives on doesn't have the proper class bit set and	238	segment your device lives on doesn't have the proper class bit set and
234	thus detection doesn't trigger.	239	thus detection doesn't trigger.