1. 24 Jun, 2013 1 commit
    • Rafael J. Wysocki's avatar
      ACPI / dock / PCI: Synchronous handling of dock events for PCI devices · 21a31013
      Rafael J. Wysocki authored
      The interactions between the ACPI dock driver and the ACPI-based PCI
      hotplug (acpiphp) are currently problematic because of ordering
      issues during hot-remove operations.
      First of all, the current ACPI glue code expects that physical
      devices will always be deleted before deleting the companion ACPI
      device objects.  Otherwise, acpi_unbind_one() will fail with a
      warning message printed to the kernel log, for example:
      [  185.026073] usb usb5: Oops, 'acpi_handle' corrupt
      [  185.035150] pci 0000:1b:00.0: Oops, 'acpi_handle' corrupt
      [  185.035515] pci 0000:18:02.0: Oops, 'acpi_handle' corrupt
      [  180.013656]  port1: Oops, 'acpi_handle' corrupt
      This means, in particular, that struct pci_dev objects have to
      be deleted before the struct acpi_device objects they are "glued"
      Now, the following happens the during the undocking of an ACPI-based
      dock station:
       1) hotplug_dock_devices() invokes registered hotplug callbacks to
          destroy physical devices associated with the ACPI device objects
          depending on the dock station.  It calls dd->ops->handler() for
          each of those device objects.
       2) For PCI devices dd->ops->handler() points to
          handle_hotplug_event_func() that queues up a separate work item
          to execute _handle_hotplug_event_func() for the given device and
          returns immediately.  That work item will be executed later.
       3) hotplug_dock_devices() calls dock_remove_acpi_device() for each
          device depending on the dock station.  This runs acpi_bus_trim()
          for each of them, which causes the underlying ACPI device object
          to be destroyed, but the work items queued up by
          handle_hotplug_event_func() haven't been started yet.
       4) _handle_hotplug_event_func() queued up in step 2) are executed
          and cause the above failure to happen, because the PCI devices
          they handle do not have the companion ACPI device objects any
          more (those objects have been deleted in step 3).
      The possible breakage doesn't end here, though, because
      hotplug_dock_devices() may return before at least some of the
      _handle_hotplug_event_func() work items spawned by it have a
      chance to complete and then undock() will cause _DCK to be
      evaluated and that will cause the devices handled by the
      _handle_hotplug_event_func() to go away possibly while they are
      being accessed.
      This means that dd->ops->handler() for PCI devices should not point
      to handle_hotplug_event_func().  Instead, it should point to a
      function that will do the work of _handle_hotplug_event_func()
      synchronously.  For this reason, introduce such a function,
      hotplug_event_func(), and modity acpiphp_dock_ops to point to
      it as the handler.
      Unfortunately, however, this is not sufficient, because if the dock
      code were not changed further, hotplug_event_func() would now
      deadlock with hotplug_dock_devices() that called it, since it would
      run unregister_hotplug_dock_device() which in turn would attempt to
      acquire the dock station's hp_lock mutex already acquired by
      To resolve that deadlock use the observation that
      unregister_hotplug_dock_device() won't need to acquire hp_lock
      if PCI bridges the devices on the dock station depend on are
      prevented from being removed prematurely while the first loop in
      hotplug_dock_devices() is in progress.
      To make that possible, introduce a mechanism by which the callers of
      register_hotplug_dock_device() can provide "init" and "release"
      routines that will be executed, respectively, during the addition
      and removal of the physical device object associated with the
      given ACPI device handle.  Make acpiphp use two new functions,
      acpiphp_dock_init() and acpiphp_dock_release(), that call
      get_bridge() and put_bridge(), respectively, on the acpiphp bridge
      holding the given device, for this purpose.
      In addition to that, remove the dock station's list of
      "hotplug devices" and make the dock code always walk the whole list
      of "dependent devices" instead in such a way that the loops in
      hotplug_dock_devices() and dock_event() (replacing the loops over
      "hotplug devices") will take references to the list entries that
      register_hotplug_dock_device() has been called for.  That prevents
      the "release" routines associated with those entries from being
      called while the given entry is being processed and for PCI
      devices this means that their bridges won't be removed (by a
      concurrent thread) while hotplug_event_func() handling them is
      being executed.
      This change is based on two earlier patches from Jiang Liu.
      References: https://bugzilla.kernel.org/show_bug.cgi?id=59501Reported-and-tested-by: default avatarAlexander E. Patrakov <patrakov@gmail.com>
      Tracked-down-by: default avatarJiang Liu <jiang.liu@huawei.com>
      Tested-by: default avatarIllya Klymov <xanf@xanf.me>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarYinghai Lu <yinghai@kernel.org>
      Cc: 3.9+ <stable@vger.kernel.org>
  2. 22 Jun, 2013 1 commit
  3. 19 Jun, 2013 4 commits
    • Rafael J. Wysocki's avatar
      ACPI / LPSS: Power up LPSS devices during enumeration · b9e95fc6
      Rafael J. Wysocki authored
      Commit 7cd8407d (ACPI / PM: Do not execute _PS0 for devices without
      _PSC during initialization) introduced a regression on some systems
      with Intel Lynxpoint Low-Power Subsystem (LPSS) where some devices
      need to be powered up during initialization, but their device objects
      in the ACPI namespace have _PS0 and _PS3 only (without _PSC or power
      To work around this problem, make the ACPI LPSS driver power up
      devices it knows about by using a new helper function
      acpi_device_fix_up_power() that does all of the necessary
      sanity checks and calls acpi_dev_pm_explicit_set() to put the
      device into D0.
      Reported-and-tested-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
    • Rafael J. Wysocki's avatar
      ACPI / PM: Fix error code path for power resources initialization · 6ee22e9d
      Rafael J. Wysocki authored
      Commit 781d737c (ACPI: Drop power resources driver) introduced a
      bug in the power resources initialization error code path causing
      a NULL pointer to be referenced in acpi_release_power_resource()
      if there's an error triggering a jump to the 'err' label in
      acpi_add_power_resource().  This happens because the list_node
      field of struct acpi_power_resource has not been initialized yet
      at this point and doing a list_del() on it is a bad idea.
      To prevent this problem from occuring, initialize the list_node
      field of struct acpi_power_resource upfront.
      Reported-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Tested-by: default avatarLan Tianyu <tianyu.lan@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: 3.9+ <stable@vger.kernel.org>
      Acked-by: default avatarYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Reviewed-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
    • Rafael J. Wysocki's avatar
      ACPI / dock: Take ACPI scan lock in write_undock() · 8112006f
      Rafael J. Wysocki authored
      Since commit 3757b948 (ACPI / hotplug: Fix concurrency issues and
      memory leaks) acpi_bus_scan() and acpi_bus_trim() must always be
      called under acpi_scan_lock, but currently the following scenario
      violating that requirement is possible:
      Fix that by making write_undock() acquire acpi_scan_lock before
      calling handle_eject_request() as appropriate (begin_undock() is
      under the lock too in analogy with acpi_dock_deferred_cb()).
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: 3.9+ <stable@vger.kernel.org>
      Acked-by: default avatarToshi Kani <toshi.kani@hp.com>
    • Mika Westerberg's avatar
      ACPI / resources: call acpi_get_override_irq() only for legacy IRQ resources · 204ebc0a
      Mika Westerberg authored
      acpi_get_override_irq() was added because there was a problem with
      buggy BIOSes passing wrong IRQ() resource for the RTC IRQ.  The
      commit that added the workaround was 61fd47e0 (ACPI: fix two
      IRQ8 issues in IOAPIC mode).
      With ACPI 5 enumerated devices there are typically one or more
      extended IRQ resources per device (and these IRQs can be shared).
      However, the acpi_get_override_irq() workaround forces all IRQs in
      range 0 - 15 (the legacy ISA IRQs) to be edge triggered, active high
      as can be seen from the dmesg below:
      	ACPI: IRQ 6 override to edge, high
      	ACPI: IRQ 7 override to edge, high
      	ACPI: IRQ 7 override to edge, high
      	ACPI: IRQ 13 override to edge, high
      Also /proc/interrupts for the I2C controllers (INT33C2 and INT33C3) shows
      the same thing:
      	7:          4          0          0          0   IO-APIC-edge INT33C2:00, INT33C3:00
      The _CSR method for INT33C2 (and INT33C3) device returns following
      	Interrupt (ResourceConsumer, Level, ActiveLow, Shared,,, )
      which states that this is supposed to be level triggered, active low,
      shared IRQ instead.
      Fix this by making sure that acpi_get_override_irq() gets only called
      when we are dealing with legacy IRQ() or IRQNoFlags() descriptors.
      While we are there, correct pr_warning() to print the right triggering
      This change turns out to be necessary to make DMA work correctly on
      systems based on the Intel Lynxpoint PCH (Platform Controller Hub).
      [rjw: Changelog]
      Signed-off-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Cc: 3.9+ <stable@vger.kernel.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
  4. 10 Jun, 2013 1 commit
  5. 07 Jun, 2013 2 commits
  6. 05 Jun, 2013 2 commits
  7. 01 Jun, 2013 2 commits
  8. 30 May, 2013 1 commit
  9. 22 May, 2013 1 commit
  10. 21 May, 2013 1 commit
    • Rafael J. Wysocki's avatar
      ACPI / PM: Allow device power states to be used for CONFIG_PM unset · ec4602a9
      Rafael J. Wysocki authored
      Currently, drivers/acpi/device_pm.c depends on CONFIG_PM and all of
      the functions defined in there are replaced with static inline stubs
      if that option is unset.  However, CONFIG_PM means, roughly, "runtime
      PM or suspend/hibernation support" and some of those functions are
      useful regardless of that.  For example, they are used by the ACPI
      fan driver for controlling fans and acpi_device_set_power() is called
      during device removal.  Moreover, device initialization may depend on
      setting device power states properly.
      For these reasons, make the routines manipulating ACPI device power
      states defined in drivers/acpi/device_pm.c available for CONFIG_PM
      unset too.
      Reported-by: default avatarZhang Rui <rui.zhang@intel.com>
      Reported-and-tested-by: default avatarMichel Lespinasse <walken@google.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: 3.9+ <stable@vger.kernel.org>
  11. 17 May, 2013 1 commit
  12. 15 May, 2013 1 commit
  13. 13 May, 2013 2 commits
  14. 12 May, 2013 4 commits
  15. 08 May, 2013 3 commits
  16. 01 May, 2013 1 commit
  17. 26 Apr, 2013 1 commit
  18. 25 Apr, 2013 1 commit
    • Aaron Lu's avatar
      ACPI: video: correct acpi_video_bus_add error processing · 91e13aa3
      Aaron Lu authored
      acpi_video_bus_get_devices() may fail due to some video output device
      doesn't have the _ADR method, and in this case, the error processing
      is to simply free the video structure in acpi_video_bus_add(), while
      leaving those already registered video output devices in the wild,
      which means for some video output device, we have already registered
      a backlight interface and installed a notification handler for it.
      So it can happen when user is using this system, on hotkey pressing,
      the notification handler will send a keycode through a non-existing
      input device, causing kernel freeze.
      To solve this problem, free all those already registered video output
      devices once something goes wrong in acpi_video_bus_get_devices(), so
      that no wild backlight interfaces and notification handlers exist.
      References: https://bugzilla.kernel.org/show_bug.cgi?id=51731
      Reported-and-tested-by: <i-tek@web.de>
      Signed-off-by: default avatarAaron Lu <aaron.lu@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
  19. 24 Apr, 2013 1 commit
  20. 23 Apr, 2013 1 commit
  21. 22 Apr, 2013 1 commit
  22. 16 Apr, 2013 1 commit
  23. 12 Apr, 2013 6 commits