aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/i2c/instantiating-devices
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/i2c/instantiating-devices')
-rw-r--r--Documentation/i2c/instantiating-devices44
1 files changed, 44 insertions, 0 deletions
diff --git a/Documentation/i2c/instantiating-devices b/Documentation/i2c/instantiating-devices
index b55ce57a84db..c740b7b41088 100644
--- a/Documentation/i2c/instantiating-devices
+++ b/Documentation/i2c/instantiating-devices
@@ -165,3 +165,47 @@ was done there. Two significant differences are:
165Once again, method 3 should be avoided wherever possible. Explicit device 165Once again, method 3 should be avoided wherever possible. Explicit device
166instantiation (methods 1 and 2) is much preferred for it is safer and 166instantiation (methods 1 and 2) is much preferred for it is safer and
167faster. 167faster.
168
169
170Method 4: Instantiate from user-space
171-------------------------------------
172
173In general, the kernel should know which I2C devices are connected and
174what addresses they live at. However, in certain cases, it does not, so a
175sysfs interface was added to let the user provide the information. This
176interface is made of 2 attribute files which are created in every I2C bus
177directory: new_device and delete_device. Both files are write only and you
178must write the right parameters to them in order to properly instantiate,
179respectively delete, an I2C device.
180
181File new_device takes 2 parameters: the name of the I2C device (a string)
182and the address of the I2C device (a number, typically expressed in
183hexadecimal starting with 0x, but can also be expressed in decimal.)
184
185File delete_device takes a single parameter: the address of the I2C
186device. As no two devices can live at the same address on a given I2C
187segment, the address is sufficient to uniquely identify the device to be
188deleted.
189
190Example:
191# echo eeprom 0x50 > /sys/class/i2c-adapter/i2c-3/new_device
192
193While this interface should only be used when in-kernel device declaration
194can't be done, there is a variety of cases where it can be helpful:
195* The I2C driver usually detects devices (method 3 above) but the bus
196 segment your device lives on doesn't have the proper class bit set and
197 thus detection doesn't trigger.
198* The I2C driver usually detects devices, but your device lives at an
199 unexpected address.
200* The I2C driver usually detects devices, but your device is not detected,
201 either because the detection routine is too strict, or because your
202 device is not officially supported yet but you know it is compatible.
203* You are developing a driver on a test board, where you soldered the I2C
204 device yourself.
205
206This interface is a replacement for the force_* module parameters some I2C
207drivers implement. Being implemented in i2c-core rather than in each
208device driver individually, it is much more efficient, and also has the
209advantage that you do not have to reload the driver to change a setting.
210You can also instantiate the device before the driver is loaded or even
211available, and you don't need to know what driver the device needs.