On 06/11/2013 06:10 PM, Samuel Ortiz wrote:

Hi Sebastian,

Hi Samuel,

On Tue, Jun 11, 2013 at 05:29:22PM +0200, Sebastian Andrzej Siewior wrote:

quoted

quoted

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.

Except for the one #18 as mentioned below.

quoted

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 ?

Yes. Once the header files is modified without the two .c files the
driver is not working. To fix this I need another patch making sure
input + iio does not the header files and another to user it (once
everything is merged).

quoted

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 ?

It would work in general. The first few DT-iio patches wouldn't make
sense but then why not.

quoted

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.

Nicer. I see. Please tell me what you think about #1 because I really
would like to drop regmap and then I can start reshuffle the series :)

Cheers,
Samuel.

Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html