linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: linux@prisktech.co.nz (Tony Prisk)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv4 0/9] *** ARM: Update arch-vt8500 to Devicetree ***
Date: Fri, 24 Aug 2012 19:18:12 +1200	[thread overview]
Message-ID: <1345792692.23550.3.camel@gitbox> (raw)
In-Reply-To: <CABjd4Yxxf5XDc6gs0WABZgF3SOd89J7CfjsU9uitOg4qpQ4WEQ@mail.gmail.com>

On Fri, 2012-08-24 at 09:54 +0400, Alexey Charkov wrote:
> 2012/8/24 Tony Prisk <linux@prisktech.co.nz>:
> > 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
> 
Actually - that doesn't resolve the problem unless it all goes in via
the same tree still because the clock patch can only drop the #define if
the arch-vt8500 patch exists still - same as problem #2 I mentioned.

If the clock patch goes via Mikes tree he will need the arch-vt8500
patch as well - don't think it can be avoided.

Still easier to send the whole lot via arm-soc, then at least we can
resolve the patch conflicts without having to apply the patches twice.

Regards
Tony P

  parent reply	other threads:[~2012-08-24  7:18 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-23  7:35 [PATCHv4 0/9] *** ARM: Update arch-vt8500 to Devicetree *** Tony Prisk
2012-08-23  7:35 ` [PATCHv4 1/9] arm: vt8500: Add device tree files for VIA/Wondermedia SoC's Tony Prisk
2012-08-23  7:35 ` [PATCHv4 2/9] rtc: vt8500: Add devicetree support for vt8500-rtc Tony Prisk
2012-08-23  7:35 ` [PATCHv4 3/9] serial: vt8500: Add devicetree support for vt8500-serial Tony Prisk
2012-08-23 10:53   ` Alan Cox
2012-08-23  7:35 ` [PATCHv4 4/9] usb: vt8500: Add devicetree support for vt8500-ehci and -uhci Tony Prisk
2012-08-23  7:35 ` [PATCHv4 5/9] video: vt8500: Add devicetree support for vt8500-fb and wm8505-fb Tony Prisk
2012-08-23  7:35 ` [PATCHv4 6/9] arm: vt8500: Update arch-vt8500 to devicetree support Tony Prisk
2012-08-23  7:35 ` [PATCHv4 7/9] arm: vt8500: doc: Add device tree bindings for arch-vt8500 devices Tony Prisk
2012-09-20 23:13   ` Rob Herring
2012-08-23  7:35 ` [PATCHv4 8/9] arm: vt8500: gpio: Devicetree support for arch-vt8500 Tony Prisk
2012-08-23 13:31   ` [rtc-linux] " Linus Walleij
2012-08-23  7:35 ` [PATCHv4 9/9] arm: vt8500: clk: Add Common Clock Framework support Tony Prisk
2012-08-23 10:40 ` [PATCHv4 0/9] *** ARM: Update arch-vt8500 to Devicetree *** Arnd Bergmann
2012-08-23 12:58   ` Tony Prisk
2012-08-23 13:22     ` Arnd Bergmann
2012-08-23 21:48       ` Tony Prisk
2012-08-24  5:40         ` Arnd Bergmann
2012-08-24  5:52           ` Tony Prisk
2012-08-24  5:54             ` Alexey Charkov
2012-08-24  7:14               ` Tony Prisk
2012-08-24  7:18               ` Tony Prisk [this message]
2012-08-23 13:34     ` [rtc-linux] " Linus Walleij
2012-08-25  3:32 ` Stephen Warren

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1345792692.23550.3.camel@gitbox \
    --to=linux@prisktech.co.nz \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).