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

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