[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMuHMdU1rHDvZEknNqKLHyBmJ26kH7SJtxsOZmOysrSzg6bz4g@mail.gmail.com>
Date: Wed, 12 Oct 2011 18:15:49 +0200
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Kumar Gala <galak@...nel.crashing.org>
Cc: "Hans J. Koch" <hjk@...sjkoch.de>, gregkh@...e.de,
linuxppc-dev@...abs.org, linux-kernel@...r.kernel.org,
Kai Jiang <Kai.Jiang@...escale.com>
Subject: Re: [PATCH] uio: Support 36-bit physical addresses on 32-bit systems
On Wed, Oct 12, 2011 at 18:07, Kumar Gala <galak@...nel.crashing.org> wrote:
> On Oct 12, 2011, at 10:32 AM, Hans J. Koch wrote:
>> On Wed, Oct 12, 2011 at 09:35:45AM -0500, Kumar Gala wrote:
>>> From: Kai Jiang <Kai.Jiang@...escale.com>
>>>
>>> To support >32-bit physical addresses for UIO_MEM_PHYS type we need to
>>> extend the width of 'addr' in struct uio_mem. Numerous platforms like
>>> embedded PPC, ARM, and X86 have support for systems with larger physical
>>> address than logical.
>>>
>>> Since 'addr' may contain a physical, logical, or virtual address the
>>> easiest solution is to just change the type to 'unsigned long long'
>>> regardless of which type is utilized.
>>
>> No. There's phys_addr_t for that purpose, defined in include/linux/types.h.
>> Please use that.
>
> Do we believe phys_addr_t is always greater than or equal to size need for logical & virtual addresses?
Yes:
#ifdef CONFIG_PHYS_ADDR_T_64BIT
typedef u64 phys_addr_t;
#else
typedef u32 phys_addr_t;
#endif
config PHYS_ADDR_T_64BIT
def_bool 64BIT || ARCH_PHYS_ADDR_T_64BIT
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org
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
--
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