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

Convert each file at I2C subsystem, renaming them to .rst and adding to the driver-api book.

Mauro Carvalho Chehab committed 7 years ago

Commit ccf988b1 parent 09f4c7583 files · +1095 −789Browse files

Unified · Split

83 files

Documentation/devicetree/bindings/i2c/i2c-mux-gpmux.txt +1 −1
Documentation/driver-api/ipmb.rst +1 −1
Documentation/hwmon/adm1021.rst +1 −1
Documentation/hwmon/adm1275.rst +1 −1
Documentation/hwmon/hih6130.rst +1 −1
Documentation/hwmon/ibm-cffps.rst +1 −1
Documentation/hwmon/lm25066.rst +1 −1
Documentation/hwmon/max16064.rst +1 −1
Documentation/hwmon/max16065.rst +1 −1
Documentation/hwmon/max20751.rst +1 −1
Documentation/hwmon/max34440.rst +1 −1
Documentation/hwmon/max6650.rst +1 −1
Documentation/hwmon/max8688.rst +1 −1
Documentation/hwmon/menf21bmc.rst +1 −1
Documentation/hwmon/pcf8591.rst +1 −1
Documentation/hwmon/sht3x.rst +1 −1
Documentation/hwmon/shtc1.rst +1 −1
Documentation/hwmon/tmp103.rst +1 −1
Documentation/hwmon/tps40422.rst +1 −1
Documentation/hwmon/ucd9000.rst +1 −1
Documentation/hwmon/ucd9200.rst +1 −1
Documentation/hwmon/via686a.rst +1 −1
Documentation/hwmon/zl6100.rst +1 −1
Documentation/i2c/busses/i2c-ali1535.rst +8 −5
Documentation/i2c/busses/i2c-ali1563.rst +3 −0
Documentation/i2c/busses/i2c-ali15x3.rst +37 −27
Documentation/i2c/busses/i2c-amd-mp2 +0 −23
Documentation/i2c/busses/i2c-amd-mp2.rst +25 −0
Documentation/i2c/busses/i2c-amd756.rst +6 −2
Documentation/i2c/busses/i2c-amd8111.rst +8 −6
Documentation/i2c/busses/i2c-diolan-u2c.rst +3 −0
Documentation/i2c/busses/i2c-i801.rst +21 −12
Documentation/i2c/busses/i2c-ismt.rst +14 −6
Documentation/i2c/busses/i2c-mlxcpld.rst +6 −0
Documentation/i2c/busses/i2c-nforce2.rst +18 −15
Documentation/i2c/busses/i2c-nvidia-gpu.rst +4 −2
Documentation/i2c/busses/i2c-ocores.rst +12 −10
Documentation/i2c/busses/i2c-parport +0 −178
Documentation/i2c/busses/i2c-parport-light.rst +5 −3
Documentation/i2c/busses/i2c-parport.rst +190 −0
Documentation/i2c/busses/i2c-pca-isa.rst +6 −3
Documentation/i2c/busses/i2c-piix4.rst +10 −8
Documentation/i2c/busses/i2c-sis5595.rst +14 −5
Documentation/i2c/busses/i2c-sis630 +0 −58
Documentation/i2c/busses/i2c-sis630.rst +63 −0
Documentation/i2c/busses/i2c-sis96x.rst +20 −11
Documentation/i2c/busses/i2c-taos-evm.rst +5 −3
Documentation/i2c/busses/i2c-via.rst +17 −11
Documentation/i2c/busses/i2c-viapro.rst +8 −4
Documentation/i2c/busses/index.rst +33 −0
Documentation/i2c/busses/scx200_acb.rst +7 −2
Documentation/i2c/dev-interface.rst +55 −49
Documentation/i2c/dma-considerations.rst +0 −0
Documentation/i2c/fault-codes.rst +4 −1
Documentation/i2c/functionality.rst +15 −7
Documentation/i2c/gpio-fault-injection.rst +6 −6
Documentation/i2c/i2c-protocol.rst +19 −9
Documentation/i2c/i2c-stub.rst +11 −9
Documentation/i2c/i2c-topology.rst +44 −24
Documentation/i2c/index.rst +37 −0
Documentation/i2c/instantiating-devices.rst +25 −20
Documentation/i2c/muxes/i2c-mux-gpio.rst +14 −12
Documentation/i2c/old-module-parameters.rst +16 −11
Documentation/i2c/slave-eeprom-backend.rst +2 −2
Documentation/i2c/slave-interface.rst +19 −14
Documentation/i2c/smbus-protocol.rst +52 −34
Documentation/i2c/summary.rst +4 −2
Documentation/i2c/ten-bit-addresses.rst +5 −0
Documentation/i2c/upgrading-clients.rst +105 −99
Documentation/i2c/writing-clients.rst +58 −36
Documentation/index.rst +1 −0
Documentation/spi/spi-sc18is602 +1 −1
MAINTAINERS +24 −24
drivers/hwmon/atxp1.c +1 −1
drivers/hwmon/smm665.c +1 −1
drivers/i2c/Kconfig +2 −2
drivers/i2c/busses/Kconfig +1 −1
drivers/i2c/busses/i2c-i801.c +1 −1
drivers/i2c/busses/i2c-taos-evm.c +1 −1
drivers/i2c/i2c-core-base.c +2 −2
drivers/iio/dummy/iio_simple_dummy.c +1 −1
drivers/rtc/rtc-ds1374.c +1 −1
include/linux/i2c.h +1 −1

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

@@ -42,7 +42,7 @@ Optional properties: · 41 unmodified lines
42	42	This means that no unrelated I2C transactions are allowed on the parent I2C
43	43	adapter for the complete multiplexed I2C transaction.
44	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	47	For each i2c child node, an I2C child bus will be created. They will
48	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	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	87	If you have multiple BMCs, each connected to your Satellite MC via
88	88	a different I2C bus, you can instantiate a device for each of
89	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	142	If nothing happens when loading the adm1021 module, and you are certain
143	143	that your specific Xeon processor model includes compatible sensors, you
144	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	146	addresses are 0x18, 0x1a, 0x29, 0x2b, 0x4c, or 0x4e. It is likely that
147	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	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	79	details.
80	80
81	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	27	I2C address 0x27 by default, so an entry with I2C_BOARD_INFO("hih6130", 0x27)
28	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	31	instantiate I2C devices.
32	32
33	33	sysfs-Interface

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

@@ -17,7 +17,7 @@ Usage Notes · 16 unmodified lines
17	17	-----------
18	18
19	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	21	details.
22	22
23	23	Sysfs entries

Documentation/hwmon/lm25066.rst+1−1

@@ -76,7 +76,7 @@ Usage Notes · 75 unmodified lines
76	76	-----------
77	77
78	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	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	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	32	details.
33	33
34	34

Documentation/hwmon/max16065.rst+1−1

@@ -79,7 +79,7 @@ Usage Notes · 78 unmodified lines
79	79
80	80	This driver does not probe for devices, since there is no register which
81	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	83	details.
84	84
85	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	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	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	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	87	details.
88	88
89	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	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	59	details.
60	60
61	61	Module parameters

Documentation/hwmon/max8688.rst+1−1

@@ -28,7 +28,7 @@ Usage Notes · 27 unmodified lines
28	28	-----------
29	29
30	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	32	details.
33	33
34	34

Documentation/hwmon/menf21bmc.rst+1−1

@@ -28,7 +28,7 @@ Usage Notes · 27 unmodified lines
28	28	This driver is part of the MFD driver named "menf21bmc" and does
29	29	not auto-detect devices.
30	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	32	details.
33	33
34	34	Sysfs entries

Documentation/hwmon/pcf8591.rst+1−1

@@ -68,7 +68,7 @@ Accessing PCF8591 via /sys interface · 67 unmodified lines
68	68	The PCF8591 is plainly impossible to detect! Thus the driver won't even
69	69	try. You have to explicitly instantiate the device at the relevant
70	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	72	for details.
73	73
74	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	27	The device communicates with the I2C protocol. Sensors can have the I2C
28	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	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	36	chip, which has the same electrical interface.
37	37
38	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	40	instantiate the device.
41	41
42	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	30	Documentation/hwmon/sysfs-interface.rst under Temperatures).
31	31
32	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	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	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	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	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	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	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	41	The Via 686a southbridge has integrated hardware monitor functionality.
42	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	45	The Via 686a implements three temperature sensors, two fan rotation speed
46	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	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	125	details.
126	126
127	127	.. warning::

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

@@ -1,16 +1,19 @@
	1	+=========================
1	2	Kernel driver i2c-ali1535
	3	+=========================
2	4
3	5	Supported adapters:
4	6	* Acer Labs, Inc. ALI 1535 (south bridge)
	7	+
5	8	Datasheet: Now under NDA
6	9	http://www.ali.com.tw/
7	10
8	11	Authors:
9		− Frodo Looijaard <frodol@dds.nl>,
10		− Philip Edelbrock <phil@netroedge.com>,
11		− Mark D. Studebaker <mdsxyz123@yahoo.com>,
12		− Dan Eaton <dan.eaton@rocketlogix.com>,
13		− Stephen Rousset<stephen.rousset@rocketlogix.com>
	12	+ - Frodo Looijaard <frodol@dds.nl>,
	13	+ - Philip Edelbrock <phil@netroedge.com>,
	14	+ - Mark D. Studebaker <mdsxyz123@yahoo.com>,
	15	+ - Dan Eaton <dan.eaton@rocketlogix.com>,
	16	+ - Stephen Rousset<stephen.rousset@rocketlogix.com>
14	17
15	18	Description
16	19	-----------

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

@@ -1,7 +1,10 @@
	1	+=========================
1	2	Kernel driver i2c-ali1563
	3	+=========================
2	4
3	5	Supported adapters:
4	6	* Acer Labs, Inc. ALI 1563 (south bridge)
	7	+
5	8	Datasheet: Now under NDA
6	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	2	Kernel driver i2c-ali15x3
	3	+=========================
2	4
3	5	Supported adapters:
4	6	* Acer Labs, Inc. ALI 1533 and 1543C (south bridge)
	7	+
5	8	Datasheet: Now under NDA
6	9	http://www.ali.com.tw/
7	10
8	11	Authors:
9		− Frodo Looijaard <frodol@dds.nl>,
10		− Philip Edelbrock <phil@netroedge.com>,
11		− Mark D. Studebaker <mdsxyz123@yahoo.com>
	12	+ - Frodo Looijaard <frodol@dds.nl>,
	13	+ - Philip Edelbrock <phil@netroedge.com>,
	14	+ - Mark D. Studebaker <mdsxyz123@yahoo.com>
12	15
13	16	Module Parameters
14	17	-----------------
15	18
16	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	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	28	lspci. Don't use this unless the driver complains that the base address is
26	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	35	SMBus periodically hangs on ASUS P5A motherboards and can only be cleared
31	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	43	M1541 and M1543C South Bridges.
39	44
40	45	The M1543C is a South bridge for desktop systems.
	46	+
41	47	The M1541 is a South bridge for portable systems.
	48	+
42	49	They are part of the following ALI chipsets:
43	50
44	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	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	56	Some Aladdin V motherboards:
49		− Asus P5A
50		− Atrend ATC-5220
51		− BCM/GVC VP1541
52		− Biostar M5ALA
53		− Gigabyte GA-5AX (** Generally doesn't work because the BIOS doesn't
54		− enable the 7101 device! **)
55		− Iwill XA100 Plus
56		− Micronics C200
57		− Microstar (MSI) MS-5169
	57	+ - Asus P5A
	58	+ - Atrend ATC-5220
	59	+ - BCM/GVC VP1541
	60	+ - Biostar M5ALA
	61	+ - Gigabyte GA-5AX (Generally doesn't work because the BIOS doesn't
	62	+ enable the 7101 device!)
	63	+ - Iwill XA100 Plus
	64	+ - Micronics C200
	65	+ - Microstar (MSI) MS-5169
