blob: 38e55829dee8247ffce4d2b64c74a6416202fe1b [file] [log] [blame]
Luca Ceresolif6fcefa2020-01-29 16:19:51 +01001================================================================
2I2C device driver binding control from user-space in old kernels
3================================================================
Jean Delvarec7b25a92009-12-06 17:06:24 +01004
Luca Ceresolidfea2b12020-01-29 16:19:49 +01005.. 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
Luca Ceresoli2f07c052020-01-29 16:19:29 +010010Up to kernel 2.6.32, many I2C drivers used helper macros provided by
Jean Delvarec7b25a92009-12-06 17:06:24 +010011<linux/i2c.h> which created standard module parameters to let the user
Luca Ceresoli2f07c052020-01-29 16:19:29 +010012control how the driver would probe I2C buses and attach to devices. These
Luca Ceresoli1ef05722020-01-29 16:19:50 +010013parameters 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).
Jean Delvarec7b25a92009-12-06 17:06:24 +010016
Luca Ceresoli2f07c052020-01-29 16:19:29 +010017With the conversion of the I2C subsystem to the standard device driver
Jean Delvarec7b25a92009-12-06 17:06:24 +010018binding model, it became clear that these per-module parameters were no
19longer needed, and that a centralized implementation was possible. The new,
Luca Ceresoli899b56b2020-01-29 16:19:48 +010020sysfs-based interface is described in :doc:`instantiating-devices`, section
21"Method 4: Instantiate from user-space".
Jean Delvarec7b25a92009-12-06 17:06:24 +010022
23Below is a mapping from the old module parameters to the new interface.
24
25Attaching a driver to an I2C device
26-----------------------------------
27
Mauro Carvalho Chehabccf988b2019-07-26 09:51:16 -030028Old method (module parameters)::
Jean Delvarec7b25a92009-12-06 17:06:24 +010029
Mauro Carvalho Chehabccf988b2019-07-26 09:51:16 -030030 # 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
Jean Delvarec7b25a92009-12-06 17:06:24 +010037
38Preventing a driver from attaching to an I2C device
39---------------------------------------------------
40
Mauro Carvalho Chehabccf988b2019-07-26 09:51:16 -030041Old method (module parameters)::
Jean Delvarec7b25a92009-12-06 17:06:24 +010042
Mauro Carvalho Chehabccf988b2019-07-26 09:51:16 -030043 # 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>
Jean Delvarec7b25a92009-12-06 17:06:24 +010049
Luca Ceresoli1ef05722020-01-29 16:19:50 +010050Of course, it is important to instantiate the ``dummy`` device before loading
Jean Delvarec7b25a92009-12-06 17:06:24 +010051the 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
Luca Ceresoli1ef05722020-01-29 16:19:50 +010054pass the name of the device in question instead of ``dummy``.