Conversion guide for i2c chip drivers

Conversion guide for i2c chip drivers

[Jean Delvare]

Hi Greg,

I'm in the process of writting a conversion guide for i2c chip drivers.
First version attached. Please tell me what you think about it. There's
at least two things I'd like explanations on:

In the detect function, why is memset called on client data before it is
filled?

Why is client data handled with i2c_set_clientdata and
i2c_get_clientdata instead of direct access?

I'd need to explain that in my guide, but don't understand it myself.

Thanks.

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/
-------------- next part --------------
2003-09-27, Jean Delvare <khali@linux-fr.org>

This is a guide on how to convert I2C chip drivers from Linux 2.4 to
Linux 2.6. I have been using the simple lm75 driver as an example.

There are two sets of points below. The first set concerns technical
points and are mandatory. The second set concerns coding policy, you
are strongly invited to follow them.

Mandatory:

* [Includes] Get rid of "version.h". Replace <linux/i2c-proc.h> with
  <linux/i2c-sensor.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 */
  Some extra headers may be required for a given driver.

* [Addresses] SENSORS_I2C_END becomes I2C_CLIENT_END, SENSORS_ISA_END
  becomes I2C_CLIENT_ISA_END.

* [Client data] Get rid of sysctl_id. Use standard names for register
  values (for example, temp becomes temp_input, temp_os becomes
  temp_max).

* [Function prototypes] The detect functions loses its flags
  parameter. Sysctl (e.g. lm75_temp) and miscellaneous (e.g.
  swap_bytes) functions are off the list of prototypes.

* [Sysctl] All sysctl stuff is of course gone (defines, ctl_table
  and functions). Instead, right after the static id definition
  line, you have to define show and set functions for each sysfs
  file. Only define set for writable values. You may want to create
  two macros first, because the functions are always the same. Take
  a look at an existing 2.6 driver for details (lm75 is a a good one
  because it is simple). Don't forget to define the attributes for
  each file (this is that step that links callback functions).

* [Attach] The attach function should make sure that the adapter's
  class is I2C_ADAP_CLASS_SMBUS, using the following construct:
  if (!(adapter->class & I2C_ADAP_CLASS_SMBUS))
          return 0;

* [Detect] As mentioned earlier, the flags parameter is gone.
  The type_name and client_name strings are replaced by a single
  name string, which will be filled with a lowercase, short string
  (typically the driver name, e.g. "lm75). The errorN labels are
  reduced to the number needed. If that number is 2 (i2c-only
  drivers), it is advised that the labels are named exit and
  exit_free. For i2c+isa drivers, labels should be named ERROR0,
  ERROR1 and ERROR2. Don't forget to properly set err before
  jumping to error labels. By the way, labels should be
  left-aligned.
  i2c_set_clientdata ?
  Use strlcpy instead of strcpy to copy the client name.
  Replace the sysctl directory registration by calls to
  device_create_file.

* [Detach] Get rid of data, remove call to deregister_entry.

* [Update] Don't access client->data directly, use
  i2c_get_clientdata(client) instead.

* [Interface] Use standard names for init and exit functions
  (e.g. sensors_lm75_init and sensors_lm75_exit). Init function
  should not print anything. Make sure that MODULE_LICENSE is
  called.

Recommended:

* [Debug] Debug code should be placed inside #ifdef DEBUG/#endif
  constructs. A commented line to define DEBUG should be provided
  near the top of the script. Calls to printk/pr_debug for debugging
  purposes are replaced by calls to dev_dbg. Here is an example on
  how to call it (taken from lm75_detect):
  dev_dbg(&adapter->dev,
          "lm75_detect called for an ISA bus adapter?!?\n");
  For other prink calls, don't forget the KERN_* prefix.

* [Constants] Constants defines (registers, conversions, initial
  values) should be aligned. This greatly improves readability.
  Same goes for variables declarations.

* [Structure definition] The name field should be standardized. All
  lowercase and as simple as the driver name itself (e.g. "lm75").

Conversion guide for i2c chip drivers

[Greg KH]

Oops, forgot one:

> * [Client data] Get rid of sysctl_id. Use standard names for register
>   values (for example, temp becomes temp_input, temp_os becomes
>   temp_max).

Use the file names specified in Documentation/i2c/sysfs-interface for
the individual files.  Also convert the units these files read and write
to the specified ones.

If you need to add a new type of file, please discuss it on the sensors
mailing by providing a patch to the Documentation/i2c/sysfs-interface
file.

thanks,

greg k-h

Conversion guide for i2c chip drivers

[Greg KH]

On Sat, Sep 27, 2003 at 12:24:51PM +0200, Jean Delvare wrote:
> 
> Hi Greg,
> 
> I'm in the process of writting a conversion guide for i2c chip drivers.
> First version attached. Please tell me what you think about it. There's
> at least two things I'd like explanations on:
> 
> In the detect function, why is memset called on client data before it is
> filled?

Because the struct device burried in that structure needs to be set to 0
before the register function is called.

> Why is client data handled with i2c_set_clientdata and
> i2c_get_clientdata instead of direct access?

Because it's easier that way :)
This way a driver will work with both 2.4 and 2.6 without having to
figure out exactly where to store it's private data.  It's much cleaner
that way.

> I'd need to explain that in my guide, but don't understand it myself.

Looks good, I have a few minor comments below:

> * [Attach] The attach function should make sure that the adapter's
>   class is I2C_ADAP_CLASS_SMBUS, using the following construct:
>   if (!(adapter->class & I2C_ADAP_CLASS_SMBUS))
>           return 0;

For smbus drivers, right?  isa drivers would not do this :)

