Commit | Line | Data |
---|---|---|
c7b25a9e JD |
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". |