1. 11 8月, 2015 1 次提交
  2. 19 6月, 2015 1 次提交
  3. 22 5月, 2015 1 次提交
    • R
      PCI: pciehp: Drop pointless ACPI-based "slot detection" check · e705c295
      Rafael J. Wysocki 提交于
      Jarod Wilson reports that ExpressCard hotplug doesn't work on HP ZBook G2.
      The problem turns out to be the ACPI-based "slot detection" code called
      from pciehp_probe() which uses questionable heuristics based on what ACPI
      objects are present for the PCIe port device to figure out whether to
      register a hotplug slot for that port.
      
      That code is used if there is at least one PCIe port having an ACPI device
      configuration object related to hotplug (such as _EJ0 or _RMV), and the
      Thunderbolt port on the ZBook has _RMV.  Of course, Thunderbolt and PCIe
      native hotplug need not be mutually exclusive (as they aren't on the
      ZBook), so that rule is simply incorrect.
      
      Moreover, the ACPI-based "slot detection" check does not add any value if
      pciehp_probe() is called at all and the service type of the device object
      it has been called for is PCIE_PORT_SERVICE_HP, because PCIe hotplug
      services are only registered if the _OSC handshake in acpi_pci_root_add()
      allows the kernel to control the PCIe native hotplug feature.  No more
      checks need to be carried out to decide whether or not to register a native
      PCIe hotlug slot in that case.
      
      For the above reasons, make pciehp_probe() check if it has been called for
      the right service type and drop the pointless ACPI-based "slot detection"
      check from it.  Also remove the entire code whose only user is that check
      (the entire pciehp_acpi.c file goes away as a result) and drop function
      headers related to it from the internal pciehp header file.
      
      Link: http://lkml.kernel.org/r/1431632038-39917-1-git-send-email-jarod@redhat.com
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=98581Reported-by: NJarod Wilson <jarod@redhat.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: NJarod Wilson <jarod@redhat.com>
      Tested-by: NJarod Wilson <jarod@redhat.com>
      e705c295
  4. 13 9月, 2014 1 次提交
  5. 06 7月, 2014 1 次提交
  6. 18 6月, 2014 1 次提交
    • B
      PCI: pciehp: Compute timeout from hotplug command start time · 40b96083
      Bjorn Helgaas 提交于
      If we issue a hotplug command, go do something else, then come back and
      wait for the command to complete, we don't have to wait the whole timeout
      period, because some of it elapsed while we were doing something else.
      
      Keep track of the time we issued the command, and wait only until the
      timeout period from that point has elapsed.
      
      For controllers with errata like Intel CF118, we previously timed out
      before issuing the second hotplug command:
      
        At time T1 (during boot):
          - Write DLLSCE, ABPE, PDCE, etc. to Slot Control
        At time T2 (hotplug event):
          - Wait for command completion (CC) in Slot Status
          - Timeout at T2 + 1 second because CC is never set in Slot Status
          - Write PCC, PIC, etc. to Slot Control
      
      With this change, we wait until T1 + 1 second instead of T2 + 1 second.
      If the hotplug event is more than 1 second after the boot-time
      initialization, we won't wait for the timeout at all.
      
      We still emit a "Timeout on hotplug command" message if it timed out; we
      should see this on the first hotplug event on every controller with this
      erratum, as well as on real errors on controllers without the erratum.
      
      Link: http://www.intel.com/content/www/us/en/processors/xeon/xeon-e7-v2-spec-update.html
      Tested-by: Rajat Jain <rajatxjain@gmail.com>	(IDT 807a controller)
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Acked-by: NYinghai Lu <yinghai@kernel.org>
      40b96083
  7. 17 6月, 2014 1 次提交
  8. 15 4月, 2014 1 次提交
  9. 12 2月, 2014 1 次提交
  10. 11 2月, 2014 2 次提交
  11. 14 1月, 2014 1 次提交
  12. 16 12月, 2013 1 次提交
  13. 07 12月, 2013 1 次提交
    • L
      ACPI: Clean up inclusions of ACPI header files · 8b48463f
      Lv Zheng 提交于
      Replace direct inclusions of <acpi/acpi.h>, <acpi/acpi_bus.h> and
      <acpi/acpi_drivers.h>, which are incorrect, with <linux/acpi.h>
      inclusions and remove some inclusions of those files that aren't
      necessary.
      
      First of all, <acpi/acpi.h>, <acpi/acpi_bus.h> and <acpi/acpi_drivers.h>
      should not be included directly from any files that are built for
      CONFIG_ACPI unset, because that generally leads to build warnings about
      undefined symbols in !CONFIG_ACPI builds.  For CONFIG_ACPI set,
      <linux/acpi.h> includes those files and for CONFIG_ACPI unset it
      provides stub ACPI symbols to be used in that case.
      
      Second, there are ordering dependencies between those files that always
      have to be met.  Namely, it is required that <acpi/acpi_bus.h> be included
      prior to <acpi/acpi_drivers.h> so that the acpi_pci_root declarations the
      latter depends on are always there.  And <acpi/acpi.h> which provides
      basic ACPICA type declarations should always be included prior to any other
      ACPI headers in CONFIG_ACPI builds.  That also is taken care of including
      <linux/acpi.h> as appropriate.
      Signed-off-by: NLv Zheng <lv.zheng@intel.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Acked-by: Bjorn Helgaas <bhelgaas@google.com> (drivers/pci stuff)
      Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> (Xen stuff)
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      8b48463f
  14. 15 11月, 2013 1 次提交
  15. 15 8月, 2013 1 次提交
  16. 18 4月, 2013 1 次提交
  17. 13 1月, 2013 1 次提交
    • Y
      PCI: pciehp: Use per-slot workqueues to avoid deadlock · c2be6f93
      Yijing Wang 提交于
      When we have a hotplug-capable PCIe port with a second hotplug-capable
      PCIe port below it, removing the device below the upstream port causes
      a deadlock.
      
      The deadlock happens because we use the pciehp_wq workqueue to run
      pciehp_power_thread(), which uses pciehp_disable_slot() to remove devices
      below the upstream port.  When we remove the downstream PCIe port, we call
      pciehp_remove(), the pciehp driver's .remove() method.  That calls
      flush_workqueue(pciehp_wq), which deadlocks because the
      pciehp_power_thread() work item is still running.
      
      This patch avoids the deadlock by creating a workqueue for every PCIe port
      and removing the single shared workqueue.
      
      Here's the call path that leads to the deadlock:
      
        pciehp_queue_pushbutton_work
          queue_work(pciehp_wq)                   # queue pciehp_power_thread
          ...
      
        pciehp_power_thread
          pciehp_disable_slot
            remove_board
      	pciehp_unconfigure_device
      	  pci_stop_and_remove_bus_device
      	    ...
      	      pciehp_remove                 # pciehp driver .remove method
      		pciehp_release_ctrl
      		  pcie_cleanup_slot
      		    flush_workqueue(pciehp_wq)
      
      This is fairly urgent because it can be caused by simply unplugging a
      Thunderbolt adapter, as reported by Daniel below.
      
      [bhelgaas: changelog]
      Reference: http://lkml.kernel.org/r/CAMVG2ssiRgcTD1bej2tkUUfsWmpL5eNtPcNif9va2-Gzb2u8nQ@mail.gmail.comReported-and-tested-by: NDaniel J Blueman <daniel@quora.org>
      Reviewed-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Signed-off-by: NYijing Wang <wangyijing@huawei.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      CC: stable@vger.kernel.org
      c2be6f93
  18. 13 7月, 2012 1 次提交
  19. 13 1月, 2012 1 次提交
  20. 07 1月, 2012 1 次提交
  21. 06 12月, 2011 1 次提交
  22. 18 10月, 2010 1 次提交
    • T
      pciehp: update workqueue usage · a827ea30
      Tejun Heo 提交于
      * Rename pciehp_wq to pciehp_ordered_wq and add non-ordered pciehp_wq
        which is used instead of the system workqueue.  This is to remove
        the use of flush_scheduled_work() which is deprecated and scheduled
        for removal.
      
      * With cmwq in place, there's no point in creating workqueues lazily.
        Create both pciehp_wq and pciehp_ordered_wq upfront.
      
      * Include workqueue.h from pciehp.h.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      a827ea30
  23. 26 8月, 2010 1 次提交
  24. 25 8月, 2010 1 次提交
    • R
      PCI: PCIe: Ask BIOS for control of all native services at once · 28eb5f27
      Rafael J. Wysocki 提交于
      After commit 852972ac (ACPI: Disable
      ASPM if the platform won't provide _OSC control for PCIe) control of
      the PCIe Capability Structure is unconditionally requested by
      acpi_pci_root_add(), which in principle may cause problems to
      happen in two ways.  First, the BIOS may refuse to give control of
      the PCIe Capability Structure if it is not asked for any of the
      _OSC features depending on it at the same time.  Second, the BIOS may
      assume that control of the _OSC features depending on the PCIe
      Capability Structure will be requested in the future and may behave
      incorrectly if that doesn't happen.  For this reason, control of
      the PCIe Capability Structure should always be requested along with
      control of any other _OSC features that may depend on it (ie. PCIe
      native PME, PCIe native hot-plug, PCIe AER).
      
      Rework the PCIe port driver so that (1) it checks which native PCIe
      port services can be enabled, according to the BIOS, and (2) it
      requests control of all these services simultaneously.  In
      particular, this causes pcie_portdrv_probe() to fail if the BIOS
      refuses to grant control of the PCIe Capability Structure, which
      means that no native PCIe port services can be enabled for the PCIe
      Root Complex the given port belongs to.  If that happens, ASPM is
      disabled to avoid problems with mishandling it by the part of the
      PCIe hierarchy for which control of the PCIe Capability Structure
      has not been received.
      
      Make it possible to override this behavior using 'pcie_ports=native'
      (use the PCIe native services regardless of the BIOS response to the
      control request), or 'pcie_ports=compat' (do not use the PCIe native
      services at all).
      
      Accordingly, rework the existing PCIe port service drivers so that
      they don't request control of the services directly.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      28eb5f27
  25. 25 11月, 2009 1 次提交
  26. 18 9月, 2009 14 次提交