diff options
author | Jean Delvare <khali@linux-fr.org> | 2009-06-19 10:58:18 -0400 |
---|---|---|
committer | Jean Delvare <khali@linux-fr.org> | 2009-06-19 10:58:18 -0400 |
commit | 729d6dd571464954f625e6b80950d9e4e3bd94f7 (patch) | |
tree | faf8ada32b03c8bc07e1ddb8ec0d26d6440b6d98 /Documentation/i2c/writing-clients | |
parent | 352da9820e5506e3b8496e6052a2ad9c488efae8 (diff) |
i2c: Get rid of the legacy binding model
We converted all the legacy i2c drivers so we can finally get rid of
the legacy binding model. Hooray!
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Diffstat (limited to 'Documentation/i2c/writing-clients')
-rw-r--r-- | Documentation/i2c/writing-clients | 16 |
1 files changed, 3 insertions, 13 deletions
diff --git a/Documentation/i2c/writing-clients b/Documentation/i2c/writing-clients index c1a06f989cf7..7860aafb483d 100644 --- a/Documentation/i2c/writing-clients +++ b/Documentation/i2c/writing-clients | |||
@@ -126,19 +126,9 @@ different) configuration information, as do drivers handling chip variants | |||
126 | that can't be distinguished by protocol probing, or which need some board | 126 | that can't be distinguished by protocol probing, or which need some board |
127 | specific information to operate correctly. | 127 | specific information to operate correctly. |
128 | 128 | ||
129 | Accordingly, the I2C stack now has two models for associating I2C devices | ||
130 | with their drivers: the original "legacy" model, and a newer one that's | ||
131 | fully compatible with the Linux 2.6 driver model. These models do not mix, | ||
132 | since the "legacy" model requires drivers to create "i2c_client" device | ||
133 | objects after SMBus style probing, while the Linux driver model expects | ||
134 | drivers to be given such device objects in their probe() routines. | ||
135 | 129 | ||
136 | The legacy model is deprecated now and will soon be removed, so we no | 130 | Device/Driver Binding |
137 | longer document it here. | 131 | --------------------- |
138 | |||
139 | |||
140 | Standard Driver Model Binding ("New Style") | ||
141 | ------------------------------------------- | ||
142 | 132 | ||
143 | System infrastructure, typically board-specific initialization code or | 133 | System infrastructure, typically board-specific initialization code or |
144 | boot firmware, reports what I2C devices exist. For example, there may be | 134 | boot firmware, reports what I2C devices exist. For example, there may be |
@@ -201,7 +191,7 @@ a given I2C bus. This is for example the case of hardware monitoring | |||
201 | devices on a PC's SMBus. In that case, you may want to let your driver | 191 | devices on a PC's SMBus. In that case, you may want to let your driver |
202 | detect supported devices automatically. This is how the legacy model | 192 | detect supported devices automatically. This is how the legacy model |
203 | was working, and is now available as an extension to the standard | 193 | was working, and is now available as an extension to the standard |
204 | driver model (so that we can finally get rid of the legacy model.) | 194 | driver model. |
205 | 195 | ||
206 | You simply have to define a detect callback which will attempt to | 196 | You simply have to define a detect callback which will attempt to |
207 | identify supported devices (returning 0 for supported ones and -ENODEV | 197 | identify supported devices (returning 0 for supported ones and -ENODEV |