[PATCH 0/3] staging: ks7010: refactor tx_device_task()
Greg Kroah-Hartman
gregkh at linuxfoundation.org
Wed Mar 29 14:55:34 UTC 2017
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
More information about the devel
mailing list