On Wed, 08 May 2013, Mark Brown wrote: > On Wed, May 08, 2013 at 10:39:14AM +0200, Fabio Baltieri wrote: > > As enable_msp gets called only after some audio data has been received, > > if the userspace closes the device before sending any data it causes > > ux500_msp_i2s_close to clear device state even if it was not previously > > initialized. > > Ugh, please don't do stuff like this - you're posting an individual > revision of a patch buried in the middle of a thread. This just makes > things hard to follow and error prone. Repost the patch series
It's so much more convenient to do it this way. Re-sending entire patch-sets for small fixups is clumsy and annoying at best. Creating much more churn than is actually required. Sending patches again signally i.e. not as a reply to the original [PATCH x/x], would be even more prone to error. Personally, I like to get the niggles and fixups out of the way using this method, then send the entire patch-set again, complete with all of the reaped Acks once there are significant fixes or when I believe it to be finished and ready for applying. Surely most people have their mail setup as threaded? Then the time-line and subsequent patch versions are very easy to follow aren't they? I get a nice trace like this: > <date> Fabio Baltieri ( 0) ├>[PATCH 2/6] ASoC: ux500: <snip> > <date> To Fabio Baltieri ( 0) │└> > <date> Fabio Baltieri ( 0) │ └>[PATCH v2 2/6] ASoC: <snip> ... or even better would be to reply to the original one, then subsequent versions won't be "buried in the thread" per say: > <date> Fabio Baltieri ( 0) ├>[PATCH 2/6] ASoC: ux500: <snip> > <date> Fabio Baltieri ( 0) │ └>[PATCH v2 2/6] ASoC: <snip> > <date> To Fabio Baltieri ( 0) │-> > or wait until what can be applied is applied then repost. Taking patches out-of-order, or 'willy-nilly', is asking for trouble. -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
