Jean Delvare | c7b25a9 | 2009-12-06 17:06:24 +0100 | [diff] [blame] | 1 | I2C device driver binding control from user-space |
| 2 | ================================================= |
| 3 | |
| 4 | Up to kernel 2.6.32, many i2c drivers used helper macros provided by |
| 5 | <linux/i2c.h> which created standard module parameters to let the user |
| 6 | control how the driver would probe i2c buses and attach to devices. These |
| 7 | parameters were known as "probe" (to let the driver probe for an extra |
| 8 | address), "force" (to forcibly attach the driver to a given device) and |
| 9 | "ignore" (to prevent a driver from probing a given address). |
| 10 | |
| 11 | With the conversion of the i2c subsystem to the standard device driver |
| 12 | binding model, it became clear that these per-module parameters were no |
| 13 | longer needed, and that a centralized implementation was possible. The new, |
| 14 | sysfs-based interface is described in the documentation file |
| 15 | "instantiating-devices", section "Method 4: Instantiate from user-space". |
| 16 | |
| 17 | Below is a mapping from the old module parameters to the new interface. |
| 18 | |
| 19 | Attaching a driver to an I2C device |
| 20 | ----------------------------------- |
| 21 | |
| 22 | Old method (module parameters): |
| 23 | # modprobe <driver> probe=1,0x2d |
| 24 | # modprobe <driver> force=1,0x2d |
| 25 | # modprobe <driver> force_<device>=1,0x2d |
| 26 | |
| 27 | New method (sysfs interface): |
| 28 | # echo <device> 0x2d > /sys/bus/i2c/devices/i2c-1/new_device |
| 29 | |
| 30 | Preventing a driver from attaching to an I2C device |
| 31 | --------------------------------------------------- |
| 32 | |
| 33 | Old method (module parameters): |
| 34 | # modprobe <driver> ignore=1,0x2f |
| 35 | |
| 36 | New method (sysfs interface): |
| 37 | # echo dummy 0x2f > /sys/bus/i2c/devices/i2c-1/new_device |
| 38 | # modprobe <driver> |
| 39 | |
| 40 | Of course, it is important to instantiate the "dummy" device before loading |
| 41 | the driver. The dummy device will be handled by i2c-core itself, preventing |
| 42 | other drivers from binding to it later on. If there is a real device at the |
| 43 | problematic address, and you want another driver to bind to it, then simply |
| 44 | pass the name of the device in question instead of "dummy". |