1. 07 11月, 2013 1 次提交
  2. 10 10月, 2013 1 次提交
  3. 01 10月, 2013 3 次提交
  4. 10 9月, 2013 1 次提交
  5. 06 9月, 2013 1 次提交
  6. 02 9月, 2013 1 次提交
  7. 31 8月, 2013 1 次提交
  8. 30 8月, 2013 2 次提交
    • N
      PCI/ACPI: Fix _OSC ordering to allow PCIe hotplug use when available · 3dc48af3
      Neil Horman 提交于
      This fixes the problem of acpiphp claiming slots that should be managed
      by pciehp, which may keep ExpressCard slots from working.
      
      The acpiphp driver claims PCIe slots unless the BIOS has granted us
      control of PCIe native hotplug via _OSC.  Prior to v3.10, the acpiphp
      .add method (add_bridge()) was always called *after* we had requested
      native hotplug control with _OSC.
      
      But after 3b63aaa7 ("PCI: acpiphp: Do not use ACPI PCI subdriver
      mechanism"), which appeared in v3.10, acpiphp initialization is done
      during the bus scan via the pcibios_add_bus() hook, and this happens
      *before* we request native hotplug control.
      
      Therefore, acpiphp doesn't know yet whether the BIOS will grant control,
      and it claims slots that we should be handling with native hotplug.
      
      This patch requests native hotplug control earlier, so we know whether
      the BIOS granted it to us before we initialize acpiphp.
      
      To avoid reintroducing the ASPM issue fixed by b8178f13 ('Revert
      "PCI/ACPI: Request _OSC control before scanning PCI root bus"'), we run
      _OSC earlier but defer the actual ASPM calls until after the bus scan is
      complete.
      
      Tested successfully by myself.
      
      [bhelgaas: changelog, mark for stable]
      Reference: https://bugzilla.kernel.org/show_bug.cgi?id=60736Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Acked-by: NYinghai Lu <yinghai@kernel.org>
      CC: stable@vger.kernel.org	# v3.10+
      CC: Len Brown <lenb@kernel.org>
      CC: "Rafael J. Wysocki" <rjw@sisk.pl>
      3dc48af3
    • R
      ACPI / hotplug: Remove containers synchronously · f943db40
      Rafael J. Wysocki 提交于
      The current protocol for handling hot remove of containers is very
      fragile and causes acpi_eject_store() to acquire acpi_scan_lock
      which may deadlock with the removal of the device that it is called
      for (the reason is that device sysfs attributes cannot be removed
      while their callbacks are being executed and ACPI device objects
      are removed under acpi_scan_lock).
      
      The problem is related to the fact that containers are handled by
      acpi_bus_device_eject() in a special way, which is to emit an
      offline uevent instead of just removing the container.  Then, user
      space is expected to handle that uevent and use the container's
      "eject" attribute to actually remove it.  That is fragile, because
      user space may fail to complete the ejection (for example, by not
      using the container's "eject" attribute at all) leaving the BIOS
      kind of in a limbo.  Moreover, if the eject event is not signaled
      for a container itself, but for its parent device object (or
      generally, for an ancestor above it in the ACPI namespace), the
      container will be removed straight away without doing that whole
      dance.
      
      For this reason, modify acpi_bus_device_eject() to remove containers
      synchronously like any other objects (user space will get its uevent
      anyway in case it does some other things in response to it) and
      remove the eject_pending ACPI device flag that is not used any more.
      This way acpi_eject_store() doesn't have a reason to acquire
      acpi_scan_lock any more and one possible deadlock scenario goes
      away (plus the code is simplified a bit).
      Reported-and-tested-by: NGu Zheng <guz.fnst@cn.fujitsu.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Acked-by: NToshi Kani <toshi.kani@hp.com>
      f943db40
  9. 29 8月, 2013 2 次提交
  10. 26 8月, 2013 1 次提交
  11. 23 8月, 2013 2 次提交
  12. 22 8月, 2013 2 次提交
  13. 21 8月, 2013 1 次提交
  14. 20 8月, 2013 4 次提交
  15. 15 8月, 2013 4 次提交
  16. 13 8月, 2013 10 次提交
  17. 12 8月, 2013 1 次提交
  18. 09 8月, 2013 2 次提交