archive mirror
 help / color / mirror / Atom feed
From: Arnd Bergmann <>
To: "Michael S. Tsirkin" <>
Cc: Kevin Cernekee <>,
	Ralf Baechle <>,
	Paul Mundt <>,
	Jesse Barnes <>,
	Myron Stowe <>,
	Paul Gortmaker <>,
	Lucas De Marchi <>,
	Dmitry Kasatkin <>,
	James Morris <>,
	"John W. Linville" <>,
	Michael Witten <>,,,,
Subject: Re: [PATCH 0/3] arch: fix ioport mapping on mips,sh
Date: Mon, 30 Jan 2012 16:09:55 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Monday 30 January 2012, Michael S. Tsirkin wrote:
> Kevin Cernekee reported that recent cleanup
> that replaced pci_iomap with a generic function
> failed to take into account the differences
> in io port handling on mips and sh architectures.
> Rather than revert the changes reintroducing the
> code duplication, this patchset fixes this
> by adding ability for architectures to override
> ioport mapping for pci devices.
> I put this in my tree that feeds into linux-next
> and intend to ask Linus to pull this fix if this
> doesn't cause any issues and there are no objections.
> The patches were tested on x86 and compiled on mips and sh.
> Would appreciate reviews/acks/testing reports.

Looks good to me, except for the one detail I've commented
on in the third patch.

Acked-by: Arnd Bergmann <>

I do wonder if the sh and mips implementations are robust enough however
(independent of your work): It seems that an ioport number is treated
differently in pci_iomap than it is using ioport_map and inb/outb,
the assumption being that the port number is a local index per PCI domain.
This would mean that any port access other than pci_iomap would only
work on the primary PCI domain. There are two IMHO better solutions that
I've seen on other architectures:

1. create a larger (e.g. 1MB) io port mapping range in virtual memory
that is split into 64kb per domain, and use the domain number to
find the per domain range when setting the resources. Port numbers will
be larger than 65535 this way, but PCI will ignore the upper address
bits for any access so it works fine.

2. split the 64kb io port range into subsections per domain (on page
granularity, e.g. 2 domains with 32kb or at most 16 domains with 4kb)
and map them virtually contiguous, then reassign all io port resources
so that only the correct region for each domain is used.


      parent reply	other threads:[~2012-01-30 16:10 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-30 12:18 [PATCH 0/3] arch: fix ioport mapping on mips,sh Michael S. Tsirkin
2012-01-30 12:18 ` [PATCH 1/3] lib: add NO_GENERIC_PCI_IOPORT_MAP Michael S. Tsirkin
2012-01-30 14:19   ` Shane McDonald
2012-01-30 14:25     ` Michael S. Tsirkin
2012-01-30 15:51   ` Arnd Bergmann
2012-01-30 16:18     ` Michael S. Tsirkin
2012-01-30 20:04       ` Arnd Bergmann
2012-01-31  0:22         ` Michael S. Tsirkin
2012-01-31 15:59           ` Arnd Bergmann
2012-01-31 21:18         ` Michael S. Tsirkin
2012-01-30 12:18 ` [PATCH 2/3] mips: use the the PCI controller's io_map_base Michael S. Tsirkin
2012-01-30 17:49   ` Sergei Shtylyov
2012-01-30 12:19 ` [PATCH 3/3] sh: use the the PCI channels's io_map_base Michael S. Tsirkin
2012-01-30 17:50   ` Sergei Shtylyov
2012-01-30 16:09 ` Arnd Bergmann [this message]

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* 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).