lkml.org 
[lkml]   [2013]   [Jun]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: am335x: TSC & ADC reworking including DT pieces, take 4
    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-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2013-06-11 18:21    [W:4.878 / U:0.148 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site