From: Ralf Baechle <ralf@linux-mips.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
Ingo Molnar <mingo@elte.hu>, Alex Nixon <alex.nixon@citrix.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux/MIPS Development <linux-mips@linux-mips.org>,
Jeff Dike <jdike@addtoit.com>,
user-mode-linux-devel@lists.sourceforge.net
Subject: Re: [PATCH 0/3] Globally defining phys_addr_t
Date: Thu, 11 Sep 2008 13:50:09 +0200 [thread overview]
Message-ID: <20080911115009.GA6715@linux-mips.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0809111202560.1545@anakin>
On Thu, Sep 11, 2008 at 12:03:36PM +0200, Geert Uytterhoeven wrote:
> On Thu, 11 Sep 2008, Jeremy Fitzhardinge wrote:
> > This is a repost of a little 3-patch series which Andrew has been
> > carrying in -mm. It cleans up the definition of phys_addr_t to make it
> > kernel-wide rather than x86-specific, and fixes up PFN_PHYS() to use it
> > to avoid address truncation.
> >
> > We currently have a few workarounds for this problem in the tree, but
> > Alex found another bug caused by PFN_PHYS(), so it's probably better if
> > you bring these patches into tip.git for now.
> >
> > PowerPC also defines a phys_addr_t with the same meaning as x86; the
> > powerpc arch maintainers are happy with these patches.
>
> If I'm not mistaking, this is also true for some MIPS machines.
Jeremy probably missed it because it's called phys_t on MIPS. It's usually
the same size as unsigned long but a few of the 32-bit Alchemy SOCs have
peripherals placed outside of the 32-bit physical address space so for
those CONFIG_64BIT_PHYS_ADDR will be defined and phys_t be unsigned long
long and used for some pagetable stuff to map those devices into the 32-bit
virtual address space.
UM uses a phys_t for its pagetables.
A single data type for everybody is enough. phys_addr_t or phys_t I don't
care; I went for phys_t because it's shorter, less to type.
Ralf
WARNING: multiple messages have this Message-ID (diff)
From: Ralf Baechle <ralf@linux-mips.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Linux/MIPS Development <linux-mips@linux-mips.org>,
Jeremy Fitzhardinge <jeremy@goop.org>,
user-mode-linux-devel@lists.sourceforge.net,
Jeff Dike <jdike@addtoit.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Alex Nixon <alex.nixon@citrix.com>, Ingo Molnar <mingo@elte.hu>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [uml-devel] [PATCH 0/3] Globally defining phys_addr_t
Date: Thu, 11 Sep 2008 13:50:09 +0200 [thread overview]
Message-ID: <20080911115009.GA6715@linux-mips.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0809111202560.1545@anakin>
On Thu, Sep 11, 2008 at 12:03:36PM +0200, Geert Uytterhoeven wrote:
> On Thu, 11 Sep 2008, Jeremy Fitzhardinge wrote:
> > This is a repost of a little 3-patch series which Andrew has been
> > carrying in -mm. It cleans up the definition of phys_addr_t to make it
> > kernel-wide rather than x86-specific, and fixes up PFN_PHYS() to use it
> > to avoid address truncation.
> >
> > We currently have a few workarounds for this problem in the tree, but
> > Alex found another bug caused by PFN_PHYS(), so it's probably better if
> > you bring these patches into tip.git for now.
> >
> > PowerPC also defines a phys_addr_t with the same meaning as x86; the
> > powerpc arch maintainers are happy with these patches.
>
> If I'm not mistaking, this is also true for some MIPS machines.
Jeremy probably missed it because it's called phys_t on MIPS. It's usually
the same size as unsigned long but a few of the 32-bit Alchemy SOCs have
peripherals placed outside of the 32-bit physical address space so for
those CONFIG_64BIT_PHYS_ADDR will be defined and phys_t be unsigned long
long and used for some pagetable stuff to map those devices into the 32-bit
virtual address space.
UM uses a phys_t for its pagetables.
A single data type for everybody is enough. phys_addr_t or phys_t I don't
care; I went for phys_t because it's shorter, less to type.
Ralf
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
next prev parent reply other threads:[~2008-09-15 7:29 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-11 8:31 [PATCH 0/3] Globally defining phys_addr_t Jeremy Fitzhardinge
2008-09-11 9:53 ` Ingo Molnar
2008-09-11 10:20 ` Andrew Morton
2008-09-11 11:56 ` Ingo Molnar
2008-09-11 16:08 ` Jeremy Fitzhardinge
2008-09-11 10:03 ` Geert Uytterhoeven
2008-09-11 11:50 ` Ralf Baechle [this message]
2008-09-11 11:50 ` [uml-devel] " Ralf Baechle
2008-09-11 16:06 ` Jeremy Fitzhardinge
2008-09-11 16:17 ` Maciej W. Rozycki
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=20080911115009.GA6715@linux-mips.org \
--to=ralf@linux-mips.org \
--cc=akpm@linux-foundation.org \
--cc=alex.nixon@citrix.com \
--cc=geert@linux-m68k.org \
--cc=jdike@addtoit.com \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=mingo@elte.hu \
--cc=user-mode-linux-devel@lists.sourceforge.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.