On Fri, Nov 16, 2012 at 05:01:55AM +0900, YAMANE Toshiaki wrote: > On Wed, Nov 14, 2012 at 9:41 PM, Dan Carpenter <dan.carpenter@xxxxxxxxxx> wrote: > > > > Why can't we test whether i == (RxCount - 3) earlier and handle > > the errors there? That way we wouldn't need to pass the limit > > variable. > > > > In fact, this whole function is sort of nasty. We start by doing > > a switch (data[i + 2]) { then we combine the 0x00 and 0x01 and call > > this function which separates them out and sets a function pointer > > and then calls the function point? Get rid of this whole function. > > > > You shouldn't need to use function pointers to do this; that's too > > many levels of abstraction. > > I feel it so diffcult to consider the fixing this patch more. > > There are some reasons why I have become such a description. > - The purpose of this patch is the resolution of the > line over 80 characters issue > - I Wrote the code to be aware of the following: > -- Do not change the procedure > -- The shallow nest > -- To avoid the redundancy > > If I do not use a function pointer, which take the form below. > > if (0x00 == data[i + 2]) > dev_dbg(&port->dev, "Line status status.\n"); > else > dev_dbg(&port->dev, "Modem status status.\n"); > > if (i > limit) { > dev_dbg(&port->dev, > "Illegal escape seuences in received data\n"); > return 0; > } > > if (0x00 == data[i + 2]) > ProcessLineStatus(qt_port, data[i + 3]); > else > ProcessModemStatus(qt_port, data[i + 3]); > > return 1; > > I also feel it may be... > > And I am against to move the dev_dbg procedure call to > qt_status_change_check procedure because the nesting will be so deep. In the end, the new version is more confusing than the original code. Checkpatch.pl is not a king which must be obeyed. The only thing which matters is how easy it is for a human to understand the code. > > >> if (urb->status) { > >> qt_port->ReadBulkStopped = 1; > >> - dev_dbg(&urb->dev->dev, "%s - nonzero write bulk status received: %d\n", > >> + dev_dbg(&urb->dev->dev, > >> + "%s - nonzero write bulk status received: %d\n", > >> __func__, urb->status); > > > > Don't mix in these unrelated 80 character limit changes. > > I think the purpose of refactoring is the resolution of the line over 80 > characters issue. I think that the separation of the patch should stop taking > because they are already applied in the linux-next tree. > Yes, once it is merged into linux-next then it is too late to send a version 2 patch. I'm explaining that as a reviewer it is confusing for me to figure out when you do unrelated things in the same patch and mix everything up. regards, dan carpenter _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel