1. 11 Nov, 2005 4 commits
    • rajesh.shah@intel.com's avatar
      [PATCH] pciehp: remove redundant data structures · ca22a5e4
      rajesh.shah@intel.com authored
      State information is currently stored in per-slot as well as
      per-pci-function data structures in pciehp. There's a lot of
      overlap in the information kept, and some of it is never used.
      This patch consolidates the state information to per-slot and
      eliminates unused data structures. The biggest change is to
      eliminate the pci_func structure and the code around managing
      its lists.
      Signed-off-by: default avatarRajesh Shah <rajesh.shah@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      ca22a5e4
    • rajesh.shah@intel.com's avatar
      [PATCH] pciehp: reduce dependence on ACPI · a8a2be94
      rajesh.shah@intel.com authored
      Reduce the PCI Express hotplug driver's dependence on ACPI.
      We don't walk the acpi namespace anymore to build a list of
      bridges and devices. We go to ACPI only to run the _OSC or
      _OSHP methods to transition control of hotplug hardware from
      system BIOS to the hotplug driver, and to run the _HPP
      method to get hotplug device parameters like cache line size,
      latency timer and SERR/PERR enable from BIOS.
      
      Note that one of the side effects of this patch is that pciehp
      does not automatically enable the hot-added device or its DMA
      bus mastering capability now. It expects the device driver to
      do that. This may break some drivers and we will have to fix
      them as they are reported.
      Signed-off-by: default avatarRajesh Shah <rajesh.shah@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      a8a2be94
    • rajesh.shah@intel.com's avatar
      [PATCH] patch 1/8] pciehp: use the PCI core for hotplug resource management · 71b720c0
      rajesh.shah@intel.com authored
      This patch converts the pci express hotplug controller driver
      to use the PCI core for resource management. This eliminates a
      lot of duplicated code and integrates pciehp with the system's
      normal PCI handling code.
      Signed-off-by: default avatarRajesh Shah <rajesh.shah@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      71b720c0
    • Roland Dreier's avatar
      [PATCH] PCI: add pci_find_next_capability() · 24a4e377
      Roland Dreier authored
      Some devices have more than one capability of the same type.  For
      example, the PCI header for the PathScale InfiniPath looks like:
      
      	04:01.0 InfiniBand: Unknown device 1fc1:000d (rev 02)
      		Subsystem: Unknown device 1fc1:000d
      		Flags: bus master, fast devsel, latency 0, IRQ 193
      		Memory at fea00000 (64-bit, non-prefetchable) [size=2M]
      		Capabilities: [c0] HyperTransport: Slave or Primary Interface
      		Capabilities: [f8] HyperTransport: Interrupt Discovery and Configuration
      
      There are _two_ HyperTransport capabilities, and the PathScale driver
      wants to look at both of them.
      
      The current pci_find_capability() API doesn't work for this, since it
      only allows us to get to the first capability of a given type.  The
      patch below introduces a new pci_find_next_capability(), which can be
      used in a loop like
      
      	for (pos = pci_find_capability(pdev, <ID>);
      	     pos;
      	     pos = pci_find_next_capability(pdev, pos, <ID>)) {
      		/* ... */
      	}
      Signed-off-by: default avatarRoland Dreier <rolandd@cisco.com>
      Signed-off-by: default avatarMatthew Wilcox <matthew@wil.cx>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      24a4e377
  2. 10 Nov, 2005 36 commits