From: Arnd Bergmann <arnd@arndb.de>
To: Mark Salter <msalter@redhat.com>
Cc: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org
Subject: Re: generic page.h problem
Date: Wed, 23 Mar 2011 20:53:40 +0100 [thread overview]
Message-ID: <201103232053.40057.arnd@arndb.de> (raw)
In-Reply-To: <1300907573.15255.224.camel@deneb.localdomain>
On Wednesday 23 March 2011 20:12:53 Mark Salter wrote:
> I'm working with a new architecture port (nommu) and was wanting to use
> the generic page.h but there is a problem. I'm using CONFIG_FLATMEM with
> a non-zero CONFIG_KERNEL_RAM_BASE_ADDRESS. The hardware uses this same
> address to access RAM from code and for DMA purposes. The generic page.h
> has:
>
> #ifdef CONFIG_KERNEL_RAM_BASE_ADDRESS
> #define PAGE_OFFSET (CONFIG_KERNEL_RAM_BASE_ADDRESS)
> #else
> #define PAGE_OFFSET (0)
> #endif
>
> #ifndef __ASSEMBLY__
>
> #define __va(x) ((void *)((unsigned long)(x) + PAGE_OFFSET))
> #define __pa(x) ((unsigned long) (x) - PAGE_OFFSET)
>
> The problem I have is that __va(x) and __pa(x) should do nothing on
> this architecture. If I use the following, then everything seems to
> work as it should.
>
>
> diff --git a/include/asm-generic/page.h b/include/asm-generic/page.h
> index 75fec18..4dc4a81 100644
> --- a/include/asm-generic/page.h
> +++ b/include/asm-generic/page.h
> @@ -73,8 +73,8 @@ extern unsigned long memory_end;
>
> #ifndef __ASSEMBLY__
>
> -#define __va(x) ((void *)((unsigned long)(x) + PAGE_OFFSET))
> -#define __pa(x) ((unsigned long) (x) - PAGE_OFFSET)
> +#define __va(x) ((void *)((unsigned long) (x)))
> +#define __pa(x) ((unsigned long) (x))
>
> #define virt_to_pfn(kaddr) (__pa(kaddr) >> PAGE_SHIFT)
> #define pfn_to_virt(pfn) __va((pfn) << PAGE_SHIFT)
>
>
> Am I missing something here? The only other arch using the generic
> page.h is blackfin, but it uses a zero PAGE_OFFSET, so my patch
> would have no effect there.
I don't think the handling of nonzero PAGE_OFFSET in asm-generic/page.h
was intentional. When Remis worked on the patch to introduce this file,
the idea was to take the common parts from all related architectures
and come up with a way that works on most of them.
Maybe one of the other arch maintainers has an opinion on this. If
not, I don't mind your patch, just add that to your series when submitting
the architecture for review.
Arnd
prev parent reply other threads:[~2011-03-23 19:53 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-23 19:12 generic page.h problem Mark Salter
2011-03-23 19:19 ` Mike Frysinger
2011-03-23 19:53 ` Arnd Bergmann [this message]
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=201103232053.40057.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=msalter@redhat.com \
/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