linux-mips
[Top] [All Lists]

Re: [PATCH 0/2] FLATMEM: allow memory to start at pfn != 0 [take #2]

To: post@pfrst.de
Subject: Re: [PATCH 0/2] FLATMEM: allow memory to start at pfn != 0 [take #2]
From: "Franck Bui-Huu" <vagabon.xyz@gmail.com>
Date: Mon, 12 Mar 2007 18:05:10 +0100
Cc: linux-mips@linux-mips.org
Dkim-signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=O4O2brhiLC0JqrnEjkQFuQv+ccdNehNlA/gzsR/sQJL4jiiMmu9cll+lGOwKqr1n2kAfkm//mE/WNXEoOeiBJw/HdX62YU/aU90Xf4xb8gt7eLD7hPIomvH0fzcS6ynDOsom5jvr7Urlo2+lBYNy+a1pm5kcydZ0Dpk42+Dqm1Q=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=BjaiZWBZilZkGQl1QX/kOotn08viVn1w+eWOyi+TEkTsUV8K1AqduoTq6/0XlNgx/Xu8EEVeHv6wJcoEBKZp+tAhPQYhR2/MvBP3Wg75kv5Dk3940ceUE1UqZ290g9qk0KfaK2ABipGVOjFjpPmHGy+JNoMAIrZg9etn++wMBnw=
In-reply-to: <Pine.LNX.4.58.0703121329450.440@Indigo2.Peter>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <116841864595-git-send-email-fbuihuu@gmail.com> <Pine.LNX.4.58.0703101034500.19007@Indigo2.Peter> <cda58cb80703120247q435b6bb1p8a025d8597aca2a2@mail.gmail.com> <Pine.LNX.4.58.0703121329450.440@Indigo2.Peter>
Sender: linux-mips-bounce@linux-mips.org
On 3/12/07, peter fuerst <post@pfrst.de> 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 ?

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 can be wrong but these
people haven't given any feedbacks so far...

Thanks
--
              Franck

<Prev in Thread] Current Thread [Next in Thread>