diff options
Diffstat (limited to 'Documentation/i2c/instantiating-devices')
-rw-r--r-- | Documentation/i2c/instantiating-devices | 44 |
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: | |||
165 | Once again, method 3 should be avoided wherever possible. Explicit device | 165 | Once again, method 3 should be avoided wherever possible. Explicit device |
166 | instantiation (methods 1 and 2) is much preferred for it is safer and | 166 | instantiation (methods 1 and 2) is much preferred for it is safer and |
167 | faster. | 167 | faster. |
168 | |||
169 | |||
170 | Method 4: Instantiate from user-space | ||
171 | ------------------------------------- | ||
172 | |||
173 | In general, the kernel should know which I2C devices are connected and | ||
174 | what addresses they live at. However, in certain cases, it does not, so a | ||
175 | sysfs interface was added to let the user provide the information. This | ||
176 | interface is made of 2 attribute files which are created in every I2C bus | ||
177 | directory: new_device and delete_device. Both files are write only and you | ||
178 | must write the right parameters to them in order to properly instantiate, | ||
179 | respectively delete, an I2C device. | ||
180 | |||
181 | File new_device takes 2 parameters: the name of the I2C device (a string) | ||
182 | and the address of the I2C device (a number, typically expressed in | ||
183 | hexadecimal starting with 0x, but can also be expressed in decimal.) | ||
184 | |||
185 | File delete_device takes a single parameter: the address of the I2C | ||
186 | device. As no two devices can live at the same address on a given I2C | ||
187 | segment, the address is sufficient to uniquely identify the device to be | ||
188 | deleted. | ||
189 | |||
190 | Example: | ||
191 | # echo eeprom 0x50 > /sys/class/i2c-adapter/i2c-3/new_device | ||
192 | |||
193 | While this interface should only be used when in-kernel device declaration | ||
194 | can'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 | |||
206 | This interface is a replacement for the force_* module parameters some I2C | ||
207 | drivers implement. Being implemented in i2c-core rather than in each | ||
208 | device driver individually, it is much more efficient, and also has the | ||
209 | advantage that you do not have to reload the driver to change a setting. | ||
210 | You can also instantiate the device before the driver is loaded or even | ||
211 | available, and you don't need to know what driver the device needs. | ||