[PATCH 1/3] ARM: CSR: Adding CSR SiRFprimaII board support

[Nicolas Pitre]

On Fri, 8 Jul 2011, Russell King - ARM Linux wrote:

> On Fri, Jul 08, 2011 at 09:38:56AM -0400, Nicolas Pitre wrote:
> > On Fri, 8 Jul 2011, Russell King - ARM Linux wrote:
> > 
> > > On Fri, Jul 08, 2011 at 10:18:57AM +0800, Barry Song wrote:
> > > > simply adding a UL suffix will make compiling fail since
> > > > arch/arm/kernel/debug.S will refer to the macro calculating virtual
> > > > address of SIRFSOC_UART1_VA_BASE and UL is not legal in asm.
> > > 
> > > A solution for VMALLOC_END would be to include linux/const.h and use
> > > _AC(value, UL).  I think you're the only one who bases their IO
> > > addressing off VMALLOC_END.
> > 
> > This is also a bad idea to use VMALLOC_END like that since this is 
> > another per-architecture constant which is targetted for a global 
> > removal.
> 
> Let's get the story straight and avoid confusion...
> 
> Using _AC(value, UL) is not a bad idea, nor is adding UL as a suffix for
> VMALLOC_END. 

Absolutely.

> Basing IO addresses off VMALLOC_END is questionable, but we have to 
> have some value for this.

Exact.  I just wouldn't want to see VMALLOC_END even more entangled into 
SOC specific mappings.

> Rather than trying to convert everything to a variable, I think some
> effort needs to be spent trying to keep this as a constant.  We've
> grown too much to have lots of variances in the kernel memory layout
> and we really should be trying to standardize on this stuff.

Indeed.  The VMALLOC_END case is possibly different as we were trying to 
find a way to adjust it automatically at run time which would be one 
thing less for platforms to care about.  Having a globally fixed value 
for it would also solve the multiple definition problem.  But some 
machines have a large set of IO mappings while some others have a 
small one, so having a one size fits all solution here might be 
suboptimal.


Nicolas