Globally defining phys_addr_t
Subsystems (2)
cover Globally defining phys_addr_t
Hi Ingo,
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.
The third patch in the series is not necessary to fix any bug, but it removes the separate definition of resource_size_t to define it in terms of phys_addr_t. I include it for competeness.
Thanks,
J
Quoted 7 lines · Jeremy Fitzhardinge
Hi Ingo,
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_tto make it kernel-wide rather than x86-specific, and fixes upPFN_PHYS()to use it to avoid address truncation.
Quoted 6 lines
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_twith the same meaning as x86; the powerpc arch maintainers are happy with these patches.
Andrew, are you fine with that approach too?
Also, i dont see Andrew's signoffs in the patches, and that's the true path of these patches which should be preserved: you => -mm => -tip.
Ingo
Quoted 10 lines · On Thu, 11 Sep 2008 11:53:11 +0200 Ingo Molnar <[email protected]> wrote:
Quoted 7 lines · Jeremy Fitzhardinge
Hi Ingo,
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_tto make it kernel-wide rather than x86-specific, and fixes upPFN_PHYS()to use it to avoid address truncation.
Quoted 8 lines
Quoted 6 lines
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_twith the same meaning as x86; the powerpc arch maintainers are happy with these patches.Andrew, are you fine with that approach too?
spose so. These patches are the same as those in -mm (I checked).
Still seems a bit odd to me that we're disallowing things like 32-bit reosurces on >4G-memory-span machines. A resource_size_t is a different (and narrower) concept from a physical address.
Quoted 2 lines
Also, i dont see Andrew's signoffs in the patches, and that's the true path of these patches which should be preserved: you => -mm => -tip.
Not really. These went
JF -> mm
and
JF -> you
but whatever.
Quoted 11 lines · Andrew Morton
Quoted 3 lines
Also, i dont see Andrew's signoffs in the patches, and that's the true path of these patches which should be preserved: you => -mm => -tip.
Not really. These went
JF -> mm
and
JF -> you
yeah - it was just a small detail: i generally try to preserve the testing (and review) track record of patches. So since they've been in -mm for some time, ideally that fact should be preserved.
Ingo
Quoted 20 lines · Andrew Morton
Quoted 17 lines · On Thu, 11 Sep 2008 11:53:11 +0200 Ingo Molnar <[email protected]> wrote:
Quoted 14 lines · Jeremy Fitzhardinge
Hi Ingo,
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_tto make it kernel-wide rather than x86-specific, and fixes upPFN_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_twith the same meaning as x86; the powerpc arch maintainers are happy with these patches.
Quoted 9 lines
Quoted 2 lines
Andrew, are you fine with that approach too?
spose so. These patches are the same as those in -mm (I checked).
Still seems a bit odd to me that we're disallowing things like 32-bit reosurces on >4G-memory-span machines. A
resource_size_tis a different (and narrower) concept from a physical address.
I don't mind much either way. I added that patch on suggestion from BenH, and don't really mind if it gets dropped. The first two are the really important ones.
Quoted 6 lines
Quoted 3 lines
Also, i dont see Andrew's signoffs in the patches, and that's the true path of these patches which should be preserved: you => -mm => -tip.
Not really. These went
Quoted 8 lines
JF -> mm
and
JF -> you
but whatever.
Yes, I just resent the same patches. But getting the ones blessed with -mm pee would be the best.
J
Quoted 11 lines · Jeremy Fitzhardinge
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_tto make it kernel-wide rather than x86-specific, and fixes upPFN_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_twith 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.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Quoted 6 lines · Geert Uytterhoeven
Quoted 3 lines
PowerPC also defines a
phys_addr_twith 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.
Nothing turns up in a grep over arch/mips and include/asm-mips.
J
Quoted 4 lines · Jeremy Fitzhardinge
Quoted 2 lines
If I'm not mistaking, this is also true for some MIPS machines.
Nothing turns up in a grep over
arch/mipsandinclude/asm-mips.
It's called phys_t for MIPS. It's time to make it consistent probably.
Maciej
Quoted 6 lines · Geert Uytterhoeven
Quoted 5 lines · Jeremy Fitzhardinge
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_tto make it kernel-wide rather than x86-specific, and fixes upPFN_PHYS()to use it to avoid address truncation.
Quoted 8 lines
Quoted 6 lines
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_twith 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