public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: Roel Kluin <12o3l@tiscali.nl>
To: linux-ia64@vger.kernel.org
Subject: Re: [PATCH] iounmap after ioremap in efi_enter_virtual_mode, file
Date: Mon, 05 Nov 2007 08:45:27 +0000	[thread overview]
Message-ID: <472ED827.6010801@tiscali.nl> (raw)
In-Reply-To: <472D0486.8080604@tiscali.nl>

Simon Horman wrote:
> On Sun, Nov 04, 2007 at 12:30:14AM +0100, Roel Kluin wrote:
>> I am less certain about this one, so please review
>> --
>> Iounmap when EFI won't switch to virtual mode
>>

> 
> Hi Roel,
> 
> I'm not really sure what the intention of this patch is.
> But I'm pretty sure its not doing what you want it to do.
> 
> I guess that you wish to reverse all the calls to ioremap()
> that are made in efi_enter_virtual_mode(). ioremap() is
> called during iterating through efi_map_start, but you only
> seem to call iounmap on whatever md happens to be set
> to at the end of the iteration. Surely you need to run through
> efi_map_start again?

Yes, you are right, this was what I had in mind:
--
 	if (status != EFI_SUCCESS) {
+                for (p = efi_map_start; p < efi_map_end; p += efi_desc_size) {
+			md = p;
+			if ((md->attribute & EFI_MEMORY_RUNTIME) &&
+			    (md->attribute & EFI_MEMORY_UC) ||
+			    (md->attribute & EFI_MEMORY_WC))
+				iounmap(md->virt_addr);
+		}
 		printk(KERN_WARNING "warning: unable to switch EFI into virtual mode "
 		       "(status=%lu)\n", status);
 		return;
---

> The next thing that I wonder about is weather calling iounmap()
> actually reverses ioremap() in this case. Though now that I look
> at it and see that basically iounmap() will do nothing in
> this case, which seems appropriate as in this case ioremap()
> ends up being:
> 
>    return (void __iomem *) (__IA64_UNCACHED_OFFSET | phys_addr)
> 
> Its probably not to much of a bother that all the md->virt_addr have
> been mangled and stay mangled. Though if we are concerned about such
> things, perhaps it would be cleaner to zero them on error?
> 

Like this?

---
 	if (status != EFI_SUCCESS) {
+                for (p = efi_map_start; p < efi_map_end; p += efi_desc_size) {
+			md = p;
+			if ((md->attribute & EFI_MEMORY_RUNTIME) &&
+			    (md->attribute & EFI_MEMORY_UC) ||
+			    (md->attribute & EFI_MEMORY_WC))
+				md->virt_addr = 0;
+		}
 		printk(KERN_WARNING "warning: unable to switch EFI into virtual mode "
 		       "(status=%lu)\n", status);
 		return;
---

I fear the remainder of your review is beyond my scope. My field of
expertise is biomedical sciences :)

Roel

  parent reply	other threads:[~2007-11-05  8:45 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-03 23:30 [PATCH] iounmap after ioremap in efi_enter_virtual_mode, file arch/ia64/kernel/efi.c Roel Kluin
2007-11-05  2:03 ` Simon Horman
2007-11-05  8:45 ` Roel Kluin [this message]
2007-11-14 22:00 ` Simon Horman

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=472ED827.6010801@tiscali.nl \
    --to=12o3l@tiscali.nl \
    --cc=linux-ia64@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