On Mon, 12 Mar 2007, Franck Bui-Huu wrote:
> Date: Mon, 12 Mar 2007 18:05:10 +0100
> From: Franck Bui-Huu <firstname.lastname@example.org>
> To: email@example.com
> Cc: firstname.lastname@example.org
> Subject: Re: [PATCH 0/2] FLATMEM: allow memory to start at pfn != 0 [take
> On 3/12/07, peter fuerst <email@example.com> wrote:
> > You see the problem. Any occurrence of PAGE_OFFSET must be checked.
> yes and whatever the scheme you propose...
> > the kernel-addresses. Moreover it would be desirable, if this macro
> > really could be used throughout the kernel, e.g. by drivers, handling
> > any reasonable kernel-address, which isn't possible in the page_offset
> > scheme anyway.
> Can you explain why the current use of pa() failed to handle all
> kernel address with a real example ?
Simply, when you convert between cached (kseg0, ckseg0, several xkphys-
regions) and uncached (kseg1, ckseg1, several xkphys-regions) addresses
and the other way round, you need the physical address as an intermediate
value and __pa() or virt_to_phys() can support only one direction.
Of course a scheme, that supports all unmapped spaces (kseg0/1, ckseg0/1,
xkphys) simultaneously, or even xkphys alone, can't support TLB-mapped
spaces (kseg3, ckseg3, ..., xkseg) - at which your patch seems to aim -
and vice versa.
> A few people reported that they had problem with KPHYS/CKSEG0 address
> mix for 64 bit kernels but as far I can see it was due to a miss
> configuration of their kernels. Of course I canbe wrong but these
Hmm, i don't remember actually mis-configured kernels, but allright,
have to skim the eMail-archive again.
> people haven't given any feedbacks so far...