summaryrefslogtreecommitdiff
path: root/Documentation/i2c
diff options
context:
space:
mode:
authorJean Delvare <khali@linux-fr.org>2005-07-31 23:49:03 +0400
committerGreg Kroah-Hartman <gregkh@suse.de>2005-09-05 20:14:21 +0400
commitf4b50261207c987913f076d867c2e154d71fd012 (patch)
tree0b50cfa93f2e1e6a877f51028f93539db0e4547e /Documentation/i2c
parent96478ef3f3f71fa929cc905cc794993e312d9a5d (diff)
downloadlinux-f4b50261207c987913f076d867c2e154d71fd012.tar.xz
[PATCH] hwmon: hwmon vs i2c, second round (06/11)
The only thing left in i2c-sensor.h are module parameter definition macros. It's only an extension of what i2c.h offers, and this extension is not sensors-specific. As a matter of fact, a few non-sensors drivers use them. So we better merge them in i2c.h, and get rid of i2c-sensor.h altogether. Signed-off-by: Jean Delvare <khali@linux-fr> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Diffstat (limited to 'Documentation/i2c')
-rw-r--r--Documentation/i2c/porting-clients8
-rw-r--r--Documentation/i2c/writing-clients68
2 files changed, 19 insertions, 57 deletions
diff --git a/Documentation/i2c/porting-clients b/Documentation/i2c/porting-clients
index f9099211bd0b..8b819379adcb 100644
--- a/Documentation/i2c/porting-clients
+++ b/Documentation/i2c/porting-clients
@@ -1,4 +1,4 @@
-Revision 4, 2004-03-30
+Revision 5, 2005-07-29
Jean Delvare <khali@linux-fr.org>
Greg KH <greg@kroah.com>
@@ -17,13 +17,12 @@ yours for best results.
Technical changes:
-* [Includes] Get rid of "version.h". Replace <linux/i2c-proc.h> with
- <linux/i2c-sensor.h>. Includes typically look like that:
+* [Includes] Get rid of "version.h" and <linux/i2c-proc.h>.
+ Includes typically look like that:
#include <linux/module.h>
#include <linux/init.h>
#include <linux/slab.h>
#include <linux/i2c.h>
- #include <linux/i2c-sensor.h>
#include <linux/i2c-vid.h> /* if you need VRM support */
#include <asm/io.h> /* if you have I/O operations */
Please respect this inclusion order. Some extra headers may be
@@ -31,6 +30,7 @@ Technical changes:
* [Addresses] SENSORS_I2C_END becomes I2C_CLIENT_END, ISA addresses
are no more handled by the i2c core.
+ SENSORS_INSMOD_<n> becomes I2C_CLIENT_INSMOD_<n>.
* [Client data] Get rid of sysctl_id. Try using standard names for
register values (for example, temp_os becomes temp_max). You're
diff --git a/Documentation/i2c/writing-clients b/Documentation/i2c/writing-clients
index 43d7928056ae..97e138cbb2a9 100644
--- a/Documentation/i2c/writing-clients
+++ b/Documentation/i2c/writing-clients
@@ -155,8 +155,8 @@ NOTE: If you want to write a `sensors' driver, the interface is slightly
-Probing classes (i2c)
----------------------
+Probing classes
+---------------
All parameters are given as lists of unsigned 16-bit integers. Lists are
terminated by I2C_CLIENT_END.
@@ -171,12 +171,18 @@ The following lists are used internally:
ignore: insmod parameter.
A list of pairs. The first value is a bus number (-1 for any I2C bus),
the second is the I2C address. These addresses are never probed.
- This parameter overrules 'normal' and 'probe', but not the 'force' lists.
+ This parameter overrules the 'normal_i2c' list only.
force: insmod parameter.
A list of pairs. The first value is a bus number (-1 for any I2C bus),
the second is the I2C address. A device is blindly assumed to be on
the given address, no probing is done.
+Additionally, kind-specific force lists may optionally be defined if
+the driver supports several chip kinds. They are grouped in a
+NULL-terminated list of pointers named forces, those first element if the
+generic force list mentioned above. Each additional list correspond to an
+insmod parameter of the form force_<kind>.
+
Fortunately, as a module writer, you just have to define the `normal_i2c'
parameter. The complete declaration could look like this:
@@ -186,61 +192,17 @@ parameter. The complete declaration could look like this:
/* Magic definition of all other variables and things */
I2C_CLIENT_INSMOD;
+ /* Or, if your driver supports, say, 2 kind of devices: */
+ I2C_CLIENT_INSMOD_2(foo, bar);
+
+If you use the multi-kind form, an enum will be defined for you:
+ enum chips { any_chip, foo, bar, ... }
+You can then (and certainly should) use it in the driver code.
Note that you *have* to call the defined variable `normal_i2c',
without any prefix!
-Probing classes (sensors)
--------------------------
-
-If you write a `sensors' driver, you use a slightly different interface.
-Also, we use a enum of chip types. Don't forget to include `sensors.h'.
-
-The following lists are used internally. They are all lists of integers.
-
- normal_i2c: filled in by the module writer. Terminated by I2C_CLIENT_END.
- A list of I2C addresses which should normally be examined.
- probe: insmod parameter. Initialize this list with I2C_CLIENT_END values.
- A list of pairs. The first value is a bus number (ANY_I2C_BUS for any
- I2C bus), the second is the address. These addresses are also probed,
- as if they were in the 'normal' list.
- ignore: insmod parameter. Initialize this list with I2C_CLIENT_END values.
- A list of pairs. The first value is a bus number (ANY_I2C_BUS for any
- I2C bus), the second is the I2C address. These addresses are never
- probed. This parameter overrules 'normal' and 'probe', but not the
- 'force' lists.
-
-Also used is a list of pointers to sensors_force_data structures:
- force_data: insmod parameters. A list, ending with an element of which
- the force field is NULL.
- Each element contains the type of chip and a list of pairs.
- The first value is a bus number (ANY_I2C_BUS for any I2C bus), the
- second is the address.
- These are automatically translated to insmod variables of the form
- force_foo.
-
-So we have a generic insmod variabled `force', and chip-specific variables
-`force_CHIPNAME'.
-
-Fortunately, as a module writer, you just have to define the `normal_i2c'
-parameter, and define what chip names are used. The complete declaration
-could look like this:
- /* Scan i2c addresses 0x37, and 0x48 to 0x4f */
- static unsigned short normal_i2c[] = { 0x37, 0x48, 0x49, 0x4a, 0x4b, 0x4c,
- 0x4d, 0x4e, 0x4f, I2C_CLIENT_END };
-
- /* Define chips foo and bar, as well as all module parameters and things */
- SENSORS_INSMOD_2(foo,bar);
-
-If you have one chip, you use macro SENSORS_INSMOD_1(chip), if you have 2
-you use macro SENSORS_INSMOD_2(chip1,chip2), etc. If you do not want to
-bother with chip types, you can use SENSORS_INSMOD_0.
-
-A enum is automatically defined as follows:
- enum chips { any_chip, chip1, chip2, ... }
-
-
Attaching to an adapter
-----------------------