1. 11 11月, 2005 5 次提交
    • R
      [PATCH] pciehp: fix handling of power faults during hotplug · 8239def1
      rajesh.shah@intel.com 提交于
      The current pciehp implementation reports a power-fail error
      even if the condition has cleared by the time the corresponding
      interrupt handling code gets a chance to run. This patch
      fixes this problem.
      Signed-off-by: NRajesh Shah <rajesh.shah@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      8239def1
    • R
      [PATCH] pciehp: clean-up how we request control of hotplug hardware · a3a45ec8
      rajesh.shah@intel.com 提交于
      This patch further tweaks how we request control of hotplug
      controller hardware from BIOS. We first search the ACPI namespace
      corresponding to a specific hotplug controller looking for an
      _OSC or OSHP method. On failure, we successively move to the
      ACPI parent object, till we hit the highest level host bridge
      in the hierarchy. This allows for different types of BIOS's
      which place the _OSC/OSHP methods at various places in the acpi
      namespace, while still not encroaching on the namespace of
      some other root level host bridge.
      
      This patch also introduces a new load time option (pciehp_force)
      that allows us to bypass all _OSC/OSHP checking. Not supporting
      these methods seems to be be the most common ACPI firmware problem
      we've run into. This will still _not_ allow the pciehp driver to
      work correctly if the BIOS really doesn't support pciehp (i.e. if
      it doesn't generate a hotplug interrupt). Use this option with
      caution.  Some BIOS's may deliberately not build any _OSC/OSHP
      methods to make sure it retains control the hotplug hardware.
      Using the pciehp_force parameter for such systems can lead to
      two separate entities trying to control the same hardware.
      Signed-off-by: NRajesh Shah <rajesh.shah@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      a3a45ec8
    • R
      [PATCH] pciehp: reduce debug message verbosity · 1a9ed1bf
      rajesh.shah@intel.com 提交于
      Reduce the number of debug messages generated if pciehp debug is
      enabled. I tried to restrict this to removing debug messages that
      are either early-driver-debug type messages, or print information
      that can be inferred through other debug prints.
      Signed-off-by: NRajesh Shah <rajesh.shah@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      1a9ed1bf
    • R
      [PATCH] pciehp: miscellaneous cleanups · ed6cbcf2
      rajesh.shah@intel.com 提交于
      Remove un-necessary header includes, remove dead code, remove
      some hardcoded constants...
      Signed-off-by: NRajesh Shah <rajesh.shah@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      ed6cbcf2
    • R
      [PATCH] pciehp: reduce dependence on ACPI · a8a2be94
      rajesh.shah@intel.com 提交于
      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: NRajesh Shah <rajesh.shah@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      a8a2be94
  2. 17 8月, 2005 1 次提交
  3. 18 5月, 2005 1 次提交
  4. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4