58	66
59	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	70	For an overview of these chips see http://www.acerlabs.com. At this time the
63	71	full data sheets on the web site are password protected, however if you
64	72	contact the ALI office in San Jose they may give you the password.
65	73
66	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	77	00:02.0 USB Controller: Acer Laboratories Inc. M5237 (rev 03)
70	78	00:03.0 Bridge: Acer Laboratories Inc. M7101 <= THIS IS THE ONE WE NEED
71	79	00:07.0 ISA bridge: Acer Laboratories Inc. M1533 (rev c3)
72	80	00:0f.0 IDE interface: Acer Laboratories Inc. M5229 (rev c1)
73	81
74		− IMPORTANT
75		−** If you have a M1533 or M1543C on the board and you get
76		−** "ali15x3: Error: Can't detect ali15x3!"
77		−** then run lspci.
78		−** If you see the 1533 and 5229 devices but NOT the 7101 device,
79		−** then you must enable ACPI, the PMU, SMB, or something similar
80		−** in the BIOS.
81		−** The driver won't work if it can't find the M7101 device.
	82	+.. important::
	83	+
	84	+ If you have a M1533 or M1543C on the board and you get
	85	+ "ali15x3: Error: Can't detect ali15x3!"
	86	+ then run lspci.
	87	+
	88	+ If you see the 1533 and 5229 devices but NOT the 7101 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	94	The SMB controller is part of the M7101 device, which is an ACPI-compliant
84	95	Power Management Unit (PMU).
@@ -109,4 +120,3 @@ There may be electrical problems on this board. · 24 unmodified lines
109	120	On the P5A, the W83781D sensor chip is on both the ISA and
110	121	SMBus. Therefore the SMBus hangs can generally be avoided
111	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

@@ -1,18 +1,22 @@
	1	+========================
1	2	Kernel driver i2c-amd756
	3	+========================
2	4
3	5	Supported adapters:
4	6	* AMD 756
5	7	* AMD 766
6	8	* AMD 768
7	9	* AMD 8111
	10	+
8	11	Datasheets: Publicly available on AMD website
9	12
10	13	* nVidia nForce
	14	+
11	15	Datasheet: Unavailable
12	16
13	17	Authors:
14		− Frodo Looijaard <frodol@dds.nl>,
15		− Philip Edelbrock <phil@netroedge.com>
	18	+ - Frodo Looijaard <frodol@dds.nl>,
	19	+ - Philip Edelbrock <phil@netroedge.com>
16	20
17	21	Description
18	22	-----------

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

@@ -1,4 +1,6 @@
	1	+=========================
1	2	Kernel driver i2c-adm8111
	3	+=========================
2	4
3	5	Supported adapters:
4	6	* AMD-8111 SMBus 2.0 PCI interface
@@ -13,14 +15,14 @@ Author: Vojtech Pavlik <vojtech@suse.cz> · 8 unmodified lines
13	15	Description
14	16	-----------
15	17
16		−If you see something like this:
	18	+If you see something like this::
17	19
18		−00:07.2 SMBus: Advanced Micro Devices [AMD] AMD-8111 SMBus 2.0 (rev 02)
19		− Subsystem: Advanced Micro Devices [AMD] AMD-8111 SMBus 2.0
20		− Flags: medium devsel, IRQ 19
21		− I/O ports at d400 [size=32]
	20	+ 00:07.2 SMBus: Advanced Micro Devices [AMD] AMD-8111 SMBus 2.0 (rev 02)
	21	+ Subsystem: Advanced Micro Devices [AMD] AMD-8111 SMBus 2.0
	22	+ Flags: medium devsel, IRQ 19
	23	+ I/O ports at d400 [size=32]
22	24
23		−in your 'lspci -v', then this driver is for your chipset.
	25	+in your ``lspci -v``, then this driver is for your chipset.
24	26
25	27	Process Call Support
26	28	--------------------

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

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

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

@@ -1,4 +1,7 @@
	1	+======================
1	2	Kernel driver i2c-i801
	3	+======================
	4	+
2	5
3	6	Supported adapters:
4	7	* Intel 82801AA and 82801AB (ICH and ICH0 - part of the
@@ -39,28 +42,33 @@ Supported adapters: · 34 unmodified lines
39	42	* Intel Comet Lake (PCH)
40	43	* Intel Elkhart Lake (PCH)
41	44	* Intel Tiger Lake (PCH)
	45	+
42	46	Datasheets: Publicly available at the Intel website
43	47
44	48	On Intel Patsburg and later chipsets, both the normal host SMBus controller
45	49	and the additional 'Integrated Device Function' controllers are supported.
46	50
47		−Authors:
48		− Mark Studebaker <mdsxyz123@yahoo.com>
49		− Jean Delvare <jdelvare@suse.de>
	51	+Authors:
	52	+ - Mark Studebaker <mdsxyz123@yahoo.com>
	53	+ - Jean Delvare <jdelvare@suse.de>
50	54
51	55
52	56	Module Parameters
53	57	-----------------
54	58
55	59	* disable_features (bit vector)
	60	+
56	61	Disable selected features normally supported by the device. This makes it
57	62	possible to work around possible driver or hardware bugs if the feature in
58	63	question doesn't work as intended for whatever reason. Bit values:
	64	+
	65	+ ==== =========================================
59	66	0x01 disable SMBus PEC
60	67	0x02 disable the block buffer
61	68	0x08 disable the I2C block read functionality
62	69	0x10 don't use interrupts
63	70	0x20 disable SMBus Host Notify
	71	+ ==== =========================================
64	72
65	73
66	74	Description
@@ -73,7 +81,7 @@ Pentium-based PCs, '815E' chipset, and others. · 6 unmodified lines
73	81
74	82	The ICH chips contain at least SEVEN separate PCI functions in TWO logical
75	83	PCI devices. An output of lspci will show something similar to the
76		−following:
	84	+following::
77	85
78	86	00:1e.0 PCI bridge: Intel Corporation: Unknown device 2418 (rev 01)
79	87	00:1f.0 ISA bridge: Intel Corporation: Unknown device 2410 (rev 01)
@@ -139,14 +147,14 @@ and you think there's something interesting on the SMBus (e.g. a · 59 unmodified lines
139	147	hardware monitoring chip), you need to add your board to the list.
140	148
141	149	The motherboard is identified using the subvendor and subdevice IDs of the
142		−host bridge PCI device. Get yours with "lspci -n -v -s 00:00.0":
	150	+host bridge PCI device. Get yours with ``lspci -n -v -s 00:00.0``::
143	151
144		−00:00.0 Class 0600: 8086:2570 (rev 02)
145		− Subsystem: 1043:80f2
146		− Flags: bus master, fast devsel, latency 0
147		− Memory at fc000000 (32-bit, prefetchable) [size=32M]
148		− Capabilities: [e4] #09 [2106]
149		− Capabilities: [a0] AGP version 3.0
	152	+ 00:00.0 Class 0600: 8086:2570 (rev 02)
	153	+ Subsystem: 1043:80f2
	154	+ Flags: bus master, fast devsel, latency 0
	155	+ Memory at fc000000 (32-bit, prefetchable) [size=32M]
	156	+ Capabilities: [e4] #09 [2106]
	157	+ Capabilities: [a0] AGP version 3.0
150	158
151	159	Here the host bridge ID is 2570 (82865G/PE/P), the subvendor ID is 1043
152	160	(Asus) and the subdevice ID is 80f2 (P4P800-X). You can find the symbolic
@@ -165,7 +173,8 @@ kernel. It's very convenient if you just want to check if there's · 12 unmodified lines
165	173	anything interesting on your hidden ICH SMBus.
166	174
167	175
168		−**********************
	176	+----------------------------------------------------------------------------
	177	+
169	178	The lm_sensors project gratefully acknowledges the support of Texas
170	179	Instruments in the initial development of this driver.
171	180

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

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

@@ -1,9 +1,12 @@
	1	+==================
1	2	Driver i2c-mlxcpld
	3	+==================
2	4
3	5	Author: Michael Shych <michaelsh@mellanox.com>
4	6
5	7	This is the Mellanox I2C controller logic, implemented in Lattice CPLD
6	8	device.
	9	+
7	10	Device supports:
8	11	- Master mode.
9	12	- One physical bus.
@@ -20,6 +23,8 @@ The next transaction types are supported: · 10 unmodified lines
20	23	- Write Byte/Block.
21	24
22	25	Registers:
	26	+
	27	+=============== === =======================================================================
23	28	CPBLTY 0x0 - capability reg.
24	29	Bits [6:5] - transaction length. b01 - 72B is supported,
25	30	36B in other case.
@@ -49,3 +54,4 @@ DATAx 0xa - 0x54 - 68 bytes data buffer regs. · 23 unmodified lines
49	54	For read transactions address is sent in a separate transaction and
50	55	specified in the four first bytes (DATA0 - DATA3). Data is read
51	56	starting from DATA0.
	57	+=============== === =======================================================================

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

@@ -1,10 +1,12 @@
	1	+=========================
1	2	Kernel driver i2c-nforce2
	3	+=========================
2	4
3	5	Supported adapters:
4		− * nForce2 MCP 10de:0064
5		− * nForce2 Ultra 400 MCP 10de:0084
6		− * nForce3 Pro150 MCP 10de:00D4
7		− * nForce3 250Gb MCP 10de:00E4
	6	+ * nForce2 MCP 10de:0064
	7	+ * nForce2 Ultra 400 MCP 10de:0084
	8	+ * nForce3 Pro150 MCP 10de:00D4
	9	+ * nForce3 250Gb MCP 10de:00E4
8	10	* nForce4 MCP 10de:0052
9	11	* nForce4 MCP-04 10de:0034
10	12	* nForce MCP51 10de:0264
@@ -16,26 +18,27 @@ Supported adapters: · 5 unmodified lines
16	18	* nForce MCP78S 10de:0752
17	19	* nForce MCP79 10de:0AA2
18	20
19		−Datasheet: not publicly available, but seems to be similar to the
	21	+Datasheet:
	22	+ not publicly available, but seems to be similar to the
20	23	AMD-8111 SMBus 2.0 adapter.
21	24
22	25	Authors:
23		− Hans-Frieder Vogt <hfvogt@gmx.net>,
24		− Thomas Leibold <thomas@plx.com>,
25		− Patrick Dreker <patrick@dreker.de>
26		−
	26	+ - Hans-Frieder Vogt <hfvogt@gmx.net>,
	27	+ - Thomas Leibold <thomas@plx.com>,
	28	+ - Patrick Dreker <patrick@dreker.de>
	29	+
27	30	Description
28	31	-----------
29	32
30	33	i2c-nforce2 is a driver for the SMBuses included in the nVidia nForce2 MCP.
31	34
32		−If your 'lspci -v' listing shows something like the following,
	35	+If your ``lspci -v`` listing shows something like the following::
33	36
34		−00:01.1 SMBus: nVidia Corporation: Unknown device 0064 (rev a2)
35		− Subsystem: Asustek Computer, Inc.: Unknown device 0c11
36		− Flags: 66Mhz, fast devsel, IRQ 5
37		− I/O ports at c000 [size=32]
38		− Capabilities: <available only to root>
	37	+ 00:01.1 SMBus: nVidia Corporation: Unknown device 0064 (rev a2)
	38	+ Subsystem: Asustek Computer, Inc.: Unknown device 0c11
	39	+ Flags: 66Mhz, fast devsel, IRQ 5
	40	+ I/O ports at c000 [size=32]
	41	+ Capabilities: <available only to root>
