From: David Miller <davem@davemloft.net>
To: ultralinux@vger.kernel.org
Subject: Re: of_ioremap / of_iounmap imbalance
Date: Mon, 18 Dec 2006 09:36:04 +0000 [thread overview]
Message-ID: <20061218.013604.71102386.davem@davemloft.net> (raw)
In-Reply-To: <ec7cefb0612121442m25faf623qf28d1d564dbf5b89@mail.gmail.com>
From: "Eric Brower" <ebrower@gmail.com>
Date: Tue, 12 Dec 2006 14:42:13 -0800
> There's an imbalance in .../arch/sparc64/kernel/of_device.c whereby
> of_ioremap() will intelligently request_region() or
> request_mem_region() as appropriate for the address space, but
> of_iounmap() will always unmap the region as an IO address. This,
> naturally, causes a fair bit of badness.
>
> In my case, I'm dealing with an Ebus device-- I suppose I can assume
> the memory space is already completely mapped, but it would be nice to
> request/release_region for the purposes of bookkeeping.
>
> Can we safely assume of_ioremap will only be used for MEM space
> addresses, and therefore skip the IO space dealing in request_region()
> and perform release_mem_region() in of_iounmap() or is this not
> sufficient?
>
> If not, since our address space context is gone during of_iounmap(),
> would it be wise to follow the lead of PCI regions and embed an "IO
> Space" bit at the bottom of IO region addresses for later querying?
> The read[bwl]/write[bwl] routines would then need to mask off that
> bit...
Thanks a lot Eric, I'll look into this.
I think we'll need to change of_iounmap() to take the struct resource
pointer as a parameter, just like of_ioremap(), in order to fix this
properly.
next prev parent reply other threads:[~2006-12-18 9:36 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-12 22:42 of_ioremap / of_iounmap imbalance Eric Brower
2006-12-18 9:36 ` David Miller [this message]
2006-12-29 0:59 ` David Miller
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=20061218.013604.71102386.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=ultralinux@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 read-only IMAP folder(s) and NNTP newsgroup(s).