1. 10 11月, 2012 1 次提交
    • D
      PCI: SRIOV control and status via sysfs · 1789382a
      Donald Dutile 提交于
      Provide files under sysfs to determine the maximum number of VFs
      an SR-IOV-capable PCIe device supports, and methods to enable and
      disable the VFs on a per-device basis.
      
      Currently, VF enablement by SR-IOV-capable PCIe devices is done
      via driver-specific module parameters.  If not setup in modprobe files,
      it requires admin to unload & reload PF drivers with number of desired
      VFs to enable.  Additionally, the enablement is system wide: all
      devices controlled by the same driver have the same number of VFs
      enabled.  Although the latter is probably desired, there are PCI
      configurations setup by system BIOS that may not enable that to occur.
      
      Two files are created for the PF of PCIe devices with SR-IOV support:
      
          sriov_totalvfs	Contains the maximum number of VFs the device
      			could support as reported by the TotalVFs register
      			in the SR-IOV extended capability.
      
          sriov_numvfs	Contains the number of VFs currently enabled on
      			this device as reported by the NumVFs register in
      			the SR-IOV extended capability.
      
      			Writing zero to this file disables all VFs.
      
      			Writing a positive number to this file enables that
      			number of VFs.
      
      These files are readable for all SR-IOV PF devices.  Writes to the
      sriov_numvfs file are effective only if a driver that supports the
      sriov_configure() method is attached.
      Signed-off-by: NDonald Dutile <ddutile@redhat.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      1789382a
  2. 13 10月, 2012 1 次提交
  3. 12 9月, 2012 1 次提交
  4. 11 9月, 2012 1 次提交
  5. 08 9月, 2012 1 次提交
  6. 23 8月, 2012 6 次提交
  7. 20 8月, 2012 1 次提交
  8. 11 7月, 2012 1 次提交
    • A
      PCI: EHCI: fix crash during suspend on ASUS computers · dbf0e4c7
      Alan Stern 提交于
      Quite a few ASUS computers experience a nasty problem, related to the
      EHCI controllers, when going into system suspend.  It was observed
      that the problem didn't occur if the controllers were not put into the
      D3 power state before starting the suspend, and commit
      151b6128 (USB: EHCI: fix crash during
      suspend on ASUS computers) was created to do this.
      
      It turned out this approach messed up other computers that didn't have
      the problem -- it prevented USB wakeup from working.  Consequently
      commit c2fb8a3f (USB: add
      NO_D3_DURING_SLEEP flag and revert 151b6128) was merged; it
      reverted the earlier commit and added a whitelist of known good board
      names.
      
      Now we know the actual cause of the problem.  Thanks to AceLan Kao for
      tracking it down.
      
      According to him, an engineer at ASUS explained that some of their
      BIOSes contain a bug that was added in an attempt to work around a
      problem in early versions of Windows.  When the computer goes into S3
      suspend, the BIOS tries to verify that the EHCI controllers were first
      quiesced by the OS.  Nothing's wrong with this, but the BIOS does it
      by checking that the PCI COMMAND registers contain 0 without checking
      the controllers' power state.  If the register isn't 0, the BIOS
      assumes the controller needs to be quiesced and tries to do so.  This
      involves making various MMIO accesses to the controller, which don't
      work very well if the controller is already in D3.  The end result is
      a system hang or memory corruption.
      
      Since the value in the PCI COMMAND register doesn't matter once the
      controller has been suspended, and since the value will be restored
      anyway when the controller is resumed, we can work around the BIOS bug
      simply by setting the register to 0 during system suspend.  This patch
      (as1590) does so and also reverts the second commit mentioned above,
      which is now unnecessary.
      
      In theory we could do this for every PCI device.  However to avoid
      introducing new problems, the patch restricts itself to EHCI host
      controllers.
      
      Finally the affected systems can suspend with USB wakeup working
      properly.
      
      Reference: https://bugzilla.kernel.org/show_bug.cgi?id=37632
      Reference: https://bugzilla.kernel.org/show_bug.cgi?id=42728Based-on-patch-by: NAceLan Kao <acelan.kao@canonical.com>
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Tested-by: NDâniel Fraga <fragabr@gmail.com>
      Tested-by: NJavier Marcet <jmarcet@gmail.com>
      Tested-by: NAndrey Rahmatullin <wrar@wrar.name>
      Tested-by: NOleksij Rempel <bug-track@fisher-privat.net>
      Tested-by: NPavel Pisa <pisa@cmp.felk.cvut.cz>
      Cc: stable <stable@vger.kernel.org>
      Acked-by: NBjorn Helgaas <bhelgaas@google.com>
      Acked-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dbf0e4c7
  9. 10 7月, 2012 1 次提交
    • B
      PCI: reimplement P2P bridge 1K I/O windows (Intel P64H2) · 2b28ae19
      Bjorn Helgaas 提交于
      9d265124 and 15a260d5 added quirks for P2P bridges that support
      I/O windows that start/end at 1K boundaries, not just the 4K boundaries
      defined by the PCI spec.  For details, see the IOBL_ADR register and the
      EN1K bit in the CNF register in the Intel 82870P2 (P64H2).
      
      These quirks complicate the code that reads P2P bridge windows
      (pci_read_bridge_io() and pci_cfg_fake_ranges()) because the bridge
      I/O resource is updated in the HEADER quirk, in pci_read_bridge_io(),
      in pci_setup_bridge(), and again in the FINAL quirk.  This is confusing
      and makes it impossible to reassign the bridge windows after FINAL
      quirks are run.
      
      This patch adds support for 1K windows in the generic paths, so the
      HEADER quirk only has to enable this support.  The FINAL quirk, which
      used to undo damage done by pci_setup_bridge(), is no longer needed.
      
      This removes "if (!res->start) res->start = ..." from pci_read_bridge_io();
      that was part of 9d265124 to avoid overwriting the resource filled in
      by the quirk.  Since pci_read_bridge_io() itself now knows about
      granularity, the quirk no longer updates the resource and this test is no
      longer needed.
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      2b28ae19
  10. 26 6月, 2012 1 次提交
  11. 24 6月, 2012 1 次提交
    • H
      PCI/PM: add PCIe runtime D3cold support · 448bd857
      Huang Ying 提交于
      This patch adds runtime D3cold support and corresponding ACPI platform
      support.  This patch only enables runtime D3cold support; it does not
      enable D3cold support during system suspend/hibernate.
      
      D3cold is the deepest power saving state for a PCIe device, where its main
      power is removed.  While it is in D3cold, you can't access the device at
      all, not even its configuration space (which is still accessible in D3hot).
      Therefore the PCI PM registers can not be used to transition into/out of
      the D3cold state; that must be done by platform logic such as ACPI _PR3.
      
      To support wakeup from D3cold, a system may provide auxiliary power, which
      allows a device to request wakeup using a Beacon or the sideband WAKE#
      signal.  WAKE# is usually connected to platform logic such as ACPI GPE.
      This is quite different from other power saving states, where devices
      request wakeup via a PME message on the PCIe link.
      
      Some devices, such as those in plug-in slots, have no direct platform
      logic.  For example, there is usually no ACPI _PR3 for them.  D3cold
      support for these devices can be done via the PCIe Downstream Port leading
      to the device.  When the PCIe port is powered on/off, the device is powered
      on/off too.  Wakeup events from the device will be notified to the
      corresponding PCIe port.
      
      For more information about PCIe D3cold and corresponding ACPI support,
      please refer to:
      
      - PCI Express Base Specification Revision 2.0
      - Advanced Configuration and Power Interface Specification Revision 5.0
      
      [bhelgaas: changelog]
      Reviewed-by: NRafael J. Wysocki <rjw@sisk.pl>
      Originally-by: NZheng Yan <zheng.z.yan@intel.com>
      Signed-off-by: NHuang Ying <ying.huang@intel.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      448bd857
  12. 17 6月, 2012 1 次提交
  13. 14 6月, 2012 5 次提交
  14. 12 6月, 2012 6 次提交
  15. 21 5月, 2012 1 次提交
  16. 01 5月, 2012 2 次提交
  17. 20 3月, 2012 1 次提交
  18. 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
  19. 28 2月, 2012 3 次提交
  20. 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
  21. 24 2月, 2012 3 次提交
    • B
      PCI: add generic pcibios_resource_to_bus() · 36a66cd6
      Bjorn Helgaas 提交于
      This replaces the generic versions of pcibios_resource_to_bus() and
      pcibios_bus_to_resource() in asm-generic/pci.h with versions that use
      pci_resource_to_bus() and pci_bus_to_resource().
      
      The replacements are equivalent except that they can apply host
      bridge window offsets when the arch has supplied them by using
      pci_add_resource_offset().
      
      Each arch can convert to using pci_add_resource_offset() individually by
      removing its device resource fixups from pcibios_fixup_bus() and supplying
      ARCH_HAS_GENERIC_PCI_OFFSETS.  ARCH_HAS_GENERIC_PCI_OFFSETS can be removed
      after all have converted.
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      36a66cd6
    • B
      PCI: add struct pci_host_bridge_window with CPU/bus address offset · 0efd5aab
      Bjorn Helgaas 提交于
      Some PCI host bridges apply an address offset, so bus addresses on PCI are
      different from CPU addresses.  This patch adds a way for architectures to
      tell the PCI core about this offset.  For example:
      
          LIST_HEAD(resources);
          pci_add_resource_offset(&resources, host->io_space, host->io_offset);
          pci_add_resource_offset(&resources, host->mem_space, host->mem_offset);
          pci_scan_root_bus(parent, bus, ops, sysdata, &resources);
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      0efd5aab
    • B
      PCI: add struct pci_host_bridge and a list of all bridges found · 5a21d70d
      Bjorn Helgaas 提交于
      This adds a list of all PCI host bridges we find and a way to look up
      the host bridge from a pci_dev.
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      5a21d70d