2020-01-29 23:19:51 +08:00
|
|
|
================================================================
|
|
|
|
|
I2C device driver binding control from user-space in old kernels
|
|
|
|
|
================================================================
|
2009-12-07 00:06:24 +08:00
|
|
|
|
2020-01-29 23:19:49 +08:00
|
|
|
.. NOTE::
|
|
|
|
|
Note: this section is only relevant if you are handling some old code
|
|
|
|
|
found in kernel 2.6. If you work with more recent kernels, you can
|
|
|
|
|
safely skip this section.
|
|
|
|
|
|
2020-01-29 23:19:29 +08:00
|
|
|
Up to kernel 2.6.32, many I2C drivers used helper macros provided by
|
2009-12-07 00:06:24 +08:00
|
|
|
<linux/i2c.h> which created standard module parameters to let the user
|
2020-01-29 23:19:29 +08:00
|
|
|
control how the driver would probe I2C buses and attach to devices. These
|
2020-01-29 23:19:50 +08:00
|
|
|
parameters were known as ``probe`` (to let the driver probe for an extra
|
|
|
|
|
address), ``force`` (to forcibly attach the driver to a given device) and
|
|
|
|
|
``ignore`` (to prevent a driver from probing a given address).
|
2009-12-07 00:06:24 +08:00
|
|
|
|
2020-01-29 23:19:29 +08:00
|
|
|
With the conversion of the I2C subsystem to the standard device driver
|
2009-12-07 00:06:24 +08:00
|
|
|
binding model, it became clear that these per-module parameters were no
|
|
|
|
|
longer needed, and that a centralized implementation was possible. The new,
|
2021-06-16 14:27:33 +08:00
|
|
|
sysfs-based interface is described in
|
|
|
|
|
Documentation/i2c/instantiating-devices.rst, section
|
2020-01-29 23:19:48 +08:00
|
|
|
"Method 4: Instantiate from user-space".
|
2009-12-07 00:06:24 +08:00
|
|
|
|
|
|
|
|
Below is a mapping from the old module parameters to the new interface.
|
|
|
|
|
|
|
|
|
|
Attaching a driver to an I2C device
|
|
|
|
|
-----------------------------------
|
|
|
|
|
|
2019-07-26 20:51:16 +08:00
|
|
|
Old method (module parameters)::
|
|
|
|
|
|
|
|
|
|
# modprobe <driver> probe=1,0x2d
|
|
|
|
|
# modprobe <driver> force=1,0x2d
|
|
|
|
|
# modprobe <driver> force_<device>=1,0x2d
|
|
|
|
|
|
|
|
|
|
New method (sysfs interface)::
|
2009-12-07 00:06:24 +08:00
|
|
|
|
2019-07-26 20:51:16 +08:00
|
|
|
# echo <device> 0x2d > /sys/bus/i2c/devices/i2c-1/new_device
|
2009-12-07 00:06:24 +08:00
|
|
|
|
|
|
|
|
Preventing a driver from attaching to an I2C device
|
|
|
|
|
---------------------------------------------------
|
|
|
|
|
|
2019-07-26 20:51:16 +08:00
|
|
|
Old method (module parameters)::
|
|
|
|
|
|
|
|
|
|
# modprobe <driver> ignore=1,0x2f
|
|
|
|
|
|
|
|
|
|
New method (sysfs interface)::
|
2009-12-07 00:06:24 +08:00
|
|
|
|
2019-07-26 20:51:16 +08:00
|
|
|
# echo dummy 0x2f > /sys/bus/i2c/devices/i2c-1/new_device
|
|
|
|
|
# modprobe <driver>
|
2009-12-07 00:06:24 +08:00
|
|
|
|
2020-01-29 23:19:50 +08:00
|
|
|
Of course, it is important to instantiate the ``dummy`` device before loading
|
2009-12-07 00:06:24 +08:00
|
|
|
the driver. The dummy device will be handled by i2c-core itself, preventing
|
|
|
|
|
other drivers from binding to it later on. If there is a real device at the
|
|
|
|
|
problematic address, and you want another driver to bind to it, then simply
|
2020-01-29 23:19:50 +08:00
|
|
|
pass the name of the device in question instead of ``dummy``.
|