39	42
40	43	then this driver should support the SMBuses of your motherboard.
41	44

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

@@ -1,4 +1,6 @@
	1	+============================
1	2	Kernel driver i2c-nvidia-gpu
	3	+============================
2	4
3	5	Datasheet: not publicly available.
4	6
@@ -11,8 +13,8 @@ Description · 6 unmodified lines
11	13	i2c-nvidia-gpu is a driver for I2C controller included in NVIDIA Turing
12	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	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

@@ -1,4 +1,6 @@
	1	+========================
1	2	Kernel driver i2c-ocores
	3	+========================
2	4
3	5	Supported adapters:
4	6	* OpenCores.org I2C controller by Richard Herveille (see datasheet link)
@@ -23,9 +25,9 @@ distance between registers and the input clock speed. · 18 unmodified lines
23	25	There is also a possibility to attach a list of i2c_board_info which
24	26	the i2c-ocores driver will add to the bus upon creation.
25	27
26		−E.G. something like:
	28	+E.G. something like::
27	29
28		−static struct resource ocores_resources[] = {
	30	+ static struct resource ocores_resources[] = {
29	31	[0] = {
30	32	.start = MYI2C_BASEADDR,
31	33	.end = MYI2C_BASEADDR + 8,
@@ -36,10 +38,10 @@ static struct resource ocores_resources[] = { · 4 unmodified lines
36	38	.end = MYI2C_IRQ,
37	39	.flags = IORESOURCE_IRQ,
38	40	},
39		−};
	41	+ };
40	42
41		−/* optional board info */
42		−struct i2c_board_info ocores_i2c_board_info[] = {
	43	+ /* optional board info */
	44	+ struct i2c_board_info ocores_i2c_board_info[] = {
43	45	{
44	46	I2C_BOARD_INFO("tsc2003", 0x48),
45	47	.platform_data = &tsc2003_platform_data,
@@ -49,20 +51,20 @@ struct i2c_board_info ocores_i2c_board_info[] = { · 3 unmodified lines
49	51	I2C_BOARD_INFO("adv7180", 0x42 >> 1),
50	52	.irq = ADV_IRQ
51	53	}
52		−};
	54	+ };
53	55
54		−static struct ocores_i2c_platform_data myi2c_data = {
	56	+ static struct ocores_i2c_platform_data myi2c_data = {
55	57	.regstep = 2, /* two bytes between registers */
56	58	.clock_khz = 50000, /* input clock of 50MHz */
57	59	.devices = ocores_i2c_board_info, /* optional table of devices */
58	60	.num_devices = ARRAY_SIZE(ocores_i2c_board_info), /* table size */
59		−};
	61	+ };
60	62
61		−static struct platform_device myi2c = {
	63	+ static struct platform_device myi2c = {
62	64	.name = "ocores-i2c",
63	65	.dev = {
64	66	.platform_data = &myi2c_data,
65	67	},
66	68	.num_resources = ARRAY_SIZE(ocores_resources),
67	69	.resource = ocores_resources,
68		−};
	70	+ };

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	2	Kernel driver i2c-parport-light
	3	+===============================
2	4
3	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	8	on the parport driver, and uses direct I/O access instead. This might be
7	9	preferred on embedded systems where wasting memory for the clean but heavy
8	10	parport handling is not an option. The drawback is a reduced portability
9		−and the impossibility to daisy-chain other parallel port devices.
10		−
	11	+and the impossibility to daisy-chain other parallel port devices.
	12	+
11	13	Please see i2c-parport for documentation.
12	14
13	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	2	Kernel driver i2c-pca-isa
	3	+=========================
2	4
3	5	Supported adapters:
	6	+
4	7	This driver supports ISA boards using the Philips PCA 9564
5	8	Parallel bus to I2C bus controller
6	9
@@ -10,11 +13,11 @@ Module Parameters · 3 unmodified lines
10	13	-----------------
11	14
12	15	* base int
13		− I/O base address
	16	+ I/O base address
14	17	* irq int
15		− IRQ interrupt
	18	+ IRQ interrupt
16	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	22	Description
20	23	-----------

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

@@ -1,4 +1,6 @@
	1	+=======================
1	2	Kernel driver i2c-piix4
	3	+=======================
2	4
3	5	Supported adapters:
4	6	* Intel 82371AB PIIX4 and PIIX4E
@@ -20,9 +22,9 @@ Supported adapters: · 15 unmodified lines
20	22	* Standard Microsystems (SMSC) SLC90E66 (Victory66) southbridge
21	23	Datasheet: Publicly available at the SMSC website http://www.smsc.com
22	24
23		−Authors:
24		− Frodo Looijaard <frodol@dds.nl>
25		− Philip Edelbrock <phil@netroedge.com>
	25	+Authors:
	26	+ - Frodo Looijaard <frodol@dds.nl>
	27	+ - Philip Edelbrock <phil@netroedge.com>
26	28
27	29
28	30	Module Parameters
@@ -39,16 +41,16 @@ Description · 10 unmodified lines
39	41
40	42	The PIIX4 (properly known as the 82371AB) is an Intel chip with a lot of
41	43	functionality. Among other things, it implements the PCI bus. One of its
42		−minor functions is implementing a System Management Bus. This is a true
	44	+minor functions is implementing a System Management Bus. This is a true
43	45	SMBus - you can not access it on I2C levels. The good news is that it
44	46	natively understands SMBus commands and you do not have to worry about
45	47	timing problems. The bad news is that non-SMBus devices connected to it can
46	48	confuse it mightily. Yes, this is known to happen...
47	49
48		−Do 'lspci -v' and see whether it contains an entry like this:
	50	+Do ``lspci -v`` and see whether it contains an entry like this::
49	51
50		−0000:00:02.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 02)
51		− Flags: medium devsel, IRQ 9
	52	+ 0000:00:02.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 02)
	53	+ Flags: medium devsel, IRQ 9
52	54
53	55	Bus and device numbers may differ, but the function number must be
54	56	identical (like many PCI devices, the PIIX4 incorporates a number of
@@ -91,7 +93,7 @@ the SMI mode. · 36 unmodified lines
91	93	device is located at 00:0f.0.
92	94	2) Now you just need to change the value in 0xD2 register. Get it first with
93	95	command: lspci -xxx -s 00:0f.0
94		− If the value is 0x3 then you need to change it to 0x1
	96	+ If the value is 0x3 then you need to change it to 0x1:
95	97	setpci -s 00:0f.0 d2.b=1
96	98
97	99	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

@@ -1,9 +1,11 @@
	1	+=========================
1	2	Kernel driver i2c-sis5595
	3	+=========================
2	4
3	5	Authors:
4		− Frodo Looijaard <frodol@dds.nl>,
5		− Mark D. Studebaker <mdsxyz123@yahoo.com>,
6		− Philip Edelbrock <phil@netroedge.com>
	6	+ - Frodo Looijaard <frodol@dds.nl>,
	7	+ - Mark D. Studebaker <mdsxyz123@yahoo.com>,
	8	+ - Philip Edelbrock <phil@netroedge.com>
7	9
8	10	Supported adapters:
9	11	* Silicon Integrated Systems Corp. SiS5595 Southbridge
@@ -11,14 +13,19 @@ Supported adapters: · 1 unmodified line
11	13
12	14	Note: all have mfr. ID 0x1039.
13	15
	16	+ ========= ======
14	17	SUPPORTED PCI ID
	18	+ ========= ======
15	19	5595 0008
	20	+ ========= ======
16	21
17	22	Note: these chips contain a 0008 device which is incompatible with the
18	23	5595. We recognize these by the presence of the listed
19	24	"blacklist" PCI ID and refuse to load.
20	25
	26	+ ============= ====== ================
21	27	NOT SUPPORTED PCI ID BLACKLIST PCI ID
	28	+ ============= ====== ================
22	29	540 0008 0540
23	30	550 0008 0550
24	31	5513 0008 5511
@@ -36,15 +43,18 @@ Note: all have mfr. ID 0x1039. · 11 unmodified lines
36	43	735 0008 0735
37	44	745 0008 0745
38	45	746 0008 0746
	46	+ ============= ====== ================
39	47
40	48	Module Parameters
41	49	-----------------
42	50
43		−* force_addr=0xaddr Set the I/O base address. Useful for boards
	51	+================== =====================================================
	52	+force_addr=0xaddr Set the I/O base address. Useful for boards
44	53	that don't set the address in the BIOS. Does not do a
45	54	PCI force; the device must still be present in lspci.
46	55	Don't use this unless the driver complains that the
47	56	base address is not set.
	57	+================== =====================================================
48	58
49	59	Description
50	60	-----------
@@ -56,4 +66,3 @@ WARNING: If you are trying to access the integrated sensors on the SiS5595 · 5 unmodified lines
56	66	chip, you want the sis5595 driver for those, not this driver. This driver
57	67	is a BUS driver, not a CHIP driver. A BUS driver is used by other CHIP
58	68	drivers to access chips on the bus.
59		−

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

@@ -1,13 +1,18 @@
	1	+========================
1	2	Kernel driver i2c-sis96x
	3	+========================
2	4
3	5	Replaces 2.4.x i2c-sis645
4	6
5	7	Supported adapters:
	8	+
6	9	* Silicon Integrated Systems Corp (SiS)
	10	+
7	11	Any combination of these host bridges:
8	12	645, 645DX (aka 646), 648, 650, 651, 655, 735, 745, 746
	13	+
9	14	and these south bridges:
10		− 961, 962, 963(L)
	15	+ 961, 962, 963(L)
11	16
12	17	Author: Mark M. Hoffman <mhoffman@lightlink.com>
13	18
@@ -21,17 +26,17 @@ those of the SiS630, although they are located in a completely different · 7 unmodified lines
21	26	place. Thanks to Alexander Malysh <amalysh@web.de> for providing the
22	27	SiS630 datasheet (and driver).
23	28
24		−The command "lspci" as root should produce something like these lines:
	29	+The command ``lspci`` as root should produce something like these lines::
25	30
26		−00:00.0 Host bridge: Silicon Integrated Systems [SiS]: Unknown device 0645
27		−00:02.0 ISA bridge: Silicon Integrated Systems [SiS] 85C503/5513
28		−00:02.1 SMBus: Silicon Integrated Systems [SiS]: Unknown device 0016
	31	+ 00:00.0 Host bridge: Silicon Integrated Systems [SiS]: Unknown device 0645
	32	+ 00:02.0 ISA bridge: Silicon Integrated Systems [SiS] 85C503/5513
	33	+ 00:02.1 SMBus: Silicon Integrated Systems [SiS]: Unknown device 0016
29	34
30		−or perhaps this...
	35	+or perhaps this::
31	36
32		−00:00.0 Host bridge: Silicon Integrated Systems [SiS]: Unknown device 0645
33		−00:02.0 ISA bridge: Silicon Integrated Systems [SiS]: Unknown device 0961
34		−00:02.1 SMBus: Silicon Integrated Systems [SiS]: Unknown device 0016
	37	+ 00:00.0 Host bridge: Silicon Integrated Systems [SiS]: Unknown device 0645
	38	+ 00:02.0 ISA bridge: Silicon Integrated Systems [SiS]: Unknown device 0961
	39	+ 00:02.1 SMBus: Silicon Integrated Systems [SiS]: Unknown device 0016
