1. 18 5月, 2013 1 次提交
  2. 17 4月, 2013 2 次提交
  3. 13 4月, 2013 4 次提交
  4. 13 2月, 2013 1 次提交
    • R
      ACPI / hotplug: Fix concurrency issues and memory leaks · 3757b948
      Rafael J. Wysocki 提交于
      This changeset is aimed at fixing a few different but related
      problems in the ACPI hotplug infrastructure.
      
      First of all, since notify handlers may be run in parallel with
      acpi_bus_scan(), acpi_bus_trim() and acpi_bus_hot_remove_device()
      and some of them are installed for ACPI handles that have no struct
      acpi_device objects attached (i.e. before those objects are created),
      those notify handlers have to take acpi_scan_lock to prevent races
      from taking place (e.g. a struct acpi_device is found to be present
      for the given ACPI handle, but right after that it is removed by
      acpi_bus_trim() running in parallel to the given notify handler).
      Moreover, since some of them call acpi_bus_scan() and
      acpi_bus_trim(), this leads to the conclusion that acpi_scan_lock
      should be acquired by the callers of these two funtions rather by
      these functions themselves.
      
      For these reasons, make all notify handlers that can handle device
      addition and eject events take acpi_scan_lock and remove the
      acpi_scan_lock locking from acpi_bus_scan() and acpi_bus_trim().
      Accordingly, update all of their users to make sure that they
      are always called under acpi_scan_lock.
      
      Furthermore, since eject operations are carried out asynchronously
      with respect to the notify events that trigger them, with the help
      of acpi_bus_hot_remove_device(), even if notify handlers take the
      ACPI scan lock, it still is possible that, for example,
      acpi_bus_trim() will run between acpi_bus_hot_remove_device() and
      the notify handler that scheduled its execution and that
      acpi_bus_trim() will remove the device node passed to
      acpi_bus_hot_remove_device() for ejection.  In that case, the struct
      acpi_device object obtained by acpi_bus_hot_remove_device() will be
      invalid and not-so-funny things will ensue.  To protect agaist that,
      make the users of acpi_bus_hot_remove_device() run get_device() on
      ACPI device node objects that are about to be passed to it and make
      acpi_bus_hot_remove_device() run put_device() on them and check if
      their ACPI handles are not NULL (make acpi_device_unregister() clear
      the device nodes' ACPI handles for that check to work).
      
      Finally, observe that acpi_os_hotplug_execute() actually can fail,
      in which case its caller ought to free memory allocated for the
      context object to prevent leaks from happening.  It also needs to
      run put_device() on the device node that it ran get_device() on
      previously in that case.  Modify the code accordingly.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NYinghai Lu <yinghai@kernel.org>
      3757b948
  5. 03 2月, 2013 1 次提交
    • J
      PCI: acpiphp: Remove dead code for PCI host bridge hotplug · be6d2867
      Jiang Liu 提交于
      Commit 668192b6 "PCI: acpiphp: Move host bridge hotplug
      to pci_root.c" has moved PCI host bridge hotplug logic from acpiphp
      to pci_root, but there is still PCI host bridge hotplug related
      dead code left in acpiphp. So remove those dead code.
      
      Now companion ACPI devices are always created before corresponding
      PCI devices. And the ACPI event handle_hotplug_event_bridge() will be
      installed only if it has associated PCI device. So remove dead code to
      handle bridge hot-adding in function handle_hotplug_event_bridge().
      Signed-off-by: NJiang Liu <jiang.liu@huawei.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      be6d2867
  6. 02 2月, 2013 1 次提交
  7. 26 1月, 2013 5 次提交
  8. 19 1月, 2013 1 次提交
    • R
      ACPI / scan: Drop acpi_bus_add() and use acpi_bus_scan() instead · b8bd759a
      Rafael J. Wysocki 提交于
      The only difference between acpi_bus_scan() and acpi_bus_add() is the
      invocation of acpi_update_all_gpes() in the latter which in fact is
      unnecessary, because acpi_update_all_gpes() has already been called
      by acpi_scan_init() and the way it is implemented guarantees the next
      invocations of it to do nothing.
      
      For this reason, drop acpi_bus_add() and make all its callers use
      acpi_bus_scan() directly instead of it.  Additionally, rearrange the
      code in acpi_scan_init() slightly to improve the visibility of the
      acpi_update_all_gpes() call in there.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NYinghai Lu <yinghai@kernel.org>
      b8bd759a
  9. 15 1月, 2013 1 次提交
  10. 03 1月, 2013 3 次提交
    • R
      ACPI: Make acpi_bus_scan() and acpi_bus_add() take only one argument · 0cd6ac52
      Rafael J. Wysocki 提交于
      The callers of acpi_bus_add() usually assume that if it has
      succeeded, then a struct acpi_device object has been attached to
      the handle passed as the first argument.  Unfortunately, however,
      this assumption is wrong, because acpi_bus_scan(), and acpi_bus_add()
      too as a result, may return a pointer to a different struct
      acpi_device object on success (it may be an object corresponding to
      one of the descendant ACPI nodes in the namespace scope below that
      handle).
      
      For this reason, the callers of acpi_bus_add() who care about
      whether or not a struct acpi_device object has been created for
      its first argument need to check that using acpi_bus_get_device()
      anyway, so the second argument of acpi_bus_add() is not really
      useful for them.  The same observation applies to acpi_bus_scan()
      executed directly from acpi_scan_init().
      
      Therefore modify the relevant callers of acpi_bus_add() to check the
      existence of the struct acpi_device in question with the help of
      acpi_bus_get_device() and drop the no longer necessary second
      argument of acpi_bus_add().  Accordingly, modify acpi_scan_init() to
      use acpi_bus_get_device() to get acpi_root and drop the no longer
      needed second argument of acpi_bus_scan().
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NYinghai Lu <yinghai@kernel.org>
      Acked-by: NToshi Kani <toshi.kani@hp.com>
      0cd6ac52
    • R
      ACPI: Remove the arguments of acpi_bus_add() that are not used · 636458de
      Rafael J. Wysocki 提交于
      Notice that acpi_bus_add() uses only 2 of its 4 arguments and
      redefine its header to match the body.  Update all of its callers as
      necessary and observe that this leads to quite a number of removed
      lines of code (Linus will like that).
      
      Add a kerneldoc comment documenting acpi_bus_add() and wonder how
      its callers make wrong assumptions about the second argument (make
      note to self to take care of that later).
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NYinghai Lu <yinghai@kernel.org>
      Acked-by: NToshi Kani <toshi.kani@hp.com>
      636458de
    • R
      ACPI: Remove acpi_start_single_object() and acpi_bus_start() · 02f57c67
      Rafael J. Wysocki 提交于
      The ACPI PCI root bridge driver was the only ACPI driver implementing
      the .start() callback, which isn't used by any ACPI drivers any more
      now.
      
      For this reason, acpi_start_single_object() has no purpose any more,
      so remove it and all references to it.  Also remove
      acpi_bus_start_device(), whose only purpose was to call
      acpi_start_single_object().
      
      Moreover, since after the removal of acpi_bus_start_device() the
      only purpose of acpi_bus_start() remains to call
      acpi_update_all_gpes(), move that into acpi_bus_add() and drop
      acpi_bus_start() too, remove its header from acpi_bus.h and
      update all of its former users accordingly.
      
      This change was previously proposed in a different from by
      Yinghai Lu.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NYinghai Lu <yinghai@kernel.org>
      Acked-by: NToshi Kani <toshi.kani@hp.com>
      02f57c67
  11. 25 9月, 2012 2 次提交
    • J
      PCI: acpiphp: Handle PCIe ports without native hotplug capability · 5ba113f7
      Jiang Liu 提交于
      Commit 0d52f54e (PCI / ACPI: Make acpiphp
      ignore root bridges using PCIe native hotplug) added code that made the
      acpiphp driver completely ignore PCIe root complexes for which the kernel
      had been granted control of the native PCIe hotplug feature by the BIOS
      through _OSC. Later commit 619a5182
      "PCI hotplug: Always allow acpiphp to handle non-PCIe bridges" relaxed
      the constraints to allow acpiphp driver handle non-PCIe bridges under
      such a complex.  The constraint needs to be relaxed further to allow
      acpiphp driver to handle PCIe ports without native PCIe hotplug capability.
      
      Some MR-IOV switch chipsets, such PLX8696, support multiple virtual PCIe
      switches and may migrate downstream ports among virtual switches.  To
      migrate a downstream port from the source virtual switch to the target, the
      port needs to be hot-removed from the source and hot-added into the target.
      The pciehp driver can't be used here because there are no slots within the
      virtual PCIe switch.  So acpiphp driver is used to support downstream port
      migration.  A typical configuration is as below:
      
          [Root without native PCIe HP]
              [Upstream port of vswitch without native PCIe HP]
                  [Downstream port of vswitch with native PCIe HP]
                      [PCIe endpoint]
      
      Here acpiphp driver will be used to handle root ports and upstream port
      in the virtual switch, and pciehp driver will be used to handle downstream
      ports in the virtual switch.
      Signed-off-by: NJiang Liu <liuj97@gmail.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Acked-by: NRafael J. Wysocki <rjw@sisk.pl>
      5ba113f7
    • T
      PCI/ACPI: Pass acpi_pci_root to acpi_pci_drivers' add/remove interface · 55bfe3c0
      Taku Izumi 提交于
      This patch changes .add/.remove interfaces of acpi_pci_driver.
      In the current implementation acpi_handle is passed as a parameter
      of .add/.remove interface.  However, the acpi_pci_root structure
      contains more useful information than just the acpi_handle.  This
      enables us to avoid some useless lookups in each acpi_pci_driver.
      
      Note: This changes interfaces used by acpi_pci_register_driver(), an
      exported symbol.  This patch updates all the in-kernel users, but any
      out-of-kernel acpi_pci_register_driver() users will need updates.
      
      [bhelgaas: changelog]
      Signed-off-by: NTaku Izumi <izumi.taku@jp.fujitsu.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      55bfe3c0
  12. 23 8月, 2012 2 次提交
  13. 18 8月, 2012 1 次提交
  14. 11 7月, 2012 1 次提交
  15. 21 6月, 2012 1 次提交
  16. 14 6月, 2012 3 次提交
  17. 28 2月, 2012 2 次提交
  18. 15 2月, 2012 1 次提交
    • A
      PCI: Can continually add funcs after adding func0 · f382a086
      Amos Kong 提交于
      Boot up a KVM guest, and hotplug multifunction
      devices(func1,func2,func0,func3) to guest.
      
      for i in 1 2 0 3;do
      qemu-img create /tmp/resize$i.qcow2 1G -f qcow2
      (qemu) drive_add 0x11.$i id=drv11$i,if=none,file=/tmp/resize$i.qcow2
      (qemu) device_add virtio-blk-pci,id=dev11$i,drive=drv11$i,addr=0x11.$i,multifunction=on
      done
      
      In linux kernel, when func0 of the slot is hot-added, the whole
      slot will be marked as 'enabled', then driver will ignore other new
      hotadded funcs.
      But in Win7 & WinXP, we can continaully add other funcs after adding
      func0, all funcs will be added in guest.
      
      drivers/pci/hotplug/acpiphp_glue.c:
      static int acpiphp_check_bridge(struct acpiphp_bridge *bridge)
      {
      ....
              for (slot = bridge->slots; slot; slot = slot->next) {
                      if (slot->flags & SLOT_ENABLED) {
                              acpiphp_disable_slot()
                      else
                              acpiphp_enable_slot()
      ....                              |
      }                                 v
                                  enable_device()
                                        |
                                        v
              //only don't enable slot if func0 is not added
      	list_for_each_entry(func, &slot->funcs, sibling) {
                     ...
              }
             slot->flags |= SLOT_ENABLED; //mark slot to 'enabled'
      
      This patch just make pci driver can continaully add funcs after adding
      func 0. Only mark slot to 'enabled' when all funcs are added.
      
      For pci multifunction hotplug, we can add functions one by one(func 0 is
      necessary), and all functions will be removed in one time.
      Signed-off-by: NAmos Kong <akong@redhat.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      f382a086
  19. 15 12月, 2011 1 次提交
    • A
      PCI: Set device power state to PCI_D0 for device without native PM support · b51306c6
      Ajaykumar Hotchandani 提交于
      During test of one IB card with guest VM, found that, msi is not
      initialized properly.
      
      It turns out __write_msi_msg will do nothing if device current_state is
      not PCI_D0.  And, that pci device does not have pm_cap in guest VM.
      
      There is an error in setting of power state to PCI_D0 in
      pci_enable_device(), but error is not returned for this.  Following is
      code flow:
      
      pci_enable_device() -->   __pci_enable_device_flags() -->
      do_pci_enable_device() -->   pci_set_power_state() -->
      __pci_start_power_transition()
      
      We have following condition inside __pci_start_power_transition():
               if (platform_pci_power_manageable(dev)) {
                       error = platform_pci_set_power_state(dev, state);
                       if (!error)
                               pci_update_current_state(dev, state);
               } else {
                       error = -ENODEV;
                       /* Fall back to PCI_D0 if native PM is not supported */
                       if (!dev->pm_cap)
                               dev->current_state = PCI_D0;
               }
      
      Here, from platform_pci_set_power_state(), acpi_pci_set_power_state() is
      getting called and that is failing with ENODEV because of following
      condition:
      
               if (!handle || ACPI_SUCCESS(acpi_get_handle(handle, "_EJ0",&tmp)))
                       return -ENODEV;
      
      Because of that, pci_update_current_state() is not getting called.
      
      With this patch, if device power state can not be set via
      platform_pci_set_power_state and that device does not have native pm
      support, then PCI device power state will be set to PCI_D0.
      
      -v2: This also reverts 47e9037a, as it's
           not needed after this change.
      Acked-by: N"Rafael J. Wysocki" <rjw@sisk.pl>
      Signed-off-by: Ajaykumar Hotchandani<ajaykumar.hotchandani@oracle.com>
      Signed-off-by: Yinghai Lu<yinghai.lu@oracle.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      b51306c6
  20. 14 12月, 2011 1 次提交
    • R
      PCI hotplug: Always allow acpiphp to handle non-PCIe bridges · 619a5182
      Rafael J. Wysocki 提交于
      Commit 0d52f54e (PCI / ACPI: Make
      acpiphp ignore root bridges using PCIe native hotplug) added code
      that made the acpiphp driver completely ignore PCIe root complexes
      for which the kernel had been granted control of the native PCIe
      hotplug feature by the BIOS through _OSC.  Unfortunately, however,
      this was a mistake, because on some systems there were PCI bridges
      supporting PCI (non-PCIe) hotplug under such root complexes and
      those bridges should have been handled by acpiphp.
      
      For this reason, revert the changes made by the commit mentioned
      above and make register_slot() in drivers/pci/hotplug/acpiphp_glue.c
      avoid registering hotplug slots for PCIe ports that belong to
      root complexes with native PCIe hotplug enabled (which means that
      the BIOS has granted the kernel control of this feature for the
      given root complex).  This is reported to address the original
      issue fixed by commit 0d52f54e and
      to work on the system where that commit broke things.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      619a5182
  21. 06 12月, 2011 1 次提交
    • R
      PCI/ACPI: Make acpiphp ignore root bridges using SHPC native hotplug · d90116ea
      Rafael J. Wysocki 提交于
      If the kernel has requested control of the SHPC native hotplug
      feature for a given root bridge, the acpiphp driver should not try
      to handle that root bridge and it should leave it to shpchp.
      Failing to do so causes problems to happen if shpchp is loaded
      and unloaded before loading acpiphp (ACPI-based hotplug won't work
      in that case anyway).
      
      To address this issue make find_root_bridges() ignore PCI root
      bridges with SHPC native hotplug enabled and make add_bridge()
      return error code if SHPC native hotplug is enabled for the given
      root bridge.  This causes acpiphp to refuse to load if SHPC native
      hotplug is enabled for all root bridges and to refuse binding to
      the root bridges with SHPC native hotplug enabled.
      Reviewed-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      d90116ea
  22. 01 11月, 2011 1 次提交
  23. 15 10月, 2011 1 次提交
    • P
      PCI hotplug: acpiphp: Prevent deadlock on PCI-to-PCI bridge remove · 6af8bef1
      Prarit Bhargava 提交于
      I originally submitted a patch to workaround this by pushing all Ejection
      Requests and Device Checks onto the kacpi_hotplug queue.
      
      http://marc.info/?l=linux-acpi&m=131678270930105&w=2
      
      The patch is still insufficient in that Bus Checks also need to be added.
      
      Rather than add all events, including non-PCI-hotplug events, to the
      hotplug queue, mjg suggested that a better approach would be to modify
      the acpiphp driver so only acpiphp events would be added to the
      kacpi_hotplug queue.
      
      It's a longer patch, but at least we maintain the benefit of having separate
      queues in ACPI.  This, of course, is still only a workaround the problem.
      As Bjorn and mjg pointed out, we have to refactor a lot of this code to do
      the right thing but at this point it is a better to have this code working.
      
      The acpi core places all events on the kacpi_notify queue.  When the acpiphp
      driver is loaded and a PCI card with a PCI-to-PCI bridge is removed the
      following call sequence occurs:
      
      cleanup_p2p_bridge()
      	    -> cleanup_bridge()
      		    -> acpi_remove_notify_handler()
      			    -> acpi_os_wait_events_complete()
      				    -> flush_workqueue(kacpi_notify_wq)
      
      which is the queue we are currently executing on and the process will hang.
      
      Move all hotplug acpiphp events onto the kacpi_hotplug workqueue.  In
      handle_hotplug_event_bridge() and handle_hotplug_event_func() we can simply
      push the rest of the work onto the kacpi_hotplug queue and then avoid the
      deadlock.
      Signed-off-by: NPrarit Bhargava <prarit@redhat.com>
      Cc: mjg@redhat.com
      Cc: bhelgaas@google.com
      Cc: linux-acpi@vger.kernel.org
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      6af8bef1
  24. 17 7月, 2011 1 次提交
  25. 12 5月, 2011 1 次提交