Julian Calaby <julian.calaby@xxxxxxxxx> writes: > Hi Jes, > > On Tue, Mar 1, 2016 at 10:48 AM, Jes Sorensen <Jes.Sorensen@xxxxxxxxxx> wrote: >> Julian Calaby <julian.calaby@xxxxxxxxx> writes: >>> Hi Jes, >>> >>> On Tue, Mar 1, 2016 at 9:05 AM, <Jes.Sorensen@xxxxxxxxxx> wrote: >>>> From: Jes Sorensen <Jes.Sorensen@xxxxxxxxxx> >>>> >>>> Having a version for the newer chips without calling it doesn't do >>>> much good..... >>>> >>>> Signed-off-by: Jes Sorensen <Jes.Sorensen@xxxxxxxxxx> >>> >>> Should this be squashed into the patch that introduces the new op? >> >> I can start rewriting history, but all that comes out of that is having >> to fight patch conflicts rebasing things. >> >> If there was an actual functional reason for it, sure, but in this case >> there isn't. > > Fair enough, it just looks odd to have fixes like this in a patch > series that almost entirely consists of introducing new stuff. As you can see from the dates, this code was written over time, one top of adding already existing code. Merging patches randomly into giant jumbo patches will make it completely impossible to bisect and debug in case one of these changes breaks something in the parts of the code that was working prior to introducing this set. So no, this is not at all odd, it's perfectly normal for this type of code. Jes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
