lkml.org 
[lkml]   [2003]   [Sep]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] fix ppc ioremap prototype
From(Eric W. Biederman)
Date05 Sep 2003 02:02:00 -0600
Linus Torvalds <torvalds@osdl.org> writes:

> So clearly ioremap() has to work for other buses too.
>
> I think that in the 2.7.x timeframe, the right thing to do is definitely:
> - move towards using "struct resource" and "ioremap_resource()"
> - make resource sizes potentially be larger (ie use "u64" instead of
> "unsigned long")
>
> This is actually a potential issue already, with 64-bit PCI on regular
> PC's. We don't handle it at all right now (the PCI probing will just not
> create the resources), and nobody has complained, but clearly the
> RightThing(tm) to do eventually is to make sure this all works cleanly.
>
> I just don't think it's worth worrying about in 2.6.x right now, since it
> doesn't matter for anybody.

But it does. There are at least some embedded ppc people who are actually
using 64bit physical addresses with a 32bit virtual address space.

And this has come up in a few other times, as well.

A big question is how much of a problem this will be for later revs of
2.6.x. I would even enable 64bit resources on an Opteron box and not
loose memory if I could be certain a 32bit kernel that people are
using temporarily would work.

So is there any reason to delay making resources a 64bit quantity?

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:48    [from the cache]
©2003-2010