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
21Documentation/i2c/instantiating-devices.rst, section
22"Method 4: Instantiate from user-space".
23
24Below is a mapping from the old module parameters to the new interface.
25
26Attaching a driver to an I2C device
27-----------------------------------
28
29Old method (module parameters)::
30
31  # modprobe <driver> probe=1,0x2d
32  # modprobe <driver> force=1,0x2d
33  # modprobe <driver> force_<device>=1,0x2d
34
35New method (sysfs interface)::
36
37  # echo <device> 0x2d > /sys/bus/i2c/devices/i2c-1/new_device
38
39Preventing a driver from attaching to an I2C device
40---------------------------------------------------
41
42Old method (module parameters)::
43
44  # modprobe <driver> ignore=1,0x2f
45
46New method (sysfs interface)::
47
48  # echo dummy 0x2f > /sys/bus/i2c/devices/i2c-1/new_device
49  # modprobe <driver>
50
51Of course, it is important to instantiate the ``dummy`` device before loading
52the driver. The dummy device will be handled by i2c-core itself, preventing
53other drivers from binding to it later on. If there is a real device at the
54problematic address, and you want another driver to bind to it, then simply
55pass the name of the device in question instead of ``dummy``.