> * [Detect] As mentioned earlier, the flags parameter is gone.
>   The type_name and client_name strings are replaced by a single
>   name string, which will be filled with a lowercase, short string
>   (typically the driver name, e.g. "lm75). The errorN labels are
>   reduced to the number needed. If that number is 2 (i2c-only
>   drivers), it is advised that the labels are named exit and
>   exit_free. For i2c+isa drivers, labels should be named ERROR0,
>   ERROR1 and ERROR2. Don't forget to properly set err before
>   jumping to error labels. By the way, labels should be
>   left-aligned.
>   i2c_set_clientdata ?

Use it :)

> * [Interface] Use standard names for init and exit functions
>   (e.g. sensors_lm75_init and sensors_lm75_exit). Init function
>   should not print anything. Make sure that MODULE_LICENSE is
>   called.

"called"?  You mean there must be a MODULE_LICENSE() line in the file,
that's all.

> Recommended:
> 
> * [Debug] Debug code should be placed inside #ifdef DEBUG/#endif
>   constructs.

No.  No #ifdefs if they can possibly be gotten rid of.  The only ones I
have left in is where some logic changes based on the DEBUG flag (which
in reality, shouldn't be there either.)  Use the dev_dbg() function
instead.

>   A commented line to define DEBUG should be provided
>   near the top of the script. Calls to printk/pr_debug for debugging
>   purposes are replaced by calls to dev_dbg. Here is an example on
>   how to call it (taken from lm75_detect):
>   dev_dbg(&adapter->dev,
>           "lm75_detect called for an ISA bus adapter?!?\n");
>   For other prink calls, don't forget the KERN_* prefix.

No, for almost all printk calls, use the proper dev_* call instead.
That provides a consistant interface to userspace so that the exact
device can be determined that is spitting out the messages.

Other than those minor comments, looks good.

thanks,

greg k-h

Conversion guide for i2c chip drivers

[Jean Delvare]

> "porting-chip-drivers-2.4-to-2.6"?  Why make it short?  :)

Because all our other docs have short names. And I usually avoid names
longer than 23, to keep "ls -l" happy. I could place the document in our
doc/chips subdirectory and name it "PORTING-2.6". BTW, I don't think the
busses and chips documentation is included into Linux 2.6.0-testX. Is it
on purpose (users will want to download lm_sensors for at least
sensors-detect anyway)?

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

Conversion guide for i2c chip drivers

[Jean Delvare]

> > In the detect function, why is memset called on client data before
> > it is filled?
> 
> Because the struct device burried in that structure needs to be set to
> 0 before the register function is called.

This doesn't answer my question. I know what memset does. What I don't
know is why this is done, or, to make my question more precise, why it
is done in 2.6 and wasn't in 2.4.

> > Why is client data handled with i2c_set_clientdata and
> > i2c_get_clientdata instead of direct access?
> 
> Because it's easier that way :)
> This way a driver will work with both 2.4 and 2.6 without having to
> figure out exactly where to store it's private data.  It's much
> cleaner that way.

