[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1393353942.26583.10.camel@deneb.redhat.com>
Date: Tue, 25 Feb 2014 13:45:42 -0500
From: Mark Salter <msalter@...hat.com>
To: Will Deacon <will.deacon@....com>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"x86@...nel.org" <x86@...nel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Arnd Bergmann <arnd@...db.de>, Ingo Molnar <mingo@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
"H. Peter Anvin" <hpa@...or.com>,
Russell King <linux@....linux.org.uk>,
Catalin Marinas <Catalin.Marinas@....com>,
Dave Young <dyoung@...hat.com>,
Rob Herring <robherring2@...il.com>,
Leif Lindholm <leif.lindholm@...aro.org>,
"patches@...aro.org" <patches@...aro.org>
Subject: Re: [PATCH v4 0/6] generic early_ioremap support
On Tue, 2014-02-25 at 18:30 +0000, Will Deacon wrote:
> I'd suggest spitting the core part out from the arch-specific parts. That
> way, the core part can merged independently and architectures can move over
> as they see fit. It also signals (at least to me) that, "hey, I should
> probably review this" whilst my current stance is "there's a whole load of
> stuff under mm/ that needs to be acked first".
>
> If you put the whole thing into next, you just run the risk of conflicts
> with all the arch trees.
I've been thinking of breaking out the common bits and x86 bits and just
going with that for now. There's no point in just doing the common bits
because it won't get tested without at least one architecture using it.
--
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