[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20111122095845.GC31064@arm.com>
Date: Tue, 22 Nov 2011 09:58:45 +0000
From: Catalin Marinas <catalin.marinas@....com>
To: Russell King <rmk@....linux.org.uk>
Cc: Stephen Rothwell <sfr@...b.auug.org.au>,
"linux-next@...r.kernel.org" <linux-next@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Nicolas Pitre <nicolas.pitre@...aro.org>
Subject: Re: linux-next: manual merge of the arm-lpae tree with the arm tree
On Tue, Nov 22, 2011 at 08:13:17AM +0000, Russell King wrote:
> On Tue, Nov 22, 2011 at 12:03:58PM +1100, Stephen Rothwell wrote:
> > diff --cc arch/arm/mm/ioremap.c
> > index 12c7ad2,d1f78ba..0000000
> > --- a/arch/arm/mm/ioremap.c
> > +++ b/arch/arm/mm/ioremap.c
> > @@@ -194,7 -208,14 +202,8 @@@ void __iomem * __arm_ioremap_pfn_caller
> > */
> > if (pfn >= 0x100000 && (__pfn_to_phys(pfn) & ~SUPERSECTION_MASK))
> > return NULL;
> > + #endif
> >
> > - /*
> > - * Don't allow RAM to be mapped - this causes problems with ARMv6+
> > - */
> > - if (WARN_ON(pfn_valid(pfn)))
> > - return NULL;
> > -
>
> This certainly is not correct - if Catalin's lpae tree is removing this
> then that needs to be fixed.
No, my patch just adds the #endif. The combined diff above means that
WARN_ON line above is only found in my version of ioremap.c (as my patch
doesn't touch that line). The "if (WARN_ON))" block was removed in the
"generic ioremap optimisation" patch and Stephen also removed it in the
resulting ioremap.c after fixing the conflict.
--
Catalin
--
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