1. 14 6月, 2012 2 次提交
  2. 21 5月, 2012 1 次提交
  3. 01 5月, 2012 2 次提交
  4. 20 3月, 2012 1 次提交
  5. 09 3月, 2012 1 次提交
    • G
      powerpc/eeh: Introduce EEH device · eb740b5f
      Gavin Shan 提交于
      Original EEH implementation depends on struct pci_dn heavily. However,
      EEH shouldn't depend on that actually because EEH needn't share much
      information with other PCI components. That's to say, EEH should have
      worked independently.
      
      The patch introduces struct eeh_dev so that EEH core components needn't
      be working based on struct pci_dn in future. Also, struct pci_dn, struct
      eeh_dev instances are created in dynamic fasion and the binding with EEH
      device, OF node, PCI device is implemented as well.
      
      The EEH devices are created after PHBs are detected and initialized, but
      PCI emunation hasn't started yet. Apart from that, PHB might be created
      dynamically through DLPAR component and the EEH devices should be creatd
      as well. Another case might be OF node is created dynamically by DR
      (Dynamic Reconfiguration), which has been defined by PAPR. For those OF
      nodes created by DR, EEH devices should be also created accordingly. The
      binding between EEH device and OF node is done while the EEH device is
      initially created.
      
      The binding between EEH device and PCI device should be done after PCI
      emunation is done. Besides, PCI hotplug also needs the binding so that
      the EEH devices could be traced from the newly coming PCI buses or PCI
      devices.
      Signed-off-by: NGavin Shan <shangw@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      eb740b5f
  6. 28 2月, 2012 3 次提交
  7. 25 2月, 2012 1 次提交
    • Y
      PCI: Add class support in quirk handling · f4ca5c6a
      Yinghai Lu 提交于
      Recently added support to allow quirks to report duration also make the
      boot log very crowded when initcall_debug is specified.
      
      One thing we can to do mitigate this is to not call quirks unnecessarily
      by adding a new quirk declaration macro that takes a class argument.
      
      The new macro takes a class value and a class shift value (since it can
      vary) so that quirks will be limited to certain device classes, greatly
      reducing the number we call on every PCI device addition.
      
      -v2: fix v1 that left over of sparated patch.
      -v3: according to Jesse, change cls to class, cls_shift, to class_shift.
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      f4ca5c6a
  8. 24 2月, 2012 4 次提交
  9. 15 2月, 2012 5 次提交
  10. 10 2月, 2012 1 次提交
  11. 13 1月, 2012 1 次提交
    • K
      pci: Introduce __pci_reset_function_locked to be used when holding device_lock. · a96d627a
      Konrad Rzeszutek Wilk 提交于
      The use case of this is when a driver wants to call FLR when a device
      is attached to it using the SysFS "bind" or "unbind" functionality.
      
      The call chain when a user does "bind" looks as so:
      
       echo "0000:01.07.0" > /sys/bus/pci/drivers/XXXX/bind
      
      and ends up calling:
        driver_bind:
          device_lock(dev);  <=== TAKES LOCK
          XXXX_probe:
               .. pci_enable_device()
               ...__pci_reset_function(), which calls
                       pci_dev_reset(dev, 0):
                              if (!0) {
                                      device_lock(dev) <==== DEADLOCK
      
      The __pci_reset_function_locked function allows the the drivers
      'probe' function to call the "pci_reset_function" while still holding
      the driver mutex lock.
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      a96d627a
  12. 07 1月, 2012 12 次提交
  13. 06 12月, 2011 1 次提交
  14. 01 11月, 2011 1 次提交
  15. 15 10月, 2011 2 次提交
    • R
      PCI / PM: Extend PME polling to all PCI devices · 379021d5
      Rafael J. Wysocki 提交于
      The land of PCI power management is a land of sorrow and ugliness,
      especially in the area of signaling events by devices.  There are
      devices that set their PME Status bits, but don't really bother
      to send a PME message or assert PME#.  There are hardware vendors
      who don't connect PME# lines to the system core logic (they know
      who they are).  There are PCI Express Root Ports that don't bother
      to trigger interrupts when they receive PME messages from the devices
      below.  There are ACPI BIOSes that forget to provide _PRW methods for
      devices capable of signaling wakeup.  Finally, there are BIOSes that
      do provide _PRW methods for such devices, but then don't bother to
      call Notify() for those devices from the corresponding _Lxx/_Exx
      GPE-handling methods.  In all of these cases the kernel doesn't have
      a chance to receive a proper notification that it should wake up a
      device, so devices stay in low-power states forever.  Worse yet, in
      some cases they continuously send PME Messages that are silently
      ignored, because the kernel simply doesn't know that it should clear
      the device's PME Status bit.
      
      This problem was first observed for "parallel" (non-Express) PCI
      devices on add-on cards and Matthew Garrett addressed it by adding
      code that polls PME Status bits of such devices, if they are enabled
      to signal PME, to the kernel.  Recently, however, it has turned out
      that PCI Express devices are also affected by this issue and that it
      is not limited to add-on devices, so it seems necessary to extend
      the PME polling to all PCI devices, including PCI Express and planar
      ones.  Still, it would be wasteful to poll the PME Status bits of
      devices that are known to receive proper PME notifications, so make
      the kernel (1) poll the PME Status bits of all PCI and PCIe devices
      enabled to signal PME and (2) disable the PME Status polling for
      devices for which correct PME notifications are received.
      Tested-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      379021d5
    • B
      PCI: Make pci_setup_bridge() non-static for use by arch code · e2444273
      Benjamin Herrenschmidt 提交于
      The "powernv" platform of the powerpc architecture needs to assign PCI
      resources using a specific algorithm to fit some HW constraints of
      the IBM "IODA" architecture (related to the ability to create error
      handling domains that encompass specific segments of MMIO space).
      
      For doing so, it wants to call pci_setup_bridge() from architecture
      specific resource management in order to configure bridges after all
      resources have been assigned. So make it non-static.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      e2444273
  16. 05 10月, 2011 1 次提交
  17. 24 9月, 2011 1 次提交