Greg KH wrote: >On Wed, Mar 02, 2005 at 01:58:51PM -0600, Corey Minyard wrote: > > >>This patch reorganizes the I2C SMBus formatting code to make it more >>suitable for the upcoming non-blocking changes. >> >> > >You are changing too much stuff here to claim it's just a >reorganization: > - variable name changes for no reason > > Well, yes. Both "adap" and "adapter" are used to refer to the same thing in the file; "adap" seemed to be the most common usage so I chose that for the new functions I added. In one place I changed adapter to adap. I also changed "res" to "result". I can fix those. Or I can submit a patch first that renames the adap and adapter to make the usage consistent (I would prefer adapter). > - coding style changes (improper ones at that) > > I don't see that. The ugliest thing about this is the functions that take the massive numbers of parameters, but that goes away in the next patch which puts all the data into a single data structure and passes it around. The code here was also very inconsistent about use of spaces, like x(a,b,c) vs x(a, b, c), "struct a *b" vs "struct a * b", "a=b" vs "a = b". It's hard to know what was right. The changes I made in these respects was to try to make it use the usage most common in the file. If you like, I can do a pass and make everything consistent in the file as part of the previous patch I talked about. > - logic changes. > > I tried very hard not to make logic changes. Now I see there were two places where the function checked client->adapter->algo->master_xfer then called i2c_transfer(), which did the same check and returned the same error if it was NULL. I removed the redundant check. That belongs in a separate patch. I couldn't find any others. >What exactly are you doing with this patch, and why? > > The i2c main functions do the following: Format the data for transmission Send the data to the next layer down for handling Clean up the results The original code did all this in single big functions. This patch breaks the formatting and cleanup operations into separate functions. Beyond one big function being ugly, the non-blocking code needs this because it needs to perform these separately. When you start the operation, the non-blocking code needs to do the format then return. Later on, when the operation is complete, the thread of execution handling the completion will do the cleanup. -Corey
