On Wed, Mar 29, 2017 at 09:43:38PM +1100, Tobin C. Harding wrote: > On Wed, Mar 29, 2017 at 09:21:20AM +0200, Greg Kroah-Hartman wrote: > > On Sun, Mar 26, 2017 at 07:45:12PM +1100, Tobin C. Harding wrote: > > > Function tx_device_task() is a candidate for refactoring. Checkpatch > > > emits a number of warnings/checks for this function. > > > > > > Patch 01 inverts if statement conditional and reduces the level of > > > nesting. > > > > > > Patch 02 renames rc -> ret, fixes function call and checkpatch WARNING. > > > > > > Patch 03 fixes function argument alignment, and checkpatch CHECK. > > > > > > Code is untested. Patch set applies and builds on x86_64 and PowerPC. > > > > I count 35+ patches from you for the same driver within 2 days. What > > order am I supposed to apply these patches in? Please resend them all > > as a single patch series, so I have a chance to get it right. > > No worries. Is that the easiest way for maintainer/reviewer to have > all changes to a single driver in a single patch set instead of having > multiple patch sets in flight at the same time? What would you rather try to review? (hint, make it totally obvious what to do in what order...) > I am basically a bit lost as to how to structure my work flow when > there are so many things to do in one driver. Obviously I'm new to > this, so any tips would be most appreciated. > > Does one just have to pick some chunk of work to do, do it as a single > patch set then wait for review/merge? And go off and work on something > else? Yes, that's usually the best thing to do. Or, send longer series of patches, after doing more work. thanks, greg k-h _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
