1. 23 4月, 2013 1 次提交
  2. 31 1月, 2013 2 次提交
  3. 26 1月, 2013 1 次提交
    • Y
      PCI: Skip attaching driver in device_add() · 58d9a38f
      Yinghai Lu 提交于
      We want to add PCI devices to the device tree as early as possible but
      delay attaching drivers.
      
      device_add() adds a device to the device hierarchy and (via
      device_attach()) attaches a matching driver and calls its .probe() method.
      We want to separate adding the device to the hierarchy from attaching the
      driver.
      
      This patch does that by adding "match_driver" in struct pci_dev.  When
      false, we return failure from pci_bus_match(), which makes device_attach()
      believe there's no matching driver.
      
      Later, we set "match_driver = true" and call device_attach() again, which
      now attaches the driver and calls its .probe() method.
      
      [bhelgaas: changelog, explicitly init dev->match_driver,
      fold device_attach() call into pci_bus_add_device()]
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      58d9a38f
  4. 25 1月, 2013 1 次提交
  5. 14 1月, 2013 1 次提交
    • R
      ACPI / PCI: Set root bridge ACPI handle in advance · 6c0cc950
      Rafael J. Wysocki 提交于
      The ACPI handles of PCI root bridges need to be known to
      acpi_bind_one(), so that it can create the appropriate
      "firmware_node" and "physical_node" files for them, but currently
      the way it gets to know those handles is not exactly straightforward
      (to put it lightly).
      
      This is how it works, roughly:
      
        1. acpi_bus_scan() finds the handle of a PCI root bridge,
           creates a struct acpi_device object for it and passes that
           object to acpi_pci_root_add().
      
        2. acpi_pci_root_add() creates a struct acpi_pci_root object,
           populates its "device" field with its argument's address
           (device->handle is the ACPI handle found in step 1).
      
        3. The struct acpi_pci_root object created in step 2 is passed
           to pci_acpi_scan_root() and used to get resources that are
           passed to pci_create_root_bus().
      
        4. pci_create_root_bus() creates a struct pci_host_bridge object
           and passes its "dev" member to device_register().
      
        5. platform_notify(), which for systems with ACPI is set to
           acpi_platform_notify(), is called.
      
      So far, so good.  Now it starts to be "interesting".
      
        6. acpi_find_bridge_device() is used to find the ACPI handle of
           the given device (which is the PCI root bridge) and executes
           acpi_pci_find_root_bridge(), among other things, for the
           given device object.
      
        7. acpi_pci_find_root_bridge() uses the name (sic!) of the given
           device object to extract the segment and bus numbers of the PCI
           root bridge and passes them to acpi_get_pci_rootbridge_handle().
      
        8. acpi_get_pci_rootbridge_handle() browses the list of ACPI PCI
           root bridges and finds the one that matches the given segment
           and bus numbers.  Its handle is then used to initialize the
           ACPI handle of the PCI root bridge's device object by
           acpi_bind_one().  However, this is *exactly* the ACPI handle we
           started with in step 1.
      
      Needless to say, this is quite embarassing, but it may be avoided
      thanks to commit f3fd0c8a (ACPI: Allow ACPI handles of devices to be
      initialized in advance), which makes it possible to initialize the
      ACPI handle of a device before passing it to device_register().
      
      Accordingly, add a new __weak routine, pcibios_root_bridge_prepare(),
      defaulting to an empty implementation that can be replaced by the
      interested architecutres (x86 and ia64 at the moment) with functions
      that will set the root bridge's ACPI handle before its dev member is
      passed to device_register().  Make both x86 and ia64 provide such
      implementations of pcibios_root_bridge_prepare() and remove
      acpi_pci_find_root_bridge() and acpi_get_pci_rootbridge_handle() that
      aren't necessary any more.
      
      Included is a fix for breakage on systems with non-ACPI PCI host
      bridges from Bjorn Helgaas.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      6c0cc950
  6. 08 1月, 2013 1 次提交
  7. 11 12月, 2012 1 次提交
  8. 06 12月, 2012 2 次提交
  9. 29 11月, 2012 2 次提交
  10. 27 11月, 2012 1 次提交
    • V
      PCI/AER: Report success only when every device has AER-aware driver · 918b4053
      Vijay Mohan Pandarathil 提交于
      When an error is detected on a PCIe device which does not have an
      AER-aware driver, prevent AER infrastructure from reporting
      successful error recovery.
      
      This is because the report_error_detected() function that gets
      called in the first phase of recovery process allows forward
      progress even when the driver for the device does not have AER
      capabilities. It seems that all callbacks (in pci_error_handlers
      structure) registered by drivers that gets called during error
      recovery are not mandatory. So the intention of the infrastructure
      design seems to be to allow forward progress even when a specific
      callback has not been registered by a driver. However, if error
      handler structure itself has not been registered, it doesn't make
      sense to allow forward progress.
      
      As a result of the current design, in the case of a single device
      having an AER-unaware driver or in the case of any function in a
      multi-function card having an AER-unaware driver, a successful
      recovery is reported.
      
      Typical scenario this happens is when a PCI device is detached
      from a KVM host and the pci-stub driver on the host claims the
      device. The pci-stub driver does not have error handling capabilities
      but the AER infrastructure still reports that the device recovered
      successfully.
      
      The changes proposed here leaves the device(s)in an unrecovered state
      if the driver for the device or for any device in the subtree
      does not have error handler structure registered. This reflects
      the true state of the device and prevents any partial recovery (or no
      recovery at all) reported as successful.
      
      [bhelgaas: changelog]
      Signed-off-by: NVijay Mohan Pandarathil <vijaymohan.pandarathil@hp.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: NLinas Vepstas <linasvepstas@gmail.com>
      Reviewed-by: NMyron Stowe <myron.stowe@redhat.com>
      918b4053
  11. 15 11月, 2012 1 次提交
  12. 10 11月, 2012 2 次提交
    • D
      PCI: Provide method to reduce the number of total VFs supported · bff73156
      Donald Dutile 提交于
      Some implementations of SRIOV provide a capability structure
      value of TotalVFs that is greater than what the software can support.
      Provide a method to reduce the capability structure reported value
      to the value the driver can support.
      This ensures sysfs reports the current capability of the system,
      hardware and software.
      Example for its use: igb & ixgbe -- report 8 & 64 as TotalVFs,
      but drivers only support 7 & 63 maximum.
      Signed-off-by: NDonald Dutile <ddutile@redhat.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      bff73156
    • 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
  13. 08 11月, 2012 1 次提交
  14. 04 11月, 2012 1 次提交
  15. 31 10月, 2012 1 次提交
  16. 13 10月, 2012 1 次提交
  17. 12 9月, 2012 1 次提交
  18. 11 9月, 2012 1 次提交
  19. 08 9月, 2012 1 次提交
  20. 23 8月, 2012 6 次提交
  21. 20 8月, 2012 1 次提交
  22. 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
  23. 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
  24. 26 6月, 2012 1 次提交
  25. 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
  26. 17 6月, 2012 1 次提交
  27. 14 6月, 2012 5 次提交