On Fri, 2012-08-24 at 09:54 +0400, Alexey Charkov wrote: > 2012/8/24 Tony Prisk <[email protected]>: > > On Fri, 2012-08-24 at 05:40 +0000, Arnd Bergmann wrote: > >> On Thursday 23 August 2012, Tony Prisk wrote: > >> > I was about to say that if Mike has any issues with the driver that I > >> > can fix the patch conflict at the same time, but I just realised that > >> > its more work than I originally thought :) > >> > > >> > I was going to move the arch-vt8500 part of the clocks patch back into > >> > the clocks patch - but that will just move the issue from arm-soc to > >> > clocks because Mike's branch won't have the arch-vt8500 patch so the > >> > patch will fail. > >> > >> But that's ok, because without the arch-v8500 part, nothing uses > >> the vt8500-clock driver, so nothing breaks. You can introduce broken > >> code in the meantime as long as it's impossible to enable and it will > >> work afterwards. > >> > >> Arnd > > > > You lost me a little bit there :) > > If it stays as is now, the arch-vt8500 patch will introduce an > > unresolved symbol. > > If I move the clock code from the arch-vt8500 patch to the clock patch, > > then the clock patch won't apply because it needs the arch-vt8500 patch > > first and Mike won't have that patch, but it would be fine if both > > patches went in via your tree. > > Why don't you add a #define in the first patch that makes your > to-be-unresolved symbol a no-op and then drop it within the clock > patch? > > Best, > Alexey > I knew we kept you around for a reason :)
Cheers, Tony P _______________________________________________ devicetree-discuss mailing list [email protected] https://lists.ozlabs.org/listinfo/devicetree-discuss