35	40
36	41	(kernel versions later than 2.4.18 may fill in the "Unknown"s)
37	42
@@ -50,7 +55,7 @@ TO DOs · 12 unmodified lines
50	55	------
51	56
52	57	* The driver does not support SMBus block reads/writes; I may add them if a
53		−scenario is found where they're needed.
	58	+ scenario is found where they're needed.
54	59
55	60
56	61	Thank You
@@ -58,16 +63,20 @@ Thank You · 1 unmodified line
58	63
59	64	Mark D. Studebaker <mdsxyz123@yahoo.com>
60	65	- design hints and bug fixes
	66	+
61	67	Alexander Maylsh <amalysh@web.de>
62	68	- ditto, plus an important datasheet... almost the one I really wanted
	69	+
63	70	Hans-Günter Lütke Uphues <hg_lu@t-online.de>
64	71	- patch for SiS735
	72	+
65	73	Robert Zwerus <arzie@dds.nl>
66	74	- testing for SiS645DX
	75	+
67	76	Kianusch Sayah Karadji <kianusch@sk-tech.net>
68	77	- patch for SiS645DX/962
	78	+
69	79	Ken Healy
70	80	- patch for SiS655
71	81
72	82	To anyone else who has written w/ feedback, thanks!
73		−

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

@@ -1,4 +1,6 @@
	1	+==========================
1	2	Kernel driver i2c-taos-evm
	3	+==========================
2	4
3	5	Author: Jean Delvare <jdelvare@suse.de>
4	6
@@ -23,10 +25,10 @@ Using this driver · 18 unmodified lines
23	25	In order to use this driver, you'll need the serport driver, and the
24	26	inputattach tool, which is part of the input-utils package. The following
25	27	commands will tell the kernel that you have a TAOS EVM on the first
26		−serial port:
	28	+serial port::
27	29
28		−# modprobe serport
29		−# inputattach --taos-evm /dev/ttyS0
	30	+ # modprobe serport
	31	+ # inputattach --taos-evm /dev/ttyS0
30	32
31	33
32	34	Technical details

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

@@ -1,4 +1,6 @@
	1	+=====================
1	2	Kernel driver i2c-via
	3	+=====================
2	4
3	5	Supported adapters:
4	6	* VIA Technologies, InC. VT82C586B
@@ -12,23 +14,27 @@ Description · 7 unmodified lines
12	14	i2c-via is an i2c bus driver for motherboards with VIA chipset.
13	15
14	16	The following VIA pci chipsets are supported:
15		− - MVP3, VP3, VP2/97, VPX/97
	17	+ - MVP3, VP3, VP2/97, VPX/97
16	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	22	Bridge: VIA Technologies, Inc. VT82C586B ACPI (rev 10)
21	23
22		− Problems?
23		−
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.
	24	+Problems?
	25	+---------
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	39	datasheets, but there are several ways the motherboard manufacturer
33	40	can actually wire the lines.
34		−

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

@@ -1,4 +1,6 @@
	1	+========================
1	2	Kernel driver i2c-viapro
	3	+========================
2	4
3	5	Supported adapters:
4	6	* VIA Technologies, Inc. VT82C596A/B
@@ -26,9 +28,9 @@ Supported adapters: · 21 unmodified lines
26	28	Datasheet: available on http://linux.via.com.tw
27	29
28	30	Authors:
29		− Kyösti Mälkki <kmalkki@cc.hut.fi>,
30		− Mark D. Studebaker <mdsxyz123@yahoo.com>,
31		− Jean Delvare <jdelvare@suse.de>
	31	+ - Kyösti Mälkki <kmalkki@cc.hut.fi>,
	32	+ - Mark D. Studebaker <mdsxyz123@yahoo.com>,
	33	+ - Jean Delvare <jdelvare@suse.de>
32	34
33	35	Module Parameters
34	36	-----------------
@@ -44,8 +46,9 @@ Description · 9 unmodified lines
44	46	i2c-viapro is a true SMBus host driver for motherboards with one of the
45	47	supported VIA south bridges.
46	48
47		−Your lspci -n listing must show one of these :
	49	+Your ``lspci -n`` listing must show one of these :
48	50
	51	+ ================ ======================
49	52	device 1106:3050 (VT82C596A function 3)
50	53	device 1106:3051 (VT82C596B function 3)
51	54	device 1106:3057 (VT82C686 function 4)
@@ -61,6 +64,7 @@ Your lspci -n listing must show one of these : · 9 unmodified lines
61	64	device 1106:8353 (VX800/VX820)
62	65	device 1106:8409 (VX855/VX875)
63	66	device 1106:8410 (VX900)
	67	+ ================ ======================
64	68
65	69	If none of these show up, you should look in the BIOS for settings like
66	70	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

@@ -1,4 +1,6 @@
	1	+========================
1	2	Kernel driver scx200_acb
	3	+========================
2	4
3	5	Author: Christer Weinigel <wingel@nano-system.com>
4	6
@@ -25,8 +27,11 @@ Device-specific notes · 20 unmodified lines
25	27
26	28	The SC1100 WRAP boards are known to use base addresses 0x810 and 0x820.
27	29	If the scx200_acb driver is built into the kernel, add the following
28		−parameter to your boot command line:
	30	+parameter to your boot command line::
	31	+
29	32	scx200_acb.base=0x810,0x820
	33	+
30	34	If the scx200_acb driver is built as a module, add the following line to
31		−a configuration file in /etc/modprobe.d/ instead:
	35	+a configuration file in /etc/modprobe.d/ instead::
	36	+
32	37	options scx200_acb base=0x810,0x820

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

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

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

@@ -1,3 +1,7 @@
	1	+=====================
	2	+I2C/SMBUS Fault Codes
	3	+=====================
	4	+
1	5	This is a summary of the most important conventions for use of fault
2	6	codes in the I2C/SMBus stack.
3	7
@@ -125,4 +129,3 @@ ETIMEDOUT · 121 unmodified lines
125	129	when a slave stretches clocks too far. I2C has no such
126	130	timeouts, but it's normal for I2C adapters to impose some
127	131	arbitrary limits (much longer than SMBus!) too.
128		−

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

@@ -1,11 +1,15 @@
	1	+=======================
	2	+I2C/SMBus Functionality
	3	+=======================
	4	+
1	5	INTRODUCTION
2	6	------------
3	7
4		−Because not every I2C or SMBus adapter implements everything in the
	8	+Because not every I2C or SMBus adapter implements everything in the
5	9	I2C specifications, a client can not trust that everything it needs
6	10	is implemented when it is given the option to attach to an adapter:
7	11	the client needs some way to check whether an adapter has the needed
8		−functionality.
	12	+functionality.
9	13
10	14
11	15	FUNCTIONALITY CONSTANTS
@@ -14,6 +18,7 @@ FUNCTIONALITY CONSTANTS · 2 unmodified lines
14	18	For the most up-to-date list of functionality constants, please check
15	19	<uapi/linux/i2c.h>!
16	20
	21	+ =============================== ==============================================
17	22	I2C_FUNC_I2C Plain i2c-level commands (Pure SMBus
18	23	adapters typically can not do these)
19	24	I2C_FUNC_10BIT_ADDR Handles the 10-bit address extensions
@@ -33,9 +38,11 @@ For the most up-to-date list of functionality constants, please check · 13 unmodified lines
33	38	I2C_FUNC_SMBUS_WRITE_BLOCK_DATA Handles the SMBus write_block_data command
34	39	I2C_FUNC_SMBUS_READ_I2C_BLOCK Handles the SMBus read_i2c_block_data command
35	40	I2C_FUNC_SMBUS_WRITE_I2C_BLOCK Handles the SMBus write_i2c_block_data command
	41	+ =============================== ==============================================
36	42
37	43	A few combinations of the above flags are also defined for your convenience:
38	44
	45	+ ========================= ======================================
39	46	I2C_FUNC_SMBUS_BYTE Handles the SMBus read_byte
40	47	and write_byte commands
41	48	I2C_FUNC_SMBUS_BYTE_DATA Handles the SMBus read_byte_data
@@ -49,6 +56,7 @@ A few combinations of the above flags are also defined for your convenience: · 7 unmodified lines
49	56	I2C_FUNC_SMBUS_EMUL Handles all SMBus commands that can be
50	57	emulated by a real I2C adapter (using
51	58	the transparent emulation layer)
	59	+ ========================= ======================================
