From: Darren Hart <dvhart@infradead.org>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Wim Van Sebroeck <wim@iguana.be>,
Linux-Next Mailing List <linux-next@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Kuppuswamy Sathyanarayanan
<sathyanarayanan.kuppuswamy@linux.intel.com>
Subject: Re: linux-next: manual merge of the drivers-x86 tree with the watchdog tree
Date: Tue, 2 May 2017 13:21:59 -0700 [thread overview]
Message-ID: <20170502202159.GC26866@fury> (raw)
In-Reply-To: <20170502191217.GA11901@roeck-us.net>
On Tue, May 02, 2017 at 12:12:17PM -0700, Guenter Roeck wrote:
> On Tue, May 02, 2017 at 11:09:40AM -0700, Darren Hart wrote:
> > On Tue, May 02, 2017 at 02:04:03PM +1000, Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > Today's linux-next merge of the drivers-x86 tree got a conflict in:
> > >
> > > drivers/watchdog/iTCO_wdt.c
> > >
> > > between commit:
> > >
> > > 38a700fa1df9 ("watchdog: iTCO_wdt: cleanup set/unset no_reboot_bit functions")
> > > (which also appears in the drivers-x86 tree as commit f583a884afec)
> > >
> >
> > Andy and Guenter, I presume the two of you discussed how this patch would get
> > submitted as I see the following in the platform driver x86 for-next branch:
> >
> > Acked-by: Guenter Roeck <linux@roeck-us.net>
> > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> >
> > for both:
> >
> > 140c91b2 watchdog: iTCO_wdt: Add PMC specific noreboot update api
> > f583a88 watchdog: iTCO_wdt: cleanup set/unset no_reboot_bit functions
> >
>
> I did not expect f583a88/38a700fa1df9 to show up in some other tree, sorry.
> I don't recall discussing how to handle it either, though my memory may defeat
> me. If so, my apologies.
>
> > This suggests these were deliberately added to our tree and not accidentally
> > included through a rebase without --preserve-merges or something like that.
> >
> > Guenter, if you prefer/need to submit this through your tree, can you provide
> > us with an immutable branch to merge for the dependencies of our later patches?
> > If you can drop these two patches without a dependency problem in your tree,
> > that would be the cleanest solution as we could avoid an additional merge.
> >
>
> Please check with Wim.
Thanks Guenter.
Wim, for context, this was a 6 patch series, with 4 patches to the platform
driver x86 tree and 2patches to the watchdog tree. The series was reviewed by
Guenter and Andy, and in v7 Andy replied that he had pushed the series to
testing (the testing branch of the platform driver x86 tree).
https://lkml.org/lkml/2017/4/25/666
>From my perspective, the most direct solution would be to drop these two patches
from the watchdog tree and let them go through the platform driver x86 tree with
Guenter's Acked-by. If you have additional patches which depend on these two,
then if you will provide an immutable branch we can merge, we can do that too
(but I try to keep the number of external merges to a minimum - which is
becoming increasingly difficult lately for some reason).
Thanks,
--
Darren Hart
VMware Open Source Technology Center
next prev parent reply other threads:[~2017-05-02 20:22 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-02 4:04 linux-next: manual merge of the drivers-x86 tree with the watchdog tree Stephen Rothwell
2017-05-02 18:09 ` Darren Hart
2017-05-02 19:12 ` Guenter Roeck
2017-05-02 20:21 ` Darren Hart [this message]
2017-05-02 20:57 ` Andy Shevchenko
2017-05-02 21:30 ` Darren Hart
2017-05-02 21:58 ` Guenter Roeck
2017-05-02 22:35 ` Darren Hart
2017-05-03 14:24 ` Wim Van Sebroeck
2017-05-03 14:43 ` Andy Shevchenko
-- strict thread matches above, loose matches on Subject: below --
2019-03-04 3:37 Stephen Rothwell
2019-03-07 5:27 ` Darren Hart
2019-03-07 5:42 ` Darren Hart
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=20170502202159.GC26866@fury \
--to=dvhart@infradead.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=sfr@canb.auug.org.au \
--cc=wim@iguana.be \
/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).