1. 24 10月, 2008 1 次提交
  2. 23 10月, 2008 3 次提交
    • A
      PCI: pciehp: remove 'name' parameter · e1acb24f
      Alex Chiang 提交于
      We do not need to manage our own name parameter, especially since
      the PCI core can change it on our behalf, in the case of duplicate
      slot names.
      
      Remove 'name' from pciehp's version of struct slot, and remove
      unused 'task_list' as well.
      
      Cc: kristen.c.accardi@intel.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>
      e1acb24f
    • A
      PCI: prevent duplicate slot names · 5fe6cc60
      Alex Chiang 提交于
      Prevent callers of pci_create_slot() from registering slots with
      duplicate names. This condition occurs most often when PCI hotplug
      drivers are loaded on platforms with broken firmware that assigns
      identical names to multiple slots.
      
      We now rename these duplicate slots 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
      	etc.
      
      This is the permanent fix mentioned in earlier commits d6a9e9b4 and
      167e782e (shpchp/pciehp: Rename duplicate slot name...).
      
      We take advantage of the new 'hotplug' parameter in pci_create_slot()
      to prevent a slot create/rename race between hotplug drivers and
      detection drivers.
      
      	Scenario A:
      	hotplug driver                  detection driver
      	--------------                  ----------------
      	pci_create_slot(hotplug=set)
      					pci_create_slot(hotplug=NULL)
      
      The hotplug driver creates the slot with its desired name, and then
      releases the semaphore. Now, the detection driver tries to create
      the same slot, but it already exists. We don't care about renaming,
      so return the existing slot.
      
      	Scenario B:
      	hotplug driver                  detection driver
      	--------------                  ----------------
      					pci_create_slot(hotplug=NULL)
      	pci_create_slot(hotplug=set)
      
      The detection driver creates the slot with name "X". Then the hotplug
      driver tries to create the same slot, but wants the name "Y" instead.
      We detect that we're trying to create the same slot and that we also
      want a rename, so rename the slot to "Y" and return.
      
      	Scenario C:
      	hotplug driver                  hotplug driver
      	--------------                  ----------------
      	pci_create_slot(hotplug=set)
      					pci_create_slot(hotplug=set)
      
      Two separate hotplug drivers are attempting to claim the slot and
      are passing valid hotplug_slot args to pci_create_slot(). We detect
      that the slot already has a ->hotplug callback, prevent a rename,
      and return -EBUSY.
      
      Cc: kristen.c.accardi@intel.com
      Cc: matthew@wil.cx
      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>
      5fe6cc60
    • A
      PCI Hotplug core: add 'name' param pci_hp_register interface · 1359f270
      Alex Chiang 提交于
      Update pci_hp_register() to take a const char *name parameter.
      
      The motivation for this is to clean up the individual hotplug
      drivers so that each one does not have to manage its own name.
      The PCI core should be the place where we manage the name.
      
      We update the interface and all callsites first, in a
      "no functional change" manner, and clean up the drivers later.
      
      Cc: kristen.c.accardi@intel.com
      Acked-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Reviewed-by: NMatthew Wilcox <willy@linux.intel.com>
      Signed-off-by: NAlex Chiang <achiang@hp.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      1359f270
  3. 21 10月, 2008 2 次提交
  4. 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
  5. 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
  6. 11 6月, 2008 4 次提交
  7. 28 5月, 2008 1 次提交
  8. 26 4月, 2008 2 次提交
  9. 21 4月, 2008 1 次提交
  10. 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
  11. 02 2月, 2008 4 次提交
  12. 13 10月, 2007 2 次提交
  13. 03 5月, 2007 3 次提交
  14. 08 2月, 2007 7 次提交
  15. 02 12月, 2006 1 次提交
  16. 19 10月, 2006 1 次提交
  17. 20 6月, 2006 1 次提交
  18. 24 3月, 2006 2 次提交
  19. 10 1月, 2006 1 次提交