^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1) ==============================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 2) How to instantiate I2C devices
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 3) ==============================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 4)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 5) Unlike PCI or USB devices, I2C devices are not enumerated at the hardware
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 6) level. Instead, the software must know which devices are connected on each
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 7) I2C bus segment, and what address these devices are using. For this
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 8) reason, the kernel code must instantiate I2C devices explicitly. There are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 9) several ways to achieve this, depending on the context and requirements.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12) Method 1: Declare the I2C devices statically
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13) --------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15) This method is appropriate when the I2C bus is a system bus as is the case
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16) for many embedded systems. On such systems, each I2C bus has a number which
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17) is known in advance. It is thus possible to pre-declare the I2C devices
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18) which live on this bus.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20) This information is provided to the kernel in a different way on different
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21) architectures: device tree, ACPI or board files.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23) When the I2C bus in question is registered, the I2C devices will be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24) instantiated automatically by i2c-core. The devices will be automatically
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25) unbound and destroyed when the I2C bus they sit on goes away (if ever).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28) Declare the I2C devices via devicetree
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31) On platforms using devicetree, the declaration of I2C devices is done in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32) subnodes of the master controller.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34) Example::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36) i2c1: i2c@400a0000 {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37) /* ... master properties skipped ... */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38) clock-frequency = <100000>;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40) flash@50 {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41) compatible = "atmel,24c256";
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42) reg = <0x50>;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45) pca9532: gpio@60 {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46) compatible = "nxp,pca9532";
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47) gpio-controller;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48) #gpio-cells = <2>;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49) reg = <0x60>;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53) Here, two devices are attached to the bus using a speed of 100kHz. For
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54) additional properties which might be needed to set up the device, please refer
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55) to its devicetree documentation in Documentation/devicetree/bindings/.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58) Declare the I2C devices via ACPI
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61) ACPI can also describe I2C devices. There is special documentation for this
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62) which is currently located at :doc:`../firmware-guide/acpi/enumeration`.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 64)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 65) Declare the I2C devices in board files
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 66) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 67)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 68) In many embedded architectures, devicetree has replaced the old hardware
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 69) description based on board files, but the latter are still used in old
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 70) code. Instantiating I2C devices via board files is done with an array of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 71) struct i2c_board_info which is registered by calling
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 72) i2c_register_board_info().
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 73)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 74) Example (from omap2 h4)::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 75)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 76) static struct i2c_board_info h4_i2c_board_info[] __initdata = {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 77) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 78) I2C_BOARD_INFO("isp1301_omap", 0x2d),
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 79) .irq = OMAP_GPIO_IRQ(125),
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 80) },
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 81) { /* EEPROM on mainboard */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 82) I2C_BOARD_INFO("24c01", 0x52),
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 83) .platform_data = &m24c01,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 84) },
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 85) { /* EEPROM on cpu card */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 86) I2C_BOARD_INFO("24c01", 0x57),
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 87) .platform_data = &m24c01,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 88) },
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 89) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 90)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 91) static void __init omap_h4_init(void)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 92) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 93) (...)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 94) i2c_register_board_info(1, h4_i2c_board_info,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 95) ARRAY_SIZE(h4_i2c_board_info));
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 96) (...)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 97) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 98)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 99) The above code declares 3 devices on I2C bus 1, including their respective
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100) addresses and custom data needed by their drivers.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103) Method 2: Instantiate the devices explicitly
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104) --------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 105)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 106) This method is appropriate when a larger device uses an I2C bus for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 107) internal communication. A typical case is TV adapters. These can have a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 108) tuner, a video decoder, an audio decoder, etc. usually connected to the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 109) main chip by the means of an I2C bus. You won't know the number of the I2C
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 110) bus in advance, so the method 1 described above can't be used. Instead,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 111) you can instantiate your I2C devices explicitly. This is done by filling
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 112) a struct i2c_board_info and calling i2c_new_client_device().
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 113)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 114) Example (from the sfe4001 network driver)::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 115)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 116) static struct i2c_board_info sfe4001_hwmon_info = {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 117) I2C_BOARD_INFO("max6647", 0x4e),
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 118) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 119)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 120) int sfe4001_init(struct efx_nic *efx)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 121) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 122) (...)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 123) efx->board_info.hwmon_client =
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 124) i2c_new_client_device(&efx->i2c_adap, &sfe4001_hwmon_info);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 125)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 126) (...)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 127) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 128)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 129) The above code instantiates 1 I2C device on the I2C bus which is on the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 130) network adapter in question.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 131)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 132) A variant of this is when you don't know for sure if an I2C device is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 133) present or not (for example for an optional feature which is not present
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 134) on cheap variants of a board but you have no way to tell them apart), or
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 135) it may have different addresses from one board to the next (manufacturer
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 136) changing its design without notice). In this case, you can call
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 137) i2c_new_scanned_device() instead of i2c_new_client_device().
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 138)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 139) Example (from the nxp OHCI driver)::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 140)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 141) static const unsigned short normal_i2c[] = { 0x2c, 0x2d, I2C_CLIENT_END };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 142)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 143) static int usb_hcd_nxp_probe(struct platform_device *pdev)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 144) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 145) (...)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 146) struct i2c_adapter *i2c_adap;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 147) struct i2c_board_info i2c_info;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 148)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 149) (...)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 150) i2c_adap = i2c_get_adapter(2);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 151) memset(&i2c_info, 0, sizeof(struct i2c_board_info));
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 152) strscpy(i2c_info.type, "isp1301_nxp", sizeof(i2c_info.type));
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 153) isp1301_i2c_client = i2c_new_scanned_device(i2c_adap, &i2c_info,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 154) normal_i2c, NULL);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 155) i2c_put_adapter(i2c_adap);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 156) (...)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 157) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 158)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 159) The above code instantiates up to 1 I2C device on the I2C bus which is on
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 160) the OHCI adapter in question. It first tries at address 0x2c, if nothing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 161) is found there it tries address 0x2d, and if still nothing is found, it
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 162) simply gives up.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 163)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 164) The driver which instantiated the I2C device is responsible for destroying
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 165) it on cleanup. This is done by calling i2c_unregister_device() on the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 166) pointer that was earlier returned by i2c_new_client_device() or
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 167) i2c_new_scanned_device().
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 168)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 169)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 170) Method 3: Probe an I2C bus for certain devices
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 171) ----------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 172)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 173) Sometimes you do not have enough information about an I2C device, not even
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 174) to call i2c_new_scanned_device(). The typical case is hardware monitoring
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 175) chips on PC mainboards. There are several dozen models, which can live
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 176) at 25 different addresses. Given the huge number of mainboards out there,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 177) it is next to impossible to build an exhaustive list of the hardware
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 178) monitoring chips being used. Fortunately, most of these chips have
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 179) manufacturer and device ID registers, so they can be identified by
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 180) probing.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 181)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 182) In that case, I2C devices are neither declared nor instantiated
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 183) explicitly. Instead, i2c-core will probe for such devices as soon as their
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 184) drivers are loaded, and if any is found, an I2C device will be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 185) instantiated automatically. In order to prevent any misbehavior of this
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 186) mechanism, the following restrictions apply:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 187)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 188) * The I2C device driver must implement the detect() method, which
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 189) identifies a supported device by reading from arbitrary registers.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 190) * Only buses which are likely to have a supported device and agree to be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 191) probed, will be probed. For example this avoids probing for hardware
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 192) monitoring chips on a TV adapter.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 193)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 194) Example:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 195) See lm90_driver and lm90_detect() in drivers/hwmon/lm90.c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 196)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 197) I2C devices instantiated as a result of such a successful probe will be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 198) destroyed automatically when the driver which detected them is removed,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 199) or when the underlying I2C bus is itself destroyed, whichever happens
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 200) first.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 201)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 202) Those of you familiar with the I2C subsystem of 2.4 kernels and early 2.6
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 203) kernels will find out that this method 3 is essentially similar to what
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 204) was done there. Two significant differences are:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 205)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 206) * Probing is only one way to instantiate I2C devices now, while it was the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 207) only way back then. Where possible, methods 1 and 2 should be preferred.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 208) Method 3 should only be used when there is no other way, as it can have
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 209) undesirable side effects.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 210) * I2C buses must now explicitly say which I2C driver classes can probe
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 211) them (by the means of the class bitfield), while all I2C buses were
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 212) probed by default back then. The default is an empty class which means
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 213) that no probing happens. The purpose of the class bitfield is to limit
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 214) the aforementioned undesirable side effects.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 215)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 216) Once again, method 3 should be avoided wherever possible. Explicit device
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 217) instantiation (methods 1 and 2) is much preferred for it is safer and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 218) faster.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 219)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 220)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 221) Method 4: Instantiate from user-space
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 222) -------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 223)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 224) In general, the kernel should know which I2C devices are connected and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 225) what addresses they live at. However, in certain cases, it does not, so a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 226) sysfs interface was added to let the user provide the information. This
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 227) interface is made of 2 attribute files which are created in every I2C bus
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 228) directory: ``new_device`` and ``delete_device``. Both files are write
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 229) only and you must write the right parameters to them in order to properly
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 230) instantiate, respectively delete, an I2C device.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 231)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 232) File ``new_device`` takes 2 parameters: the name of the I2C device (a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 233) string) and the address of the I2C device (a number, typically expressed
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 234) in hexadecimal starting with 0x, but can also be expressed in decimal.)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 235)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 236) File ``delete_device`` takes a single parameter: the address of the I2C
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 237) device. As no two devices can live at the same address on a given I2C
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 238) segment, the address is sufficient to uniquely identify the device to be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 239) deleted.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 240)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 241) Example::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 242)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 243) # echo eeprom 0x50 > /sys/bus/i2c/devices/i2c-3/new_device
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 244)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 245) While this interface should only be used when in-kernel device declaration
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 246) can't be done, there is a variety of cases where it can be helpful:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 247)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 248) * The I2C driver usually detects devices (method 3 above) but the bus
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 249) segment your device lives on doesn't have the proper class bit set and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 250) thus detection doesn't trigger.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 251) * The I2C driver usually detects devices, but your device lives at an
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 252) unexpected address.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 253) * The I2C driver usually detects devices, but your device is not detected,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 254) either because the detection routine is too strict, or because your
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 255) device is not officially supported yet but you know it is compatible.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 256) * You are developing a driver on a test board, where you soldered the I2C
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 257) device yourself.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 258)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 259) This interface is a replacement for the force_* module parameters some I2C
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 260) drivers implement. Being implemented in i2c-core rather than in each
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 261) device driver individually, it is much more efficient, and also has the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 262) advantage that you do not have to reload the driver to change a setting.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 263) You can also instantiate the device before the driver is loaded or even
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 264) available, and you don't need to know what driver the device needs.
Orange Pi5 kernel
Deprecated Linux kernel 5.10.110 for OrangePi 5/5B/5+ boards
3 Commits
0 Branches
0 Tags