[lkml]   [2006]   [Feb]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 0/4] PCI legacy I/O port free driver (take 3)
    Jeff Garzik wrote:
    > Kenji Kaneshige wrote:
    >>Here is an updated set of patches for PCI legacy I/O port free drivers
    >>which incorporates feedbacks. Summary of changes from the previous
    >>version are:
    >> - Removed the device_flags field from struct pci_device_id, which
    >> was introduced in the previous version of patch
    >> - Changed e1000 driver to use the driver_data field in struct
    >> pci_device_id to see if the device needs I/O port regions.
    >> - Added proper messages instead of WARN_ON() at the error.
    >> - Updated the Documentation/pci.txt
    >>I'm attaching the following four patches:
    >> [patch 1/4] Add no_ioport flag into pci_dev
    >> [patch 2/4] Update Documentation/pci.txt
    >> [patch 3/4] Make Intel e1000 driver legacy I/O port free
    >> [patch 4/4] Make Emulex lpfc driver legacy I/O port free
    >>I'm attaching the brief description below about what the problem I'm
    >>trying to solve is.
    >>Kenji Kaneshige
    >>Brief Description
    >>I encountered a problem that some PCI devices don't work on my system
    >>which have huge number of PCI devices.
    >>It is mandatory for all PCI device drivers to enable the device by
    >>calling pci_enable_device() which enables all regions probed from the
    >>device's BARs. If pci_enable_device() failes to enable any regions
    >>probed from BARs, it returns as error. On the large servers, I/O port
    >>resource could not be assigned to all PCI devices because it is
    >>limited (64KB on Intel Architecture[1]) and it would be fragmented
    >>(I/O base register of PCI-to-PCI bridge will usually be aligned to a
    >>4KB boundary[2]). In this case, the devices which have no I/O port
    >>resource assigned don't work because pci_enable_device() for those
    >>devices failes. This is what happened on my machine.
    > This series still leaves a lot to be desired, and creates unnecessary
    > driver churn. The better solution is:
    > 1) pci_enable_device() enables what it can

    I guess your idea is changing pci_enable_device() not to return as error
    even if it fails to enable some regions. Is it correct? If yes, we need
    to change all architecture dependent code (e.g. pcibios_enable_device())
    to do that, and it would need much bigger change.

    > 2) Drivers, as they already do, will fail if they cannot map the desired
    > memory or IO resources that are needed.
    > Thus, the PCI layer needs only to do #1, and existing driver code
    > handles the rest of the situation as one currently expects.

    Many driver uses pci_request_regions() instead of calling pci_request_region()
    for each region. That is, we need to consider the same problem at
    pci_request_regions() time. Converting drivers to use pci_request_region()
    instead of pci_request_regions() requires many changes and it would be
    troublesome for driver writers.

    Kenji Kaneshige
    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-02-28 04:04    [W:0.026 / U:6.560 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site