Skip to content

Commit 68a04ae

Browse files
hkallweitWolfram Sang
authored andcommitted
Documentation: i2c: Document that client auto-detection is a legacy mechanism
Class-based client auto-detection has been considered a legacy mechanism for 10 yrs now. See commit 0c17617 ("i2c: add deprecation warning for class based instantiation"). Change the documentation of how to write an i2c client accordingly. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
1 parent f311507 commit 68a04ae

File tree

1 file changed

+4
-28
lines changed

1 file changed

+4
-28
lines changed

Documentation/i2c/writing-clients.rst

Lines changed: 4 additions & 28 deletions
Original file line numberDiff line numberDiff line change
@@ -48,10 +48,6 @@ driver model device node, and its I2C address.
4848
.id_table = foo_idtable,
4949
.probe = foo_probe,
5050
.remove = foo_remove,
51-
/* if device autodetection is needed: */
52-
.class = I2C_CLASS_SOMETHING,
53-
.detect = foo_detect,
54-
.address_list = normal_i2c,
5551

5652
.shutdown = foo_shutdown, /* optional */
5753
.command = foo_command, /* optional, deprecated */
@@ -203,37 +199,17 @@ reference for later use.
203199
Device Detection
204200
----------------
205201

206-
Sometimes you do not know in advance which I2C devices are connected to
207-
a given I2C bus. This is for example the case of hardware monitoring
208-
devices on a PC's SMBus. In that case, you may want to let your driver
209-
detect supported devices automatically. This is how the legacy model
210-
was working, and is now available as an extension to the standard
211-
driver model.
212-
213-
You simply have to define a detect callback which will attempt to
214-
identify supported devices (returning 0 for supported ones and -ENODEV
215-
for unsupported ones), a list of addresses to probe, and a device type
216-
(or class) so that only I2C buses which may have that type of device
217-
connected (and not otherwise enumerated) will be probed. For example,
218-
a driver for a hardware monitoring chip for which auto-detection is
219-
needed would set its class to I2C_CLASS_HWMON, and only I2C adapters
220-
with a class including I2C_CLASS_HWMON would be probed by this driver.
221-
Note that the absence of matching classes does not prevent the use of
222-
a device of that type on the given I2C adapter. All it prevents is
223-
auto-detection; explicit instantiation of devices is still possible.
224-
225-
Note that this mechanism is purely optional and not suitable for all
226-
devices. You need some reliable way to identify the supported devices
202+
The device detection mechanism comes with a number of disadvantages.
203+
You need some reliable way to identify the supported devices
227204
(typically using device-specific, dedicated identification registers),
228205
otherwise misdetections are likely to occur and things can get wrong
229206
quickly. Keep in mind that the I2C protocol doesn't include any
230207
standard way to detect the presence of a chip at a given address, let
231208
alone a standard way to identify devices. Even worse is the lack of
232209
semantics associated to bus transfers, which means that the same
233210
transfer can be seen as a read operation by a chip and as a write
234-
operation by another chip. For these reasons, explicit device
235-
instantiation should always be preferred to auto-detection where
236-
possible.
211+
operation by another chip. For these reasons, device detection is
212+
considered a legacy mechanism and shouldn't be used in new code.
237213

238214

239215
Device Deletion

0 commit comments

Comments
 (0)