On Mon, Dec 05, 2011 at 10:23:17AM -0800, Grant Grundler wrote: > On Sun, Dec 4, 2011 at 6:30 AM, Michael S. Tsirkin <mst@xxxxxxxxxx> wrote: > ... > > AFAIK, on PCI a resource is either IO or MEM, but never both. > > What am I missing? > > Yes, a particular PCI BAR (Base Address Register) is either IO or MEM > (not both) address space resource. > > James is observing many older devices have the same set of registers > mapped in both address spaces using two BARs. As you already know, > MMIO is "lighter weight" (CPU cost to generate transactions on PCI > bus). I think this is orthogonal to the issue you are addressing. > > Regarding handling of IO Port space cookies: > > - if (flags & IORESOURCE_IO) > > - return ioport_map(start, len); > > I don't know who all the consumers of pci_iomap() are. If user space > can somehow call this, it should fail for IO port space "mappings" > since unlike x86, parisc has no INB/OUTB instructions. Generating IO > Port space requires frobbing PCI Bus controller registers that I don't > think we want to expose to user space. > > I'm going to assume this is NOT a problem since any code that > generates anything that tries to look like an INB/OUTB just won't > compile on parisc. I think removing the parisc specific definition > and using the generic one instead looks fine to me. But I'm not > confident enough to offer a formal ACKed-by line. Sorry. :( > > cheers, > grant How about a Tested-by line? I presume you have the hardware to try this out? You can also get the patches from my tree: git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git linux-next or from linux-next. -- MST -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
