> > 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 -------------- An embedded and charset-unspecified text was scrubbed... Name: porting-chip-drivers-to-linux-2.6.txt Url: http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20030928/fabf1682/attachment.txt