I don't follow you here either. Each chip driver is allocating the data
space by itself anyway, and the same way as in 2.4. What's more, 2.4
doesn't have i2c_set_clientdata. After reading what the function does,
it turns out that the main (well, unique) goal is to provide a standard
way to retrieve any driver's data pointer using dev_get_drvdata. So I
don't really get why we are not using dev_set_drvdata directly. Oh well,
this may simply be over me.

(some times after)

Mmm, maybe I get it now. You plan to introduce an i2c_set_clientdata
function in 2.4, which will access client->data instead of client->dev
as it is the case in 2.6. Is that it?

OK, I've made the requested changes, plus some others. Document
attached.

I will now be using my own guide to convert some drivers. That way, I'll
see if it is correct or not ;) After that, we'll consider releasing the
document.

Thanks a lot Greg for the comments.

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/
-------------- next part --------------
Revision 2, 2003-09-28
Jean Delvare <khali@linux-fr.org>
Greg KH <greg@kroah.com>

This is a guide on how to convert I2C chip drivers from Linux 2.4 to
Linux 2.6. I have been using the simple lm75 driver as an example.

There are two sets of points below. The first set concerns technical
points and are mandatory. The second set concerns coding policy, you
are strongly invited to follow them.

Although reading this guide will help you porting drivers, I suggest
you generate a diff between the original and ported version of an
already ported driver (lm75 for a simple, temperature only chip,
lm78 for a more complex one) and use it as a base. Use the chip
driver that is the more similar to yours for best results.

Mandatory:

* [Includes] Get rid of "version.h". Replace <linux/i2c-proc.h> with
  <linux/i2c-sensor.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 */
  Some extra headers may be required for a given driver.

* [Addresses] SENSORS_I2C_END becomes I2C_CLIENT_END, SENSORS_ISA_END
  becomes I2C_CLIENT_ISA_END.

* [Client data] Get rid of sysctl_id. Use standard names for register
  values (for example, temp becomes temp_input, temp_os becomes
  temp_max). Use the file names specified in
  Documentation/i2c/sysfs-interface for the individual files. Also
  convert the units these files read and write to the specified ones.
  If you need to add a new type of file, please discuss it on the
  sensors mailing list <sensors@stimpy.netroedge.com> by providing a
  patch to the Documentation/i2c/sysfs-interface file.

* [Function prototypes] The detect functions loses its flags
  parameter. Sysctl (e.g. lm75_temp) and miscellaneous (e.g.
  swap_bytes) functions are off the list of prototypes.

* [Sysctl] All sysctl stuff is of course gone (defines, ctl_table
  and functions). Instead, right after the static id definition
  line, you have to define show and set functions for each sysfs
  file. Only define set for writable values. You may want to create
  two macros first, because the functions are always the same. Take
  a look at an existing 2.6 driver for details (lm75 is a a good one
  because it is simple). Don't forget to define the attributes for
  each file (this is that step that links callback functions).

* [Attach] For I2C drivers, the attach function should make sure
  that the adapter's class has I2C_ADAP_CLASS_SMBUS, using the
  following construct:
  if (!(adapter->class & I2C_ADAP_CLASS_SMBUS))
          return 0;
  ISA-only drivers of course don't need this.

