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