Messages in this thread |  | | | Subject | Re: [PATCH] fix ppc ioremap prototype | | From | (Eric W. Biederman) | | Date | 05 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/
|  |