08 Jul, 2005

2 commits


07 Jul, 2005

5 commits

  • There is a slight disagreement between setup-bus.c code and traditional
    x86 PCI setup wrt which recourses are invalid vs resources that are free
    for further allocations.

    In particular, in the setup-bus.c, if we failed to allocate some resource,
    we nullify "start" and "flags" fields, but *not* the "end" one.

    But x86 pcibios_enable_resources() does the following check:

    if (!r->start && r->end) {
    printk(KERN_ERR "PCI: Device %s not available because of resource collisions\n", pci_name(dev));
    return -EINVAL;

    which means that the device owning the offending resource cannot be
    enabled.

    In particular, this breaks cardbus behind the normal decode p2p bridge -
    the cardbus code from setup-bus.c requests rather large IO and MEM
    windows, and if it fails, the socket is completely unavailable. Which
    is wrong, as the yenta code is capable to allocate smaller windows.

    Signed-off-by: Ivan Kokshaysky
    Signed-off-by: Linus Torvalds

    Ivan Kokshaysky
     
  • Tony Luck
     
  • This patch is the SGI hotplug driver and additional changes required for
    the driver. These modifications include changes to the SN io_init.c code
    for memory management, the inclusion of new SAL calls to enable and disable
    PCI slots, and a hotplug-style driver.

    Signed-off-by: Prarit Bhargava
    Signed-off-by: Tony Luck

    Prarit Bhargava
     
  • The pci_find_next_bus function is listed as being exported to drivers. It is
    not EXPORT_SYMBOL'd.

    Signed-off-by: Prarit Bhargava
    Signed-off-by: Tony Luck

    Prarit Bhargava
     
  • Here's a patch to fix the build issue when CONFIG_HOTPLUG is not enabled
    in 2.6.13-rc2.

    Signed-off-by: Greg Kroah-Hartman
    Signed-off-by: Linus Torvalds

    Greg KH
     

02 Jul, 2005

9 commits

  • It seems that X86 architectures in general need the setup-bus.o
    not just those with HOTPLUG. This avoids the following error on
    X86_NUMAQ and x86_64:

    arch/i386/pci/built-in.o(.init.text+0x15a6): In function `pcibios_init':
    : undefined reference to `pci_assign_unassigned_resources'

    Signed-off-by: Andy Whitcroft
    Signed-off-by: Andrew Morton
    Signed-off-by: Greg Kroah-Hartman

    Andy Whitcroft
     
  • The buffer arguments have been removed from pci_{save,restore}_state.
    The comment blocks for those functions should reflect that.

    Signed-off-by: John W. Linville
    Signed-off-by: Greg Kroah-Hartman

    John W. Linville
     
  • the pci core sends out a hotplug event variable MODALIAS with a trailing
    newline. This is inconsistent with all other event variables and breaks
    some hotplug tools. This patch removes the said newline.

    Signed-off-by: Greg Kroah-Hartman

    Hannes Reinecke
     
  • This patch, is based on kernel 2.6.12, provides a fix for PCIe
    port bus driver suspend/resume.

    Signed-off-by: T. Long Nguyen
    Signed-off-by: Greg Kroah-Hartman

    long
     
  • One more Asus motherboard requiring the SMBus quirk (P4B-LX). Original
    patch from Salah Coronya.

    Signed-off-by: Salah Coronya
    Signed-off-by: Jean Delvare
    Signed-off-by: Greg Kroah-Hartman

    Jean Delvare
     
  • The dynamic pci id logic has been bothering me for a while, and now that
    I started to look into how to move some of this to the driver core, I
    thought it was time to clean it all up.

    It ends up making the code smaller, and easier to follow, and fixes a
    few bugs at the same time (dynamic ids were not being matched
    everywhere, and so could be missed on some call paths for new devices,
    semaphore not needed to be grabbed when adding a new id and calling the
    driver core, etc.)

    I also renamed the function pci_match_device() to pci_match_id() as
    that's what it really does.

    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     
  • - Add sanity check for io[port,mem]_resource in setup-bus.c. These
    resources look like "free" as they have no parents, but obviously
    we must not touch them.
    - In i386.c:pci_allocate_bus_resources(), if a bridge resource cannot be
    allocated for some reason, then clear its flags. This prevents any child
    allocations in this range, so the setup-bus code will work with a clean
    resource sub-tree.
    - i386.c:pcibios_enable_resources() doesn't enable bridges, as it checks
    only resources 0-5, which looks like a clear bug to me. I suspect it
    might break hotplug as well in some cases.

    From: Ivan Kokshaysky
    Signed-off-by: Greg Kroah-Hartman

    Ivan Kokshaysky
     
  • With the number of PCI bus resources increased to 8, we can
    handle the subtractive decode PCI-PCI bridge like a normal
    bridge, taking into account standard PCI-PCI bridge windows
    (resources 0-2). This helps to avoid problems with peer-to-peer DMA
    behind such bridges, poor performance for MMIO ranges outside bridge
    windows and prefetchable vs. non-prefetchable memory issues.

    To reflect the fact that such bridges do forward all addresses to
    the secondary bus (transparency), remaining bus resources 3-7 are
    linked to resources 0-4 of the primary bus. These resources will be
    used as fallback by resource management code if allocation from
    standard bridge windows fails for some reason.

    Signed-off-by: Ivan Kokshaysky
    Acked-by: Dominik Brodowski
    Signed-off-by: Greg Kroah-Hartman

    Ivan Kokshaysky
     
  • When the cardbus bridge is behind another bridge change the routing
    in the parent bridge for new cards. This fixes Cardbus on various AMD64
    laptops.

    Signed-off-by: Andi Kleen
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     

28 Jun, 2005

15 commits

  • drivers/pci/hotplug/cpqphp_core.c calls cpqphp_event_start_thread()
    in one_time_init(), which is called whenever the hardware is probed.
    Unfortunately, cpqphp_event_stop_thread() is *always* called when
    the module is unloaded. If the hardware is never probed, then
    cpqphp_event_stop_thread() tries to manipulate a couple of
    uninitialized mutexes.

    Signed-off-by: Keith Moore
    Signed-off-by: Greg Kroah-Hartman

    Keith Moore
     
  • Mostly just cleans up the irq handling logic to be smaller and a bit more
    descriptive as to what it really does.

    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     
  • This is an updated version of Ben's fix-pci-mmap-on-ppc-and-ppc64.patch
    which is in 2.6.12-rc4-mm1.

    It fixes the patch to work on PPC iSeries, removes some debug printks
    at Ben's request, and incorporates your
    fix-pci-mmap-on-ppc-and-ppc64-fix.patch also.

    Originally from Benjamin Herrenschmidt

    This patch was discussed at length on linux-pci and so far, the last
    iteration of it didn't raise any comment. It's effect is a nop on
    architecture that don't define the new pci_resource_to_user() callback
    anyway. It allows architecture like ppc who put weird things inside of
    PCI resource structures to convert to some different value for user
    visible ones. It also fixes mmap'ing of IO space on those archs.

    Signed-off-by: Benjamin Herrenschmidt
    Signed-off-by: Michael Ellerman
    Signed-off-by: Andrew Morton
    Signed-off-by: Greg Kroah-Hartman

    Michael Ellerman
     
  • This patch adds PCI based I/O xAPIC hot-add support to ACPIPHP
    driver. When PCI root bridge is hot-added, all PCI based I/O xAPICs
    under the root bridge are hot-added by this patch. Hot-remove support
    is TBD.

    Signed-off-by: Kenji Kaneshige
    Signed-off-by: Andrew Morton
    Signed-off-by: Greg Kroah-Hartman

    Kenji Kaneshige
     
  • Current acpiphp code does not distinguish between the physical presence and
    power state of a device/slot. That is, if a device has to be disabled, it
    also tries to physically ejects the device. This patch decouples power state
    from physical presence. You can now echo to the corresponding sysfs power
    control file to repeatedly enable and disable a device without having to
    physically re-insert it.

    Signed-off-by: Rajesh Shah
    Signed-off-by: Andrew Morton
    Signed-off-by: Greg Kroah-Hartman

    Rajesh Shah
     
  • acpiphp changes to support acpi based root bridge hot-add.

    Signed-off-by: Rajesh Shah
    Signed-off-by: Andrew Morton
    Signed-off-by: Greg Kroah-Hartman

    Rajesh Shah
     
  • Earlier I reported that Matthew's acpiphp rewrite had problem in powering down
    slot on my i386 system. The following patch is needed to get the acpiphp
    rewrite properly powering down the slot.

    Signed-off-by: Dely Sy
    Signed-off-by: Andrew Morton
    Signed-off-by: Greg Kroah-Hartman

    Rajesh Shah
     
  • A root bridge may not have directly attached hotpluggable slots under it.
    Instead, it may have p2p bridges with slots under it. In this case, we need
    to clean up the p2p bridges and slots properly too. Patch below applies on
    top of the original patch, and fixes this problem. Without this, acpiphp
    leaves behind notify handlers on module unload, and subsequent module load
    attempts don't work properly too. Patch was tested on an ia64 Tiger4 box.

    Signed-off-by: Rajesh Shah
    Signed-off-by: Andrew Morton
    Signed-off-by: Greg Kroah-Hartman

    Rajesh Shah
     
  • This patch converts acpiphp to use the generic PCI resource assignment code.
    It's quite large, but most of it is deleting the acpiphp_pci and acpiphp_res
    files. It's tested on an hp Integrity rx8620 (which won't work without this
    patch). Testers with other hardware welcomed.

    Signed-off-by: Matthew Wilcox
    Signed-off-by: Andrew Morton
    Signed-off-by: Greg Kroah-Hartman

    Rajesh Shah
     
  • When hot-plugging an I/O hierarchy that contains many bridges and leaf
    devices, it's possible that there are not enough resources to start all the
    device present. If we fail to assign a resource, clear the corresponding
    value in the pci_dev structure, so other code can take corrective action.

    Signed-off-by: Rajesh Shah
    Signed-off-by: Andrew Morton
    Signed-off-by: Greg Kroah-Hartman

    Rajesh Shah
     
  • When a root bridge hierarchy is hot-plugged, resource requirements for the new
    devices may be greater than what the root bridge is decoding. In this case,
    we want to remove devices that did not get needed resources. These devices
    have been scanned into bus specific lists but not yet added to the global
    device list. Make sure the pci remove functions can handle this case.

    Signed-off-by: Rajesh Shah
    Signed-off-by: Andrew Morton
    Signed-off-by: Greg Kroah-Hartman

    Rajesh Shah
     
  • When a pci child bus is created, add it to the parent's children list
    immediately rather than waiting till pci_bus_add_devices(). For hot-plug
    bridges/devices, pci_bus_add_devices() may be called much later, after they
    have been properly configured. In the meantime, this allows us to use the
    normal pci bus search functions for the hot-plug bridges/buses.

    Signed-off-by: Rajesh Shah
    Signed-off-by: Andrew Morton
    Signed-off-by: Greg Kroah-Hartman

    Rajesh Shah
     
  • With root bridge and pci bridge hot-plug, new buses and devices can be added
    or removed at run time. Protect the pci bus and device lists with the pci
    lock when doing so.

    Signed-off-by: Rajesh Shah
    Signed-off-by: Andrew Morton
    Signed-off-by: Greg Kroah-Hartman

    Rajesh Shah
     
  • When hot-plugging a root bridge, as we try to assign bus numbers we may find
    that the hotplugged hieratchy has more PCI to PCI bridges (i.e. bus
    requirements) than available. Make sure we don't step over an existing bus
    when that happens.

    Signed-off-by: Rajesh Shah
    Signed-off-by: Andrew Morton
    Signed-off-by: Greg Kroah-Hartman

    Rajesh Shah
     
  • When you hot-plug a (root) bridge hierarchy, it may have p2p bridges and
    devices attached to it that have not been configured by firmware. In this
    case, we need to configure the devices before starting them. This patch
    separates device start from device scan so that we can introduce the
    configuration step in the middle.

    I kept the existing semantics for pci_scan_bus() since there are a huge number
    of callers to that function.

    Also, I have no way of testing the changes I made to the parisc files, so this
    needs review by those folks. Sorry for the massive cross-post, this touches
    files in many different places.

    Signed-off-by: Rajesh Shah
    Signed-off-by: Andrew Morton
    Signed-off-by: Greg Kroah-Hartman

    Rajesh Shah
     

