projects / linux-block.git / blame
| Commit | Line | Data |
|---|---|---|
| f6fcefa1 LC |
1 | ================================================================ |
| 2 | I2C device driver binding control from user-space in old kernels | |
| 3 | ================================================================ | |
| c7b25a9e | 4 | |
| dfea2b16 LC |
5 | .. NOTE:: |
| 6 | Note: this section is only relevant if you are handling some old code | |
| 7 | found in kernel 2.6. If you work with more recent kernels, you can | |
| 8 | safely skip this section. | |
| 9 | ||
| 2f07c05f | 10 | Up to kernel 2.6.32, many I2C drivers used helper macros provided by |
| c7b25a9e | 11 | <linux/i2c.h> which created standard module parameters to let the user |
| 2f07c05f | 12 | control how the driver would probe I2C buses and attach to devices. These |
| 1ef05722 LC |
13 | parameters were known as ``probe`` (to let the driver probe for an extra |
| 14 | address), ``force`` (to forcibly attach the driver to a given device) and | |
| 15 | ``ignore`` (to prevent a driver from probing a given address). | |
| c7b25a9e | 16 | |
| 2f07c05f | 17 | With the conversion of the I2C subsystem to the standard device driver |
| c7b25a9e JD |
18 | binding model, it became clear that these per-module parameters were no |
| 19 | longer needed, and that a centralized implementation was possible. The new, | |
| 25edd3a1 MCC |
20 | sysfs-based interface is described in |
| 21 | Documentation/i2c/instantiating-devices.rst, section | |
| 899b56b3 | 22 | "Method 4: Instantiate from user-space". |
| c7b25a9e JD |
23 | |
| 24 | Below is a mapping from the old module parameters to the new interface. | |
| 25 | ||
| 26 | Attaching a driver to an I2C device | |
| 27 | ----------------------------------- | |
| 28 | ||
| ccf988b6 MCC |
29 | Old method (module parameters):: |
| 30 | ||
| 31 | # modprobe <driver> probe=1,0x2d | |
| 32 | # modprobe <driver> force=1,0x2d | |
| 33 | # modprobe <driver> force_<device>=1,0x2d | |
| 34 | ||
| 35 | New method (sysfs interface):: | |
| c7b25a9e | 36 | |
| ccf988b6 | 37 | # echo <device> 0x2d > /sys/bus/i2c/devices/i2c-1/new_device |
| c7b25a9e JD |
38 | |
| 39 | Preventing a driver from attaching to an I2C device | |
| 40 | --------------------------------------------------- | |
| 41 | ||
| ccf988b6 MCC |
42 | Old method (module parameters):: |
| 43 | ||
| 44 | # modprobe <driver> ignore=1,0x2f | |
| 45 | ||
| 46 | New method (sysfs interface):: | |
| c7b25a9e | 47 | |
| ccf988b6 MCC |
48 | # echo dummy 0x2f > /sys/bus/i2c/devices/i2c-1/new_device |
| 49 | # modprobe <driver> | |
| c7b25a9e | 50 | |
| 1ef05722 | 51 | Of course, it is important to instantiate the ``dummy`` device before loading |
| c7b25a9e JD |
52 | the driver. The dummy device will be handled by i2c-core itself, preventing |
| 53 | other drivers from binding to it later on. If there is a real device at the | |
| 54 | problematic address, and you want another driver to bind to it, then simply | |
| 1ef05722 | 55 | pass the name of the device in question instead of ``dummy``. |