Documentation/i2c/instantiating-devices.rst

6 level. Instead, the software must know which devices are connected on each
9 several ways to achieve this, depending on the context and requirements.
13 --------------------------------------------
16 for many embedded systems. On such systems, each I2C bus has a number which
17 is known in advance. It is thus possible to pre-declare the I2C devices
18 which live on this bus.
20 This information is provided to the kernel in a different way on different
21 architectures: device tree, ACPI or board files.
24 instantiated automatically by i2c-core. The devices will be automatically
25 unbound and destroyed when the I2C bus they sit on goes away (if ever).
31 On platforms using devicetree, the declaration of I2C devices is done in
38 		clock-frequency = <100000>;
47 			gpio-controller;
48 			#gpio-cells = <2>;
54 additional properties which might be needed to set up the device, please refer
62 which is currently located at :doc:`../firmware-guide/acpi/enumeration`.
69 description based on board files, but the latter are still used in old
81 	{	/* EEPROM on mainboard */
85 	{	/* EEPROM on cpu card */
99 The above code declares 3 devices on I2C bus 1, including their respective
104 --------------------------------------------
106 This method is appropriate when a larger device uses an I2C bus for
123 	efx->board_info.hwmon_client =
124 		i2c_new_client_device(&efx->i2c_adap, &sfe4001_hwmon_info);
129 The above code instantiates 1 I2C device on the I2C bus which is on the
132 A variant of this is when you don't know for sure if an I2C device is
134 on cheap variants of a board but you have no way to tell them apart), or
159 The above code instantiates up to 1 I2C device on the I2C bus which is on
164 The driver which instantiated the I2C device is responsible for destroying
165 it on cleanup. This is done by calling i2c_unregister_device() on the
171 ----------------------------------------------
173 Sometimes you do not have enough information about an I2C device, not even
175 chips on PC mainboards. There are several dozen models, which can live
179 manufacturer and device ID registers, so they can be identified by
183 explicitly. Instead, i2c-core will probe for such devices as soon as their
184 drivers are loaded, and if any is found, an I2C device will be
188 * The I2C device driver must implement the detect() method, which
189   identifies a supported device by reading from arbitrary registers.
190 * Only buses which are likely to have a supported device and agree to be
192   monitoring chips on a TV adapter.
216 Once again, method 3 should be avoided wherever possible. Explicit device
221 Method 4: Instantiate from user-space
222 -------------------------------------
230 instantiate, respectively delete, an I2C device.
232 File ``new_device`` takes 2 parameters: the name of the I2C device (a
233 string) and the address of the I2C device (a number, typically expressed
237 device. As no two devices can live at the same address on a given I2C
238 segment, the address is sufficient to uniquely identify the device to be
243   # echo eeprom 0x50 > /sys/bus/i2c/devices/i2c-3/new_device
245 While this interface should only be used when in-kernel device declaration
249   segment your device lives on doesn't have the proper class bit set and
251 * The I2C driver usually detects devices, but your device lives at an
253 * The I2C driver usually detects devices, but your device is not detected,
255   device is not officially supported yet but you know it is compatible.
256 * You are developing a driver on a test board, where you soldered the I2C
257   device yourself.
260 drivers implement. Being implemented in i2c-core rather than in each
261 device driver individually, it is much more efficient, and also has the
263 You can also instantiate the device before the driver is loaded or even
264 available, and you don't need to know what driver the device needs.