21 Jun, 2005

5 commits


19 Jun, 2005

1 commit


18 Jun, 2005

1 commit


14 Jun, 2005

1 commit

  • On 64-bit machines, PCI_BASE_ADDRESS_MEM_MASK and other mask constants
    passed to pci_size() are 64-bit (for example ~0x0fUL). However, pci_size
    does comparisons between the u32 arguments and the mask, which will fail
    even though any result from pci_size is still just 32-bit.

    Changing the mask argument to u32 seems the obvious thing to do, since all
    arithmetic in the function is 32-bit and having a larger mask makes no
    sense.

    This triggered on a PPC64 system here where an adapter (VGA, as it
    happened) had a memory region base of 0xfe000000 and a sz of the same,
    matching the if (max == maxbase ...) test at the bottom of pci_size but
    failing the mask comparison. Quite a corner case which I guess explains
    why we haven't seen it until now.

    Signed-off-by: Olof Johansson
    Acked-by: Greg KH
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Olof Johansson
     

10 Jun, 2005

1 commit

  • MSI functionality is broken on the GC_LE x86 chipset that Serverworks
    developed and that is being used in various platforms today. Broadcom is
    going to push out to the kernel MSI enabled Gigabit drivers (in the very
    near future), and we would like to make sure that MSI does not get
    enabled on any platforms using the GC_LE chipset (device id 0x17).
    Following the AMD 8131 example, I am including a patch to disable MSI
    functionality when a GCNB_LE is detected. Please let me know if there
    are any issues with this. This is a permanent fix for this chipset, as
    the hardware will not be updated.

    Signed-off-by: Narendra Sankar
    Signed-off-by: Greg Kroah-Hartman

    Narendra Sankar