All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.