* [Detect] As mentioned earlier, the flags parameter is gone.
  The type_name and client_name strings are replaced by a single
  name string, which will be filled with a lowercase, short string
  (typically the driver name, e.g. "lm75). The errorN labels are
  reduced to the number needed. If that number is 2 (i2c-only
  drivers), it is advised that the labels are named exit and
  exit_free. For i2c+isa drivers, labels should be named ERROR0,
  ERROR1 and ERROR2. Don't forget to properly set err before
  jumping to error labels. By the way, labels should be
  left-aligned.
  Use memset to fill the client and data area with 0x00.
  Use i2c_set_clientdata to set the client data (as opposed to
  a direct access to client->data).
  Use strlcpy instead of strcpy to copy the client name.
  Replace the sysctl directory registration by calls to
  device_create_file.

* [Detach] Get rid of data, remove call to deregister_entry.

* [Update] Don't access client->data directly, use
  i2c_get_clientdata(client) instead.

* [Interface] Use standard names for init and exit functions
  (e.g. sensors_lm75_init and sensors_lm75_exit). Init function
  should not print anything. Make sure there is a MODULE_LICENSE()
  line.

Recommended:

* [Debug/log] Get it of #ifdef DEBUG/#endif constructs whenever you
  can. Calls to printk/pr_debug for debugging purposes are replaced
  by calls to dev_dbg. Here is an example on how to call it (taken
  from lm75_detect):
  dev_dbg(&adapter->dev,
          "lm75_detect called for an ISA bus adapter?!?\n");
  Replace other prink calls with the dev_info, dev_err or dev_warn
  function, as appropriate.

* [Constants] Constants defines (registers, conversions, initial
  values) should be aligned. This greatly improves readability.
  Same goes for variables declarations.

* [Structure definition] The name field should be standardized. All
  lowercase and as simple as the driver name itself (e.g. "lm75").

Conversion guide for i2c chip drivers

[Greg KH]

On Sat, Oct 04, 2003 at 06:09:52PM +0200, Jean Delvare wrote:
> 
> > You should go ahead and check your document into doc/developers now,
> > you can always make more changes in CVS later...
> 
> Will do. How would I name that document? Not sure how to find a short
> name that says what it does. "porting-chips-2.6" maybe?

"porting-chip-drivers-2.4-to-2.6"?  Why make it short?  :)

greg k-h

Conversion guide for i2c chip drivers

[Greg KH]

On Sun, Sep 28, 2003 at 03:15:07PM +0200, Jean Delvare wrote:
> 
> > > In the detect function, why is memset called on client data before
> > > it is filled?
> > 
> > Because the struct device burried in that structure needs to be set to
> > 0 before the register function is called.
> 
> This doesn't answer my question. I know what memset does. What I don't
> know is why this is done, or, to make my question more precise, why it
> is done in 2.6 and wasn't in 2.4.

Again, we have to initialize a struct device to 0 before register is
called, otherwise we oops the kernel.  2.4 does not have a struct device
in the i2c code (or anywhere actually...)

But hey, don't trust me, try not doing it and see what happens :)

> Mmm, maybe I get it now. You plan to introduce an i2c_set_clientdata
> function in 2.4, which will access client->data instead of client->dev
> as it is the case in 2.6. Is that it?

Yes, that's it.

> OK, I've made the requested changes, plus some others. Document
> attached.

Looks good, thanks for doing this.

greg k-h

Conversion guide for i2c chip drivers

[Greg KH]

On Sun, Oct 05, 2003 at 11:37:22AM +0200, Jean Delvare wrote:
> 
> > "porting-chip-drivers-2.4-to-2.6"?  Why make it short?  :)
> 
> Because all our other docs have short names. And I usually avoid names
> longer than 23, to keep "ls -l" happy. I could place the document in our
> doc/chips subdirectory and name it "PORTING-2.6".

Ok, that's fine with me.  Want to add my porting bus drivers document
too?

> BTW, I don't think the busses and chips documentation is included into
> Linux 2.6.0-testX. Is it on purpose (users will want to download
> lm_sensors for at least sensors-detect anyway)?

Care to send a patch to fix this?  :)

thanks,

greg k-h

Conversion guide for i2c chip drivers

[Mark Studebaker]

You should go ahead and check your document into doc/developers now,
you can always make more changes in CVS later...


Jean Delvare wrote:

> OK, I've made the requested changes, plus some others. Document
> attached.
> 
> I will now be using my own guide to convert some drivers. That way, I'll
> see if it is correct or not ;) After that, we'll consider releasing the
> document.
> 
> Thanks a lot Greg for the comments.
> 
> --
> Jean Delvare
> http://www.ensicaen.ismra.fr/~delvare/
> 
> 
>                                             Name: porting-chip-drivers-to-linux-2.6.txt
>    porting-chip-drivers-to-linux-2.6.txt    Type: Plain Text (text/plain)
>                                         Encoding: 7bit

Conversion guide for i2c chip drivers

[Jean Delvare]

> You should go ahead and check your document into doc/developers now,
> you can always make more changes in CVS later...

Will do. How would I name that document? Not sure how to find a short
name that says what it does. "porting-chips-2.6" maybe?

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/