[lkml]   [2006]   [Mar]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [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);

    (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 -
    maintainer of: 2.6 Serial core
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-03-02 20:37    [W:0.020 / U:33.708 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site