I have a second patch on my stack, provided by Ky?sti. This is km1 (drop older kernels compatibility), reviewed, fixed and extended. Attached. Patch is voluntarily generated with -U1 so that it won't fail if applied without the first patch. Since this patch only contains removals, no context is really needed. Ky?sti, the next patch I'll push on my stack will be km3+km5. I've cleaned it up and fixed what needed to be so that it compiles and work fine, but there are three points I'd like to hear you about: 1* What is the reason for disabling i2c_get_client? Is it in any way related to locks? To me it belongs to a different patch. 2* Your patch includes a large rewrite of i2cproc_bus_read. How tightly is it related to locks? I see that the new version uses locks, but it also looks like this isn't the reason why the function was rewritten. If possible, we'd better split the patch in two pieces, one for the locks, and one for the rewrite. 3* The argument name change in i2c_smbus_xfer doesn't belong to this patch either. Is it OK to move it apart, or am I missing something? No need to resend a patch, I'll make the updates by myself, providing you answer the questions above, so that I don't break anything. It is important that we provide patches that don't mix too much things, if we want them to be accepted. Thanks. -- Jean Delvare http://www.ensicaen.ismra.fr/~delvare/ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pre2-2-drop-compat.diff Url: http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20031223/e6ce5f63/attachment.pl
