Hi Sebastian, On Tue, Jun 11, 2013 at 05:29:22PM +0200, Sebastian Andrzej Siewior wrote: > > Then, this is a pretty big patchset, with iio, input and mfd all mixed > > together and it is likely to create merge conflicts. > They somehow depend on each other. Otherwise I would have sent three > series, one per subsystem. Of course they depend on each other, but the dependency is mostly for iio and input to depend on the MFD changes. > >>From what I can see from it, and please correct me if I'm > > wrong, the iio and input changes depend on the mfd ones, and not the > > other way around. If that's so, I'm going to ask you to reshuffle your > > patch set and separate the MFD changes from the iio and input ones. I'll > > take the MFD ones and will create an immutable branch for Jonathan and > > Dmitry to pull from and apply the iio and input changes on top of it. > > Merge conflicts should be mostly avoided that way. > > AFAICT, only patch #2 should be kept with input and iio bits mixed > > together with MFD as otherwise this would introduce functional breakage. > > Otherwise, all MFD bits from the other patches could be either separated > > or merged together (e.g. MFD bits from patches #6 and #8, and #16 and > > #17). > > > > Does that sound doable to you ? > > The device renaming shouldn't matter since I added DT nodes for the mfd > child devices earlier. But then the of_compatible assignments should > go hand in hand. However if I split this then the driver won't work > but then it does not now as well (because there is no platform_data > provider in tree). > > Still. There is #18 which reworks the "step addressing" and involves > changes in both (iio & input) at the same time. Would splitting iio and input break anything there ? > There is #21. Adding this to the initial "DT support" patch would be bad > I think because it requires some changes on the iio side which have > nothing to do with DT. Putting the iio changes before DT would require > to make some change to platform-data part which will go away anyway. Wouldn't it workif you split this one into an MFD+dts file changes and another one for the iio changes ? > So I started collecting ACKs from input and iio to avoid this split. If > you really want the split then I will start doing so… I think it would be nicer, yes. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
