[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130312115339.GF12700@titan.lakedaemon.net>
Date: Tue, 12 Mar 2013 07:53:39 -0400
From: Jason Cooper <jason@...edaemon.net>
To: Olof Johansson <olof@...om.net>
Cc: Andrew Lunn <andrew@...n.ch>,
Stephen Rothwell <sfr@...b.auug.org.au>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
Jingoo Han <jg1.han@...sung.com>,
Arnd Bergmann <arnd@...db.de>,
linux-arm-kernel@...ts.infradead.org
Subject: Re: linux-next: manual merge of the akpm tree with the arm-soc tree
On Tue, Mar 12, 2013 at 04:37:39AM -0700, Olof Johansson wrote:
> On Tue, Mar 12, 2013 at 4:12 AM, Jason Cooper <jason@...edaemon.net> wrote:
> > On Tue, Mar 12, 2013 at 07:25:09AM +0100, Andrew Lunn wrote:
> >> On Tue, Mar 12, 2013 at 02:47:14PM +1100, Stephen Rothwell wrote:
> >> > Hi Andrew,
> >> >
> >> > Today's linux-next merge of the akpm tree got a conflict in
> >> > drivers/rtc/rtc-mv.c between commit 89c58c198b25 ("rtc: rtc-mv: Add
> >> > support for clk to avoid lockups") from the arm-soc tree and commit "rtc:
> >> > rtc-mv: use devm_rtc_device_register()" from the akpm tree.
> >> >
> >> > I fixed it up (I think - see below) and can carry the fix as necessary
> >> > (no action is required).
> >>
> >> Hi Stephan
> >>
> >> Looks O.K. to me.
> >>
> >> Acked-by: Andrew Lunn <andrew@...n.ch>
> >
> > Same here,
> >
> > Acked-by: Jason Cooper <jason@...edaemon.net>
>
> We should make sure that future RTC changes get queued through AKPM
> and not through us to avoid these kind of conflicts. Same as other
> driver subsystems..
I agree, however, this patch is part of a four patch series fixing a
single problem reported by Simon Baatz:
89c58c1 rtc: rtc-mv: Add support for clk to avoid lockups
de88747 gpio: mvebu: Add clk support to prevent lockup
7bf5b40 ARM: kirkwood: fix to retain gbe MAC addresses for DT kernels
93fff4c ARM: kirkwood: of_serial: fix clock gating by removing clock-frequency
Basically, if the user builds a kernel with most everything as modules
(eg copying the debian config), it will fail to boot. All four fixes
are needed together to solve the problem.
I chose to keep them together to maintain bisectability. Either you
have all of the fix (you landed on this branch), or you don't. Was this
the correct decision in this case, or did I miss something?
Also, this series is CC'd to stable for inclusion in v3.8
thx,
Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists