1. 22 8月, 2008 1 次提交
    • A
      PCI: pciehp: Rename duplicate slot name N as N-1, N-2, N-M... · 167e782e
      Alex Chiang 提交于
      Commit 3800345f (pciehp: fix slot name)
      introduces the pciehp_slot_with_bus module parameter, which was intended
      to help work around broken firmware that assigns the same name to multiple
      slots.
      
      Commit 9e4f2e8d (pciehp: add message about
      pciehp_slot_with_bus option) tells the user to use the above parameter
      in the event of a name collision.
      
      This approach is sub-optimal because it requires too much work from
      the user.
      
      Instead, let's rename the slot on behalf of the user. If firmware
      assigns the name N to multiple slots, then:
      
      	The first registered slot is assigned N
      	The second registered slot is assigned N-1
      	The third registered slot is assigned N-2
      	The Mth registered slot becomes N-M
      
      In the event we overflow the slot->name parameter, we report an
      error to the user.
      
      This is a temporary fix until the entire PCI core can be reworked
      such that individual drivers no longer have to manage their own
      slot names.
      Tested-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Acked-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Signed-off-by: NAlex Chiang <achiang@hp.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      167e782e
  2. 28 6月, 2008 2 次提交
    • K
      pciehp: use get_service_data · b9708940
      Kenji Kaneshige 提交于
      Current pciehp driver saves its private data pointer into pci_dev
      structure using pci_set_drvdata()/pci_get_drvdata(). But because
      pciehp is not a pci device driver but a PCI Express service driver, it
      should save its private data pointer into pcie_device structure using
      set_service_data()/get_service_data().
      Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      b9708940
    • K
      pciehp: fix interrupt initialization · c4635eb0
      Kenji Kaneshige 提交于
      Current pciehp driver's intialization sequence is as follows:
      
      (1) initialize controller data structure
      (2) install interrupt handler
      (3) enable software notification
      (4) initialize controller specific slot data structure
      (5) initialize generic slot data structure and register it to pci hotplug core
      
      The interrupt handler of pciehp assumes that controller specific slot
      data structure is already initialized. However, it is installed at (2)
      before initializing controller specific slot data structure at
      (4). Because of this, pciehp driver cannot handle the following cases
      properly.
      
      - If devices that shares IRQ with pciehp raise interrupts between (2) and (4).
      - If hotplug events (e.g. MRL open) happen between (3) and (4).
      
      We already have a workaround for this problem ("pciehp: fix NULL
      dereference in interrupt handler: dbd79aed).
      But we still need fundamental fix.
      
      This patch fix the problem by changing the initilization sequence as follows:
      
      (1) initialize controller data structure
      (2) initialize controller specific slot data structure
      (3) install interrupt handler
      (4) enable software notification
      (5) initialize generic slot data structure and register it to pci hotplug core
      Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Acked-by: NAlex Chiang <achiang@hp.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      c4635eb0
  3. 11 6月, 2008 4 次提交
  4. 28 5月, 2008 1 次提交
  5. 26 4月, 2008 2 次提交
  6. 21 4月, 2008 1 次提交
  7. 18 3月, 2008 1 次提交
    • M
      pciehp: don't enable slot unless forced · 9e585824
      Mark Lord 提交于
      This fixes a 2.6.25 regression reported by Alex Chiang.
      
      Invoke pciehp_enable_slot() at startup only when pciehp_force=1.
      Some HP equipment apparently cannot cope with it otherwise.
      
      This restores the (previously working) 2.6.24 behaviour here,
      while allowing machines that need a kick to use pciehp_force=1.
      
      This was the original design back in October 2007,
      but Kristen suggested we try without it first:
      
         Kristen Carlson Accardi wrote:
         >I think it would be ok to try allowing the slot to be enabled when not
         >using pciehp_force mode.  We can wrap it later if it proves to break things
      
      This ended up breaking one of Alex's setups,
      so it's time to put the wrapper back in now.
      Signed-off-by: NMark Lord <mlord@pobox.com>
      Acked-by: NAlex Chiang <achiang@hp.com>
      Acked-by: NKristen Carlson Accardi <kristen.c.accardi@intel.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9e585824
  8. 02 2月, 2008 4 次提交
  9. 13 10月, 2007 2 次提交
  10. 03 5月, 2007 3 次提交
  11. 08 2月, 2007 7 次提交
  12. 02 12月, 2006 1 次提交
  13. 19 10月, 2006 1 次提交
  14. 20 6月, 2006 1 次提交
  15. 24 3月, 2006 2 次提交
  16. 10 1月, 2006 2 次提交
  17. 11 11月, 2005 5 次提交
    • 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: remove redundant data structures · ca22a5e4
      rajesh.shah@intel.com 提交于
      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: NRajesh Shah <rajesh.shah@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      ca22a5e4
    • 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