On 06/11/2013 06:27 PM, Jonathan Cameron wrote: > > > Samuel Ortiz <sa...@linux.intel.com> wrote: > >> Hi Dmitry, >> >> On Tue, Jun 11, 2013 at 09:04:16AM -0700, Dmitry Torokhov wrote: >>> On Tue, Jun 11, 2013 at 04:23:58PM +0200, Samuel Ortiz wrote: >>>> Hi Sebastian, >>>> >>>> On Tue, Jun 11, 2013 at 01:30:46PM +0200, Sebastian Andrzej Siewior >> wrote: >>>>> I believe the whole thing should go via the MFD tree. It touches >> also >>>>> input & iio subsystem. I collected ACKs where I got some in the >> meantime. >>>> Please fix your commit logs, and your subject lines. It should be >> e.g. >>>> mfd: input: ti_am335x_adc: Blablabla >>>> >>>> if it's mostly an mfd patch that also touches an input driver. >>>> >>>> Then, this is a pretty big patchset, with iio, input and mfd all >> mixed >>>> together and it is likely to create merge conflicts. >>>> 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. >>> >>> I purposely left this driver alone as I expected it would be merged >>> through MFD tree, so there should not be any merging issues on my >> side. >> Thanks for the notice. >> Jonathan, can you guarantee the same for the iio parts ? > I have also been avoiding taking any of these and there are unlikely to be > any iio wide changes merging at this stage in cycle. Hence these going > through MFD is best plan. > > Lars raised a couple of issues so would be best to wait for his ack if he > hasn't already looked at this revision.
The IIO bits look fine to me in this version. - Lars -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
