Re: [PATCH 0/4] PCI legacy I/O port free driver (take4)

[Russell King <rmk+lkml@arm.linux.org.uk>]

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/