52	60
53	61	In kernel versions prior to 3.5 I2C_FUNC_NOSTART was implemented as
54	62	part of I2C_FUNC_PROTOCOL_MANGLING.
@@ -58,11 +66,11 @@ ADAPTER IMPLEMENTATION · 3 unmodified lines
58	66	----------------------
59	67
60	68	When you write a new adapter driver, you will have to implement a
61		−function callback `functionality'. Typical implementations are given
	69	+function callback ``functionality``. Typical implementations are given
62	70	below.
63	71
64	72	A typical SMBus-only adapter would list all the SMBus transactions it
65		−supports. This example comes from the i2c-piix4 driver:
	73	+supports. This example comes from the i2c-piix4 driver::
66	74
67	75	static u32 piix4_func(struct i2c_adapter *adapter)
68	76	{
@@ -72,7 +80,7 @@ supports. This example comes from the i2c-piix4 driver: · 3 unmodified lines
72	80	}
73	81
74	82	A typical full-I2C adapter would use the following (from the i2c-pxa
75		−driver):
	83	+driver)::
76	84
77	85	static u32 i2c_pxa_functionality(struct i2c_adapter *adap)
78	86	{
@@ -94,7 +102,7 @@ CLIENT CHECKING · 15 unmodified lines
94	102	Before a client tries to attach to an adapter, or even do tests to check
95	103	whether one of the devices it supports is present on an adapter, it should
96	104	check whether the needed functionality is present. The typical way to do
97		−this is (from the lm75 driver):
	105	+this is (from the lm75 driver)::
98	106
99	107	static int lm75_detect(...)
100	108	{
@@ -129,7 +137,7 @@ If you try to access an adapter from a userspace program, you will have · 28 unmodified lines
129	137	to use the /dev interface. You will still have to check whether the
130	138	functionality you need is supported, of course. This is done using
131	139	the I2C_FUNCS ioctl. An example, adapted from the i2cdetect program, is
132		−below:
	140	+below::
133	141
134	142	int file;
135	143	if (file = open("/dev/i2c-0", O_RDWR) < 0) {

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

@@ -104,10 +104,10 @@ There doesn't need to be a device at this address because arbitration lost · 103 unmodified lines
104	104	should be detected beforehand. Also note, that SCL going down is monitored
105	105	using interrupts, so the interrupt latency might cause the first bits to be not
106	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 &
110		−# i2cget -y <bus_to_test> 0x3f
	109	+ # echo 200 > lose_arbitration &
	110	+ # i2cget -y <bus_to_test> 0x3f
111	111
112	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	127	process is interruptible, though.
128	128
129	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 &
133		−# i2cget -y <bus_to_test> <some_address>
	132	+ # echo 0 > inject_panic &
	133	+ # i2cget -y <bus_to_test> <some_address>
134	134
135	135	Note that there doesn't need to be a device listening to the address you are
136	136	using. Results may vary depending on that, though.

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

@@ -1,8 +1,13 @@
	1	+============
	2	+I2C Protocol
	3	+============
	4	+
1	5	This document describes the i2c protocol. Or will, when it is finished :-)
2	6
3	7	Key to symbols
4	8	==============
5	9
	10	+=============== =============================================================
6	11	S (1 bit) : Start bit
7	12	P (1 bit) : Stop bit
8	13	Rd/Wr (1 bit) : Read/Write bit. Rd equals 1, Wr equals 0.
@@ -15,33 +20,35 @@ Data (8 bits): A plain data byte. Sometimes, I write DataLow, DataHigh · 6 unmodified lines
15	20	for 16 bit data.
16	21	Count (8 bits): A data byte containing the length of a block operation.
17	22
18		−[..]: Data sent by I2C device, as opposed to data sent by the host adapter.
	23	+[..]: Data sent by I2C device, as opposed to data sent by the
	24	+ host adapter.
	25	+=============== =============================================================
19	26
20	27
21	28	Simple send transaction
22		−======================
	29	+=======================
23	30
24		−This corresponds to i2c_master_send.
	31	+This corresponds to i2c_master_send::
25	32
26	33	S Addr Wr [A] Data [A] Data [A] ... [A] Data [A] P
27	34
28	35
29	36	Simple receive transaction
30		−===========================
	37	+==========================
31	38
32		−This corresponds to i2c_master_recv
	39	+This corresponds to i2c_master_recv::
33	40
34	41	S Addr Rd [A] [Data] A [Data] A ... A [Data] NA P
35	42
36	43
37	44	Combined transactions
38		−====================
	45	+=====================
39	46
40	47	This corresponds to i2c_transfer
41	48
42	49	They are just like the above transactions, but instead of a stop bit P
43	50	a start bit S is sent and the transaction continues. An example of
44		−a byte read, followed by a byte write:
	51	+a byte read, followed by a byte write::
45	52
46	53	S Addr Rd [A] [Data] NA S Addr Wr [A] Data [A] P
47	54
@@ -65,8 +72,10 @@ I2C_M_NO_RD_ACK: · 17 unmodified lines
65	72	I2C_M_NOSTART:
66	73	In a combined transaction, no 'S Addr Wr/Rd [A]' is generated at some
67	74	point. For example, setting I2C_M_NOSTART on the second partial message
68		− generates something like:
	75	+ generates something like::
	76	+
69	77	S Addr Rd [A] [Data] NA Data [A] P
	78	+
70	79	If you set the I2C_M_NOSTART variable for the first partial message,
71	80	we do not generate Addr, but we do generate the startbit S. This will
72	81	probably confuse all other clients on your bus, so don't try this.
@@ -79,7 +88,8 @@ I2C_M_NOSTART: · 6 unmodified lines
79	88	I2C_M_REV_DIR_ADDR:
80	89	This toggles the Rd/Wr flag. That is, if you want to do a write, but
81	90	need to emit an Rd instead of a Wr, or vice versa, you set this
82		− flag. For example:
	91	+ flag. For example::
	92	+
83	93	S Addr Rd [A] Data [A] Data [A] ... [A] Data [A] P
84	94
85	95	I2C_M_STOP:

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

@@ -1,6 +1,9 @@
1		−MODULE: i2c-stub
	1	+========
	2	+i2c-stub
	3	+========
2	4
3		−DESCRIPTION:
	5	+Description
	6	+===========
4	7
5	8	This module is a very simple fake I2C/SMBus driver. It implements six
6	9	types of SMBus commands: write quick, (r/w) byte, (r/w) byte data, (r/w)
@@ -28,6 +31,7 @@ SMBus block operations. Writes can be partial. Block read commands always · 21 unmodified lines
28	31	return the number of bytes selected with the largest write so far.
29	32
30	33	The typical use-case is like this:
	34	+
31	35	1. load this module
32	36	2. use i2cset (from the i2c-tools project) to pre-load some data
33	37	3. load the target chip driver module
@@ -36,7 +40,8 @@ The typical use-case is like this: · 2 unmodified lines
36	40	There's a script named i2c-stub-from-dump in the i2c-tools package which
37	41	can load register values automatically from a chip dump.
38	42
39		−PARAMETERS:
	43	+Parameters
	44	+==========
40	45
41	46	int chip_addr[10]:
42	47	The SMBus addresses to emulate chips at.
@@ -47,18 +52,15 @@ unsigned long functionality: · 4 unmodified lines
47	52	value 0x1f0000 would only enable the quick, byte and byte data
48	53	commands.
49	54
50		−u8 bank_reg[10]
51		−u8 bank_mask[10]
52		−u8 bank_start[10]
53		−u8 bank_end[10]:
	55	+u8 bank_reg[10], u8 bank_mask[10], u8 bank_start[10], u8 bank_end[10]:
54	56	Optional bank settings. They tell which bits in which register
55	57	select the active bank, as well as the range of banked registers.
56	58
57		−CAVEATS:
	59	+Caveats
	60	+=======
58	61
59	62	If your target driver polls some byte or word waiting for it to change, the
60	63	stub could lock it up. Use i2cset to unlock it.
61	64
62	65	If you spam it hard enough, printk can be lossy. This module really wants
63	66	something like relayfs.
64		−

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

@@ -1,3 +1,4 @@
	1	+============
1	2	I2C topology
2	3	============
3	4
@@ -14,6 +15,7 @@ than a straight-forward i2c bus with one adapter and one or more devices. · 10 unmodified lines
14	15	that has to be operated before the device can be accessed.
15	16
16	17	Etc
	18	+===
17	19
18	20	These constructs are represented as i2c adapter trees by Linux, where
19	21	each adapter has a parent adapter (except the root adapter) and zero or
@@ -37,7 +39,9 @@ mux-locked or parent-locked muxes. As is evident from below, it can be · 17 unmodified lines
37	39	useful to know if a mux is mux-locked or if it is parent-locked. The
38	40	following list was correct at the time of writing:
39	41
40		−In drivers/i2c/muxes/
	42	+In drivers/i2c/muxes/:
	43	+
	44	+====================== =============================================
41	45	i2c-arb-gpio-challenge Parent-locked
42	46	i2c-mux-gpio Normally parent-locked, mux-locked iff
43	47	all involved gpio pins are controlled by the
@@ -52,18 +56,25 @@ i2c-mux-pinctrl Normally parent-locked, mux-locked iff · 8 unmodified lines
52	56	all involved pinctrl devices are controlled
53	57	by the same i2c root adapter that they mux.
54	58	i2c-mux-reg Parent-locked
	59	+====================== =============================================
	60	+
	61	+In drivers/iio/:
55	62
56		−In drivers/iio/
	63	+====================== =============================================
57	64	gyro/mpu3050 Mux-locked
58	65	imu/inv_mpu6050/ Mux-locked
	66	+====================== =============================================
59	67
60		−In drivers/media/
	68	+In drivers/media/:
	69	+
	70	+======================= =============================================
61	71	dvb-frontends/lgdt3306a Mux-locked
62	72	dvb-frontends/m88ds3103 Parent-locked
63	73	dvb-frontends/rtl2830 Parent-locked
64	74	dvb-frontends/rtl2832 Mux-locked
65	75	dvb-frontends/si2168 Mux-locked
66	76	usb/cx231xx/ Parent-locked
	77	+======================= =============================================
67	78
68	79
69	80	Mux-locked muxes
@@ -78,6 +89,7 @@ full transaction, unrelated i2c transfers may interleave the different · 8 unmodified lines
78	89	stages of the transaction. This has the benefit that the mux driver
79	90	may be easier and cleaner to implement, but it has some caveats.
80	91
	92	+==== =====================================================================
81	93	ML1. If you build a topology with a mux-locked mux being the parent
82	94	of a parent-locked mux, this might break the expectation from the
83	95	parent-locked mux that the root adapter is locked during the
@@ -105,11 +117,15 @@ ML4. If any non-i2c operation in the mux driver changes the i2c mux state, · 21 unmodified lines
105	117	Otherwise garbage may appear on the bus as seen from devices
106	118	behind the mux, when an unrelated i2c transfer is in flight during
107	119	the non-i2c mux-changing operation.
	120	+==== =====================================================================
108	121
109	122
110	123	Mux-locked Example
111	124	------------------
112	125
	126	+
	127	+::
	128	+
113	129	.----------. .--------.
114	130	.--------. \| mux- \|-----\| dev D1 \|
115	131	\| root \|--+--\| locked \| '--------'
@@ -148,6 +164,7 @@ adapter during the transaction are unlocked i2c transfers (using e.g. · 32 unmodified lines
148	164	__i2c_transfer), or a deadlock will follow. There are a couple of
149	165	caveats.
150	166
	167	+==== ====================================================================
151	168	PL1. If you build a topology with a parent-locked mux being the child
152	169	of another mux, this might break a possible assumption from the
153	170	child mux that the root adapter is unused between its select op
@@ -161,11 +178,14 @@ PL2. If select/deselect calls out to other subsystems such as gpio, · 7 unmodified lines
161	178	caused by these subsystems are unlocked. This can be convoluted to
162	179	accomplish, maybe even impossible if an acceptably clean solution
163	180	is sought.
	181	+==== ====================================================================
164	182
165	183
166	184	Parent-locked Example
167	185	---------------------
168	186
	187	+::
	188	+
169	189	.----------. .--------.
170	190	.--------. \| parent- \|-----\| dev D1 \|
171	191	\| root \|--+--\| locked \| '--------'
@@ -177,20 +197,20 @@ Parent-locked Example · 5 unmodified lines
177	197
178	198	When there is an access to D1, this happens:
179	199
180		− 1. Someone issues an i2c-transfer to D1.
181		− 2. M1 locks muxes on its parent (the root adapter in this case).
182		− 3. M1 locks its parent adapter.
183		− 4. M1 calls ->select to ready the mux.
184		− 5. If M1 does any i2c-transfers (on this root adapter) as part of
185		− its select, those transfers must be unlocked i2c-transfers so
186		− that they do not deadlock the root adapter.
187		− 6. M1 feeds the i2c-transfer from step 1 to the root adapter as an
188		− unlocked i2c-transfer, so that it does not deadlock the parent
189		− adapter.
190		− 7. M1 calls ->deselect, if it has one.
191		− 8. Same rules as in step 5, but for ->deselect.
192		− 9. M1 unlocks its parent adapter.
193		−10. M1 unlocks muxes on its parent.
	200	+ 1. Someone issues an i2c-transfer to D1.
	201	+ 2. M1 locks muxes on its parent (the root adapter in this case).
	202	+ 3. M1 locks its parent adapter.
	203	+ 4. M1 calls ->select to ready the mux.
	204	+ 5. If M1 does any i2c-transfers (on this root adapter) as part of
	205	+ its select, those transfers must be unlocked i2c-transfers so
	206	+ that they do not deadlock the root adapter.
	207	+ 6. M1 feeds the i2c-transfer from step 1 to the root adapter as an
	208	+ unlocked i2c-transfer, so that it does not deadlock the parent
	209	+ adapter.
	210	+ 7. M1 calls ->deselect, if it has one.
	211	+ 8. Same rules as in step 5, but for ->deselect.
	212	+ 9. M1 unlocks its parent adapter.
	213	+ 10. M1 unlocks muxes on its parent.
194	214
195	215
196	216	This means that accesses to both D2 and D3 are locked out for the full
@@ -203,7 +223,7 @@ Complex Examples · 6 unmodified lines
203	223	Parent-locked mux as parent of parent-locked mux
204	224	------------------------------------------------
205	225
206		−This is a useful topology, but it can be bad.
	226	+This is a useful topology, but it can be bad::
207	227
208	228	.----------. .----------. .--------.
209	229	.--------. \| parent- \|-----\| parent- \|-----\| dev D1 \|
@@ -227,7 +247,7 @@ through and be seen by the M2 adapter, thus closing M2 prematurely. · 17 unmodified lines
227	247	Mux-locked mux as parent of mux-locked mux
228	248	------------------------------------------
229	249
230		−This is a good topology.
	250	+This is a good topology::
231	251
232	252	.----------. .----------. .--------.
233	253	.--------. \| mux- \|-----\| mux- \|-----\| dev D1 \|
@@ -248,7 +268,7 @@ are still possibly interleaved. · 14 unmodified lines
248	268	Mux-locked mux as parent of parent-locked mux
249	269	---------------------------------------------
250	270
251		−This is probably a bad topology.
	271	+This is probably a bad topology::
252	272
253	273	.----------. .----------. .--------.
254	274	.--------. \| mux- \|-----\| parent- \|-----\| dev D1 \|
@@ -282,7 +302,7 @@ auto-closing, the topology is fine. · 27 unmodified lines
282	302	Parent-locked mux as parent of mux-locked mux
283	303	---------------------------------------------
284	304
285		−This is a good topology.
	305	+This is a good topology::
286	306
287	307	.----------. .----------. .--------.
288	308	.--------. \| parent- \|-----\| mux- \|-----\| dev D1 \|
@@ -306,7 +326,7 @@ adapter is locked directly. · 17 unmodified lines
306	326	Two mux-locked sibling muxes
307	327	----------------------------
308	328
309		−This is a good topology.
	329	+This is a good topology::
310	330
311	331	.--------.
312	332	.----------. .--\| dev D1 \|
@@ -330,7 +350,7 @@ accesses to D5 may be interleaved at any time. · 17 unmodified lines
330	350	Two parent-locked sibling muxes
331	351	-------------------------------
332	352
333		−This is a good topology.
	353	+This is a good topology::
334	354
335	355	.--------.
336	356	.----------. .--\| dev D1 \|
@@ -354,7 +374,7 @@ out. · 17 unmodified lines
354	374	Mux-locked and parent-locked sibling muxes
355	375	------------------------------------------
356	376
357		−This is a good topology.
	377	+This is a good topology::
358	378
359	379	.--------.
360	380	.----------. .--\| 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

@@ -1,3 +1,4 @@
	1	+==============================
1	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	18	devices which live on this bus. This is done with an array of struct
18	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	25	I2C_BOARD_INFO("isp1301_omap", 0x2d),
25	26	.irq = OMAP_GPIO_IRQ(125),
@@ -32,15 +33,15 @@ static struct i2c_board_info h4_i2c_board_info[] __initdata = { · 6 unmodified lines
32	33	I2C_BOARD_INFO("24c01", 0x57),
33	34	.platform_data = &m24c01,
34	35	},
35		−};
	36	+ };
36	37
37		−static void __init omap_h4_init(void)
38		−{
	38	+ static void __init omap_h4_init(void)
	39	+ {
39	40	(...)
40	41	i2c_register_board_info(1, h4_i2c_board_info,
41	42	ARRAY_SIZE(h4_i2c_board_info));
42	43	(...)
43		−}
	44	+ }
44	45
45	46	The above code declares 3 devices on I2C bus 1, including their respective
46	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	58	This method has the same implications as method 1a. The declaration of I2C
58	59	devices is here done via devicetree as subnodes of the master controller.
59	60
60		−Example:
	61	+Example::
61	62
62	63	i2c1: i2c@400a0000 {
63	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	100	you can instantiate your I2C devices explicitly. This is done by filling
100	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	106	I2C_BOARD_INFO("max6647", 0x4e),
106		−};
	107	+ };
107	108
108		−int sfe4001_init(struct efx_nic *efx)
109		−{
	109	+ int sfe4001_init(struct efx_nic *efx)
	110	+ {
110	111	(...)
111	112	efx->board_info.hwmon_client =
112	113	i2c_new_device(&efx->i2c_adap, &sfe4001_hwmon_info);
113	114
114	115	(...)
115		−}
	116	+ }
116	117
117	118	The above code instantiates 1 I2C device on the I2C bus which is on the
118	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	125	changing its design without notice). In this case, you can call
125	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		−{
	132	+ static int usb_hcd_nxp_probe(struct platform_device *pdev)
	133	+ {
133	134	(...)
134	135	struct i2c_adapter *i2c_adap;
135	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	143	normal_i2c, NULL);
143	144	i2c_put_adapter(i2c_adap);
144	145	(...)
145		−}
	146	+ }
146	147
147	148	The above code instantiates up to 1 I2C device on the I2C bus which is on
148	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	173	drivers are loaded, and if any is found, an I2C device will be
173	174	instantiated automatically. In order to prevent any misbehavior of this
174	175	mechanism, the following restrictions apply:
	176	+
175	177	* The I2C device driver must implement the detect() method, which
176	178	identifies a supported device by reading from arbitrary registers.
177	179	* Only buses which are likely to have a supported device and agree to be
@@ -189,6 +191,7 @@ first. · 11 unmodified lines
189	191	Those of you familiar with the i2c subsystem of 2.4 kernels and early 2.6
190	192	kernels will find out that this method 3 is essentially similar to what
191	193	was done there. Two significant differences are:
	194	+
192	195	* Probing is only one way to instantiate I2C devices now, while it was the
193	196	only way back then. Where possible, methods 1 and 2 should be preferred.
194	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	227	segment, the address is sufficient to uniquely identify the device to be
225	228	deleted.
226	229
227		−Example:
228		−# echo eeprom 0x50 > /sys/bus/i2c/devices/i2c-3/new_device
	230	+Example::
	231	+
	232	+ # echo eeprom 0x50 > /sys/bus/i2c/devices/i2c-3/new_device
229	233
230	234	While this interface should only be used when in-kernel device declaration
231	235	can't be done, there is a variety of cases where it can be helpful:
	236	+
232	237	* The I2C driver usually detects devices (method 3 above) but the bus
233	238	segment your device lives on doesn't have the proper class bit set and
234	239	thus detection doesn't trigger.

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

@@ -1,4 +1,6 @@
	1	+==========================
1	2	Kernel driver i2c-mux-gpio
	3	+==========================
2	4
3	5	Author: Peter Korsgaard <peter.korsgaard@barco.com>
4	6
@@ -8,7 +10,7 @@ Description · 3 unmodified lines
8	10	i2c-mux-gpio is an i2c mux driver providing access to I2C bus segments
9	11	from a master I2C bus and a hardware MUX controlled through GPIO pins.
10	12
11		−E.G.:
	13	+E.G.::
12	14
13	15	---------- ---------- Bus segment 1 - - - - -
14	16	\| \| SCL/SDA \| \|-------------- \| \|
@@ -33,20 +35,20 @@ bus, the number of bus segments to create and the GPIO pins used · 18 unmodified lines
33	35	to control it. See include/linux/platform_data/i2c-mux-gpio.h for details.
34	36
35	37	E.G. something like this for a MUX providing 4 bus segments
36		−controlled through 3 GPIO pins:
	38	+controlled through 3 GPIO pins::
37	39
38		−#include <linux/platform_data/i2c-mux-gpio.h>
39		−#include <linux/platform_device.h>
	40	+ #include <linux/platform_data/i2c-mux-gpio.h>
	41	+ #include <linux/platform_device.h>
40	42
41		−static const unsigned myboard_gpiomux_gpios[] = {
	43	+ static const unsigned myboard_gpiomux_gpios[] = {
42	44	AT91_PIN_PC26, AT91_PIN_PC25, AT91_PIN_PC24
43		−};
	45	+ };
44	46
45		−static const unsigned myboard_gpiomux_values[] = {
	47	+ static const unsigned myboard_gpiomux_values[] = {
46	48	0, 1, 2, 3
47		−};
	49	+ };
48	50
49		−static struct i2c_mux_gpio_platform_data myboard_i2cmux_data = {
	51	+ static struct i2c_mux_gpio_platform_data myboard_i2cmux_data = {
50	52	.parent = 1,
51	53	.base_nr = 2, /* optional */
52	54	.values = myboard_gpiomux_values,
@@ -54,15 +56,15 @@ static struct i2c_mux_gpio_platform_data myboard_i2cmux_data = { · 1 unmodified line
54	56	.gpios = myboard_gpiomux_gpios,
55	57	.n_gpios = ARRAY_SIZE(myboard_gpiomux_gpios),
56	58	.idle = 4, /* optional */
57		−};
	59	+ };
58	60
59		−static struct platform_device myboard_i2cmux = {
	61	+ static struct platform_device myboard_i2cmux = {
60	62	.name = "i2c-mux-gpio",
61	63	.id = 0,
62	64	.dev = {
63	65	.platform_data = &myboard_i2cmux_data,
64	66	},
65		−};
	67	+ };
66	68
67	69	If you don't know the absolute GPIO pin numbers at registration time,
68	70	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	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	20	Attaching a driver to an I2C device
20	21	-----------------------------------
21	22
22		−Old method (module parameters):
23		−# modprobe <driver> probe=1,0x2d
24		−# modprobe <driver> force=1,0x2d
25		−# modprobe <driver> force_<device>=1,0x2d
	23	+Old method (module parameters)::
	24	+
	25	+ # modprobe <driver> probe=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):
28		−# echo <device> 0x2d > /sys/bus/i2c/devices/i2c-1/new_device
	31	+ # echo <device> 0x2d > /sys/bus/i2c/devices/i2c-1/new_device
29	32
30	33	Preventing a driver from attaching to an I2C device
31	34	---------------------------------------------------
32	35
33		−Old method (module parameters):
34		−# modprobe <driver> ignore=1,0x2f
	36	+Old method (module parameters)::
	37	+
	38	+ # modprobe <driver> ignore=1,0x2f
	39	+
	40	+New method (sysfs interface)::
35	41
36		−New method (sysfs interface):
37		−# echo dummy 0x2f > /sys/bus/i2c/devices/i2c-1/new_device
38		−# modprobe <driver>
	42	+ # echo dummy 0x2f > /sys/bus/i2c/devices/i2c-1/new_device
	43	+ # modprobe <driver>
39	44
40	45	Of course, it is important to instantiate the "dummy" device before loading
41	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	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	7	This is a proof-of-concept backend which acts like an EEPROM on the connected
7	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	11	/sys/bus/i2c/devices/<device-directory>/slave-eeprom
11	12
12	13	As of 2015, Linux doesn't support poll on binary sysfs files, so there is no
13	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	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	13	needed. The backend driver and the I2C bus driver communicate via events. Here
13	14	is a small graph visualizing the data flow and the means by which data is
14	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	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	36	is that i2c slave backends have their own address space. So, you have to add
36	37	0x1000 to the address you would originally request. An example for
37	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	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	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	60	ret = i2c_slave_event(client, event, &val)
60	61
@@ -69,8 +70,9 @@ Event types: · 8 unmodified lines
69	70
70	71	* I2C_SLAVE_WRITE_REQUESTED (mandatory)
71	72
72		−'val': unused
73		−'ret': always 0
	73	+ 'val': unused
	74	+
	75	+ 'ret': always 0
74	76
75	77	Another I2C master wants to write data to us. This event should be sent once
76	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	82	* I2C_SLAVE_READ_REQUESTED (mandatory)
81	83
82		−'val': backend returns first byte to be sent
83		−'ret': always 0
	84	+ 'val': backend returns first byte to be sent
	85	+
	86	+ 'ret': always 0
84	87
85	88	Another I2C master wants to read data from us. This event should be sent once
86	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	92	* I2C_SLAVE_WRITE_RECEIVED (mandatory)
90	93
91		−'val': bus driver delivers received byte
92		−'ret': 0 if the byte should be acked, some errno if the byte should be nacked
	94	+ 'val': bus driver delivers received byte
	95	+
	96	+ 'ret': 0 if the byte should be acked, some errno if the byte should be nacked
93	97
94	98	Another I2C master has sent a byte to us which needs to be set in 'val'. If 'ret'
95	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	102	* I2C_SLAVE_READ_PROCESSED (mandatory)
99	103
100		−'val': backend returns next byte to be sent
101		−'ret': always 0
	104	+ 'val': backend returns next byte to be sent
	105	+
	106	+ 'ret': always 0
102	107
103	108	The bus driver requests the next byte to be sent to another I2C master in
104	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	117	* I2C_SLAVE_STOP (mandatory)
113	118
114		−'val': unused
115		−'ret': always 0
	119	+ 'val': unused
	120	+
	121	+ 'ret': always 0
116	122
117	123	A stop condition was received. This can happen anytime and the backend should
118	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	196	* A master can send STOP at any time. For partially transferred buffers, this
191	197	means additional code to handle this exception. Such code tends to be
192	198	error-prone.
193		−

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

@@ -1,3 +1,4 @@
	1	+======================
1	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	28	transaction function, a device driver should always check (just once) for
28	29	the corresponding functionality flag to ensure that the underlying I2C
29	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	34	Key to symbols
34	35	==============
35	36
	37	+=============== =============================================================
36	38	S (1 bit) : Start bit
37	39	P (1 bit) : Stop bit
38	40	Rd/Wr (1 bit) : Read/Write bit. Rd equals 1, Wr equals 0.
39		−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
	41	+A, NA (1 bit) : Accept and reverse accept bit.
	42	+Addr (7 bits): I2C 7 bit address. Note that this can be expanded as usual to
41	43	get a 10 bit I2C address.
42	44	Comm (8 bits): Command byte, a data byte which often selects a register on
43	45	the device.
@@ -45,15 +47,17 @@ Data (8 bits): A plain data byte. Sometimes, I write DataLow, DataHigh · 1 unmodified line
45	47	for 16 bit data.
46	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	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	62	Functionality flag: I2C_FUNC_SMBUS_QUICK
59	63
@@ -64,9 +68,9 @@ SMBus Receive Byte: i2c_smbus_read_byte() · 4 unmodified lines
64	68	This reads a single byte from a device, without specifying a device
65	69	register. Some devices are so simple that this interface is enough; for
66	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	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	81	This operation is the reverse of Receive Byte: it sends a single byte
78	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	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	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	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	105	This operation is very like Read Byte; again, data is read from a
100	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	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	122	register is specified through the Comm byte. This is the opposite of
117	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	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	135	This is the opposite of the Read Word operation. 16 bits
128	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	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	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]
147		− S Addr Rd [A] [DataLow] A [DataHigh] NA P
	154	+ S Addr Wr [A] Comm [A] DataLow [A] DataHigh [A]
	155	+ S Addr Rd [A] [DataLow] A [DataHigh] NA P
148	156
149	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	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	164	designated register that is specified through the Comm byte. The amount
157	165	of data is specified by the device in the Count byte.
158	166
159		−S Addr Wr [A] Comm [A]
160		− S Addr Rd [A] [Count] A [Data] A [Data] A ... A [Data] NA P
	167	+::
	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	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	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	179	a device, to a designated register that is specified through the
170	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	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	193	Revision 2.0 of the specification.
182	194
183	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] ...
187		− S Addr Rd [A] [Count] A [Data] ... A P
	198	+ S Addr Wr [A] Comm [A] Count [A] Data [A] ...
	199	+ S Addr Rd [A] [Count] A [Data] ... A P
188	200
189	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	209	It is the same form as Write Word, with the command code replaced by the
198	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	216	This is implemented in the following way in the Linux kernel:
	217	+
203	218	* I2C bus drivers which support SMBus Host Notify should report
204	219	I2C_FUNC_SMBUS_HOST_NOTIFY.
205	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	256	to know which slave triggered the interrupt.
242	257
243	258	This is implemented the following way in the Linux kernel:
	259	+
244	260	* I2C bus drivers which support SMBus alert should call
245	261	i2c_setup_smbus_alert() to setup SMBus alert support.
246	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	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
265		−designated register that is specified through the Comm byte.
	280	+This command reads a block of bytes from a device, from a
	281	+designated register that is specified through the Comm byte::
266	282
267		−S Addr Wr [A] Comm [A]
268		− S Addr Rd [A] [Data] A [Data] A ... A [Data] NA P
	283	+ S Addr Wr [A] Comm [A]
	284	+ S Addr Rd [A] [Data] A [Data] A ... A [Data] NA P
269	285
270	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	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	293	a device, to a designated register that is specified through the
278	294	Comm byte. Note that command lengths of 0, 2, or more bytes are
279	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	301	Functionality flag: I2C_FUNC_SMBUS_WRITE_I2C_BLOCK

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

@@ -1,7 +1,8 @@
	1	+=============
1	2	I2C and SMBus
2	3	=============
3	4
4		−I2C (pronounce: I squared C) is a protocol developed by Philips. It is a
	5	+I2C (pronounce: I squared C) is a protocol developed by Philips. It is a
5	6	slow two-wire protocol (variable speed, up to 400 kHz), with a high speed
6	7	extension (3.4 MHz). It provides an inexpensive bus for connecting many
7	8	types of devices with infrequent or low bandwidth communications needs.
@@ -24,7 +25,8 @@ implement all the common SMBus protocol semantics or messages. · 16 unmodified lines
24	25	Terminology
25	26	===========
26	27
27		−When we talk about I2C, we use the following terms:
	28	+When we talk about I2C, we use the following terms::
	29	+
28	30	Bus -> Algorithm
29	31	Adapter
30	32	Device -> Driver

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

@@ -1,3 +1,7 @@
	1	+=====================
	2	+I2C Ten-bit Addresses
	3	+=====================
	4	+
1	5	The I2C protocol knows about two kinds of device addresses: normal 7 bit
2	6	addresses, and an extended set of 10 bit addresses. The sets of addresses
3	7	do not intersect: the 7 bit address 0x10 is not the same as the 10 bit
@@ -12,6 +16,7 @@ See the I2C specification for the details. · 8 unmodified lines
12	16
13	17	The current 10 bit address support is minimal. It should work, however
14	18	you can expect some problems along the way:
	19	+
15	20	* Not all bus drivers support 10-bit addresses. Some don't because the
16	21	hardware doesn't support them (SMBus doesn't require 10-bit address
17	22	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	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	14	Example old-style driver
14	15	------------------------
15	16
	17	+::
16	18
17		−struct example_state {
	19	+ struct example_state {
18	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 };
25		−static unsigned short normal_addr[] = { OUR_ADDR, I2C_CLIENT_END };
	26	+ static unsigned short ignore[] = { 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)
30		−{
	31	+ static int example_attach(struct i2c_adapter *adap, int addr, int kind)
	32	+ {
31	33	struct example_state *state;
32	34	struct device dev = &adap->dev; / to use for dev_ reports */
33	35	int ret;
@@ -59,31 +61,31 @@ static int example_attach(struct i2c_adapter *adap, int addr, int kind) · 25 unmodified lines
59	61	dev_info(dev, "example client created\n");
60	62
61	63	return 0;
62		−}
	64	+ }
63	65
64		−static int example_detach(struct i2c_client *client)
65		−{
	66	+ static int example_detach(struct i2c_client *client)
	67	+ {
66	68	struct example_state *state = i2c_get_clientdata(client);
67	69
68	70	i2c_detach_client(client);
69	71	kfree(state);
70	72	return 0;
71		−}
	73	+ }
72	74
73		−static int example_attach_adapter(struct i2c_adapter *adap)
74		−{
	75	+ static int example_attach_adapter(struct i2c_adapter *adap)
	76	+ {
75	77	return i2c_probe(adap, &addr_data, example_attach);
76		−}
	78	+ }
77	79
78		−static struct i2c_driver example_driver = {
79		− .driver = {
	80	+ static struct i2c_driver example_driver = {
	81	+ .driver = {
80	82	.owner = THIS_MODULE,
81	83	.name = "example",
82	84	.pm = &example_pm_ops,
83	85	},
84	86	.attach_adapter = example_attach_adapter,
85	87	.detach_client = example_detach,
86		−};
	88	+ };
87	89
88	90
89	91	Updating the client
@@ -93,38 +95,38 @@ The new style binding model will check against a list of supported · 3 unmodified lines
93	95	devices and their associated address supplied by the code registering
94	96	the busses. This means that the driver .attach_adapter and
95	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 };
101		−- static unsigned short normal_addr[] = { OUR_ADDR, I2C_CLIENT_END };
	102	+ - static unsigned short ignore[] = { 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)
106		−- {
107		−- return i2c_probe(adap, &addr_data, example_attach);
108		−- }
	107	+ - static int example_attach_adapter(struct i2c_adapter *adap)
	108	+ - {
	109	+ - return i2c_probe(adap, &addr_data, example_attach);
	110	+ - }
109	111
110		− static struct i2c_driver example_driver = {
111		−- .attach_adapter = example_attach_adapter,
112		−- .detach_client = example_detach,
113		− }
	112	+ static struct i2c_driver example_driver = {
	113	+ - .attach_adapter = example_attach_adapter,
	114	+ - .detach_client = example_detach,
	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 = {
118		−+ .probe = example_probe,
119		−+ .remove = example_remove,
120		− }
	119	+ static struct i2c_driver example_driver = {
	120	+ + .probe = example_probe,
	121	+ + .remove = example_remove,
	122	+ }
121	123
122	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)
126		−+ static int example_probe(struct i2c_client *client,
127		−+ const struct i2c_device_id *id)
	127	+ - static int example_attach(struct i2c_adapter *adap, int addr, int kind)
	128	+ + static int example_probe(struct i2c_client *client,
	129	+ + const struct i2c_device_id *id)
128	130
129	131	Change the name of example_attach to example_probe to align it with the
130	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	135	The necessary client fields have already been setup before
134	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;
138		−- example->client.flags = 0;
139		−- example->client.adapter = adap;
140		−-
141		−- strscpy(client->i2c_client.name, "example", sizeof(client->i2c_client.name));
	139	+ - example->client.addr = addr;
	140	+ - example->client.flags = 0;
	141	+ - example->client.adapter = adap;
	142	+ -
	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);
146		−+ i2c_set_clientdata(client, state);
	147	+ - i2c_set_clientdata(&state->client, state);
	148	+ + i2c_set_clientdata(client, state);
147	149
148	150	The call to i2c_attach_client is no longer needed, if the probe
149	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);
153		−- if (ret < 0) {
154		−- dev_err(dev, "failed to attach client\n");
155		−- kfree(state);
156		−- return ret;
157		−- }
	154	+ - ret = i2c_attach_client(&state->i2c_client);
	155	+ - if (ret < 0) {
	156	+ - dev_err(dev, "failed to attach client\n");
	157	+ - kfree(state);
	158	+ - return ret;
	159	+ - }
158	160
159	161
160	162	Remove the storage of 'struct i2c_client' from the 'struct example_state'
161	163	as we are provided with the i2c_client in our example_probe. Instead we
162	164	store a pointer to it for when it is needed.
163	165
164		−struct example_state {
165		−- struct i2c_client client;
166		−+ struct i2c_client *client;
	166	+::
	167	+
	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 */
171		−+ struct device dev = &i2c_client->dev; / to use for dev_ reports */
	174	+ - struct device dev = &adap->dev; / to use for dev_ reports */
	175	+ + struct device dev = &i2c_client->dev; / to use for dev_ reports */
172	176
173	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	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	186	const struct i2c_device_id *id)
183		−{
	187	+ {
184	188	struct example_state *state;
185		− struct device *dev = &i2c_client->dev;
	189	+ struct device *dev = &i2c_client->dev;
186	190	int ret;
187	191
188	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	195	return -ENOMEM;
192	196	}
193	197
194		−+ state->client = i2c_client;
	198	+ + state->client = i2c_client;
195	199
196	200	Update the detach method, by changing the name to _remove and
197	201	to delete the i2c_detach_client call. It is possible that you
198	202	can also remove the ret variable as it is not needed for any
199	203	of the core functions.
200	204
201		−- static int example_detach(struct i2c_client *client)
202		−+ static int example_remove(struct i2c_client *client)
203		−{
	205	+::
	206	+
	207	+ - static int example_detach(struct i2c_client *client)
	208	+ + static int example_remove(struct i2c_client *client)
	209	+ {
204	210	struct example_state *state = i2c_get_clientdata(client);
205	211
206		−- i2c_detach_client(client);
	212	+ - i2c_detach_client(client);
207	213
208	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[] = {
212		−+ { "example", 0 },
213		−+ { }
214		−+};
215		−+
216		−+MODULE_DEVICE_TABLE(i2c, example_idtable);
	217	+ + struct i2c_device_id example_idtable[] = {
	218	+ + { "example", 0 },
	219	+ + { }
	220	+ +};
	221	+ +
	222	+ +MODULE_DEVICE_TABLE(i2c, example_idtable);
217	223
218		−static struct i2c_driver example_driver = {
219		− .driver = {
	224	+ static struct i2c_driver example_driver = {
	225	+ .driver = {
220	226	.owner = THIS_MODULE,
221	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	235	struct i2c_client *client;
230	236	....
231		−};
	237	+ };
232	238
233		−static int example_probe(struct i2c_client *client,
234		− const struct i2c_device_id *id)
235		−{
	239	+ static int example_probe(struct i2c_client *client,
	240	+ const struct i2c_device_id *id)
	241	+ {
236	242	struct example_state *state;
237	243	struct device *dev = &client->dev;
238	244
@@ -250,25 +256,25 @@ static int example_probe(struct i2c_client *client, · 11 unmodified lines
250	256	dev_info(dev, "example client created\n");
251	257
252	258	return 0;
253		−}
	259	+ }
254	260
255		−static int example_remove(struct i2c_client *client)
256		−{
	261	+ static int example_remove(struct i2c_client *client)
	262	+ {
257	263	struct example_state *state = i2c_get_clientdata(client);
258	264
259	265	kfree(state);
260	266	return 0;
261		−}
	267	+ }
262	268
263		−static struct i2c_device_id example_idtable[] = {
	269	+ static struct i2c_device_id example_idtable[] = {
264	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 = {
271		− .driver = {
	276	+ static struct i2c_driver example_driver = {
	277	+ .driver = {
272	278	.owner = THIS_MODULE,
273	279	.name = "example",
274	280	.pm = &example_pm_ops,
@@ -276,4 +282,4 @@ static struct i2c_driver example_driver = { · 1 unmodified line
276	282	.id_table = example_idtable,
277	283	.probe = example_probe,
278	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	5	This is a small guide for those who want to write kernel drivers for I2C
2	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	16	Try to keep the kernel namespace as clean as possible. The best way to
13	17	do this is to use a unique prefix for all global symbols. This is
14	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	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	29	provide. A client structure holds device-specific information like the
26	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	35	{ "foo", my_id_for_foo },
30	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	43	.driver = {
38	44	.name = "foo",
39	45	.pm = &foo_pm_ops, /* optional */
@@ -49,7 +55,7 @@ static struct i2c_driver foo_driver = { · 9 unmodified lines
49	55
50	56	.shutdown = foo_shutdown, /* optional */
51	57	.command = foo_command, /* optional, deprecated */
52		−}
	58	+ }
53	59
54	60	The name field is the driver name, and must not contain spaces. It
55	61	should match the module name (if the driver can be compiled as a module),
@@ -64,16 +70,18 @@ below. · 8 unmodified lines
64	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	74	structure at all. You should use this to keep device-specific data.
69	75
	76	+::
	77	+
70	78	/* store the value */
71	79	void i2c_set_clientdata(struct i2c_client client, void data);
72	80
73	81	/* retrieve the value */
74	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	85	to NULL in remove() or if probe() failed anymore. The i2c-core does this
78	86	automatically on these occasions. Those are also the only times the core will
79	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	100	be encapsulated.
93	101
94	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)
98		−{
	105	+ int foo_read_value(struct i2c_client *client, u8 reg)
	106	+ {
99	107	if (reg < 0x10) /* byte-sized register */
100	108	return i2c_smbus_read_byte_data(client, reg);
101	109	else /* word-sized register */
102	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)
106		−{
	113	+ int foo_write_value(struct i2c_client *client, u8 reg, u16 value)
	114	+ {
107	115	if (reg == 0x10) /* Impossible to write - driver error! */
108	116	return -EINVAL;
109	117	else if (reg < 0x10) /* byte-sized register */
110	118	return i2c_smbus_write_byte_data(client, reg, value);
111	119	else /* word-sized register */
112	120	return i2c_smbus_write_word_data(client, reg, value);
113		−}
	121	+ }
114	122
115	123
116	124	Probing and attaching
@@ -145,6 +153,8 @@ I2C device drivers using this binding model work just like any other · 28 unmodified lines
145	153	kind of driver in Linux: they provide a probe() method to bind to
146	154	those devices, and a remove() method to unbind.
147	155
	156	+::
	157	+
148	158	static int foo_probe(struct i2c_client *client,
149	159	const struct i2c_device_id *id);
150	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	250	you have to do some initializing. Fortunately, just registering the
241	251	driver module is usually enough.
242	252
243		−static int __init foo_init(void)
244		−{
	253	+::
	254	+
	255	+ static int __init foo_init(void)
	256	+ {
245	257	return i2c_add_driver(&foo_driver);
246		−}
247		−module_init(foo_init);
	258	+ }
	259	+ module_init(foo_init);
248	260
249		−static void __exit foo_cleanup(void)
250		−{
	261	+ static void __exit foo_cleanup(void)
	262	+ {
251	263	i2c_del_driver(&foo_driver);
252		−}
253		−module_exit(foo_cleanup);
	264	+ }
	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	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	274	the code is built into the kernel, as they would never be called.
263	275
264	276
265	277	Driver Information
266	278	==================
267	279
268		−/* Substitute your own name and email address */
269		−MODULE_AUTHOR("Frodo Looijaard <frodol@dds.nl>"
270		−MODULE_DESCRIPTION("Driver for Barf Inc. Foo I2C devices");
	280	+::
271	281
272		−/* a few non-GPL license types are also allowed */
273		−MODULE_LICENSE("GPL");
	282	+ /* Substitute your own name and email address */
	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	290	Power Management
@@ -323,6 +337,8 @@ commands, but only some of them understand plain I2C! · 46 unmodified lines
323	337	Plain I2C communication
324	338	-----------------------
325	339
	340	+::
	341	+
326	342	int i2c_master_send(struct i2c_client client, const char buf,
327	343	int count);
328	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	350	less than 64k since msg.len is u16.) Returned is the actual number of bytes
335	351	read/written.
336	352
	353	+::
	354	+
337	355	int i2c_transfer(struct i2c_adapter adap, struct i2c_msg msg,
338	356	int num);
339	357
@@ -343,13 +361,15 @@ stop bit is sent between transaction. The i2c_msg structure contains · 3 unmodified lines
343	361	for each message the client address, the number of bytes of the message
344	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	365	actual I2C protocol.
348	366
349	367
350	368	SMBus communication
351	369	-------------------
352	370
	371	+::
	372	+
353	373	s32 i2c_smbus_xfer(struct i2c_adapter *adapter, u16 addr,
354	374	unsigned short flags, char read_write, u8 command,
355	375	int size, union i2c_smbus_data *data);
@@ -357,6 +377,8 @@ SMBus communication · 1 unmodified line
357	377	This is the generic SMBus function. All functions below are implemented
358	378	in terms of it. Never use this function directly!
359	379
	380	+::
	381	+
360	382	s32 i2c_smbus_read_byte(struct i2c_client *client);
361	383	s32 i2c_smbus_write_byte(struct i2c_client *client, u8 value);
362	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	398	const u8 *values);
377	399
378	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	403	s32 i2c_smbus_write_quick(struct i2c_client *client, u8 value);
382	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	411	value, except for block transactions, which return the number of values
390	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	415	actual SMBus protocol.
394	416
395	417
@@ -397,7 +419,7 @@ General purpose routines · 1 unmodified line
397	419	========================
398	420
399	421	Below all general purpose routines are listed, that were not mentioned
400		−before.
	422	+before::
401	423
402	424	/* Return the adapter number for a specific adapter */
403	425	int i2c_adapter_id(struct i2c_adapter *adap);

Documentation/index.rst+1−0

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

Documentation/spi/spi-sc18is602+1−1

@@ -17,7 +17,7 @@ kernel's SPI core subsystem. · 16 unmodified lines
17	17
18	18	The driver does not probe for supported chips, since the SI18IS602/603 does not
19	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	23	Usage Notes

MAINTAINERS+24−24

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

drivers/hwmon/atxp1.c+1−1

@@ -5,7 +5,7 @@ · 4 unmodified lines
5	5	*
6	6	* The ATXP1 can reside on I2C addresses 0x37 or 0x4e. The chip is
7	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	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	197	if (rv != -ENXIO) {
198	198	/*
199	199	* We expect ENXIO to reflect NACK
200		− * (per Documentation/i2c/fault-codes).
	200	+ * (per Documentation/i2c/fault-codes.rst).
201	201	* Everything else is an error.
202	202	*/
203	203	dev_dbg(&client->dev,

drivers/i2c/Kconfig+2−2

@@ -54,7 +54,7 @@ config I2C_CHARDEV · 53 unmodified lines
54	54	Say Y here to use i2c-* device files, usually found in the /dev
55	55	directory on your system. They make it possible to have user-space
56	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	59	This support is also available as a module. If so, the module
60	60	will be called i2c-dev.
@@ -107,7 +107,7 @@ config I2C_STUB · 46 unmodified lines
107	107	especially for certain kinds of sensor chips.
108	108
109	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	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	1206	and makes it easier to add support for new devices.
1207	1207
1208	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	1211	Another driver exists, named i2c-parport-light, which doesn't depend
1212	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	77	* SMBus Host Notify yes
78	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	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	126	* Voluntarily dropping error code of kstrtou8 since all
127	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	130	if (kstrtou8(p + 1, 16, &data->byte))
131	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	2206	dev_warn(&adapter->dev,
2207	2207	"This adapter will soon drop class based instantiation of devices. "
2208	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	2210	info.addr);
2211	2211
2212	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	2236	if (adapter->class == I2C_CLASS_DEPRECATED) {
2237	2237	dev_dbg(&adapter->dev,
2238	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	2240	driver->driver.name);
2241	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	693	* Varies depending on bus type of the device. As there is no device
694	694	* here, call probe directly. For information on device registration
695	695	* i2c:
696		− * Documentation/i2c/writing-clients
	696	+ * Documentation/i2c/writing-clients.rst
697	697	* spi:
698	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	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	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	522	* The return codes from the @master_xfer{_atomic} fields should indicate the
523	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	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