Orange Pi5 kernel

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