Messages in this thread | | | Date | Thu, 2 Mar 2006 19:34:41 +0000 | From | Russell King <> | Subject | Re: [PATCH 0/4] PCI legacy I/O port free driver (take4) |
| |
On Thu, Mar 02, 2006 at 10:24:36AM -0700, Grant Grundler wrote: > On Thu, Mar 02, 2006 at 03:50:57PM +0000, Russell King wrote: > > I've been wondering whether this "no_ioport" flag is the correct approach, > > or whether it's adding to complexity when it isn't really required. > > I think it's the simplest solution to allowing a driver > to indicate which resources it wants to use. It solves > the problem of I/O Port resource allocation sufficiently > well.
I have another question (brought up by someone working on a series of ARM machines which make heavy use of MMIO.)
Why isn't pci_enable_device_bars() sufficient - why do we have to have another interface to say "we don't want BARs XXX" ?
Let's say that we have a device driver which does this sequence (with, of course, error checking):
pci_enable_device_bars(dev, 1<<1); pci_request_regions(dev);
(a) should PCI remember that only BAR 1 has been requested to be enabled, and as such shouldn't pci_request_regions() ignore BAR 0?
(b) should the PCI driver pass into pci_request_regions() (or even pci_request_regions_bars()) a bitmask of the BARs it wants to have requested, and similarly for pci_release_regions().
Basically, if BAR0 hasn't been enabled, has pci_request_regions() got any business requesting it from the resource tree?
-- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |