From: "Tolentino, Matthew E" <matthew.e.tolentino@intel.com>
To: <davidm@hpl.hp.com>
Cc: "Grover, Andrew" <andrew.grover@intel.com>,
<linux-ia64@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH] remove pa->va->pa conversion for efi.acpi
Date: Thu, 17 Jul 2003 10:43:19 -0700 [thread overview]
Message-ID: <D36CE1FCEFD3524B81CA12C6FE5BCAB002FFE548@fmsmsx406.fm.intel.com> (raw)
David,
> I'm OK with the change in principle, but the patch as sent is
> unacceptable because it leaves "acpi" and "acpi20" declared
> as "void *"
> (in struct efi"). If you want them to by physical addresses, this
> should be changed to "unsigned long" (or perhaps u32 for acpi and u64
> for acpi20?). It would be good to rename the members as well (e.g.,
> acpi_phys_addr/acpi20_phys_addr) to make sure that old code will
> break at compile-time, not at run-time.
Sounds good. I've changed these to unsigned long and added the phys_addr to the names...
> Does ACPI really guarantee that the table is never stored at physical
> address 0? If not, then leaving it as a virtual address might be
> safer. (Yes, I know it's very unlikely for today's system, but at
> least on ia64, pfn 0 is normal RAM so it seems at least in principle
> possible to store the ACPI table there).
>
No guarantee that I could find...I suppose this is technically possible. :) However, considering the ACPI routines expect a physical address and thus immediately map it to get the descriptor (either directly with virt_to_phys or via ioremap), this seems redundant. Given the mapping scheme employed, is this still risky? I'd like to reuse the same code path for ia32, but don't want to break ia64.
thanks,
matt
next reply other threads:[~2003-07-17 17:28 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-07-17 17:43 Tolentino, Matthew E [this message]
2003-07-17 18:09 ` [PATCH] remove pa->va->pa conversion for efi.acpi David Mosberger
-- strict thread matches above, loose matches on Subject: below --
2003-07-17 18:42 Tolentino, Matthew E
2003-07-12 2:00 Matt Tolentino
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=D36CE1FCEFD3524B81CA12C6FE5BCAB002FFE548@fmsmsx406.fm.intel.com \
--to=matthew.e.tolentino@intel.com \
--cc=andrew.grover@intel.com \
--cc=davidm@hpl.hp.com \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).