1. 12 Jan, 2011 31 commits
  2. 11 Jan, 2011 1 commit
    • Rafael J. Wysocki's avatar
      PNP / ACPI: Use DEVICE_ACPI_HANDLE() for device ACPI handle access · cc8e7a35
      Rafael J. Wysocki authored
      The PNP ACPI driver squirrels the ACPI handles of PNP devices' ACPI
      companions, but this isn't correct, because those handles should be
      accessed using the DEVICE_ACPI_HANDLE() macro operating on struct
      device objects.
      
      Using DEVICE_ACPI_HANDLE() in the PNP ACPI driver instead of the
      driver's own copies of the ACPI handles allows us to avoid a problem
      with docking stations where a machine docked before suspend to RAM
      and undocked while suspended crashes during the subsequent resume (in
      that case the ACPI companion of the PNP device in question doesn't
      exist any more while the device is being resumed).  It also allows us
      to avoid the problem where suspend to RAM fails when the machine was
      undocked while suspended before (again, the ACPI companion of the PNP
      device is not present any more while it is being suspended).
      
      This change doesn't fix all of the the PNP ACPI driver's problems
      with PNP devices in docking stations (generally speaking, the driver
      has no idea that devices can come and go and doesn't even attempt to
      handle such events), but at least it makes suspend work for the
      users of docking stations who don't use the PNP devices located in
      there.
      
      References: https://bugzilla.kernel.org/show_bug.cgi?id=15100Reported-and-tested-by: default avatarToralf Förster <toralf.foerster@gmx.de>
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: default avatarBjorn Helgaas <bjorn.helgaas@hp.com>
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      cc8e7a35
  3. 10 Jan, 2011 2 commits
  4. 07 Jan, 2011 6 commits
    • Rafael J. Wysocki's avatar
      ACPI / PM: Blacklist Averatec machine known to require acpi_sleep=nonvs · 7b330707
      Rafael J. Wysocki authored
      Apparently, Averatec AV1020-ED2 does not resume correctly without
      acpi_sleep=nonvs, so add it to the ACPI sleep blacklist.
      
      References: https://bugzilla.kernel.org/show_bug.cgi?id=16396#c86Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      7b330707
    • Rafael J. Wysocki's avatar
      ACPI / PM: Report wakeup events from buttons · 1f83511b
      Rafael J. Wysocki authored
      Since ACPI buttons and lids can be configured to wake up the system
      from sleep states, report wakeup events from these devices.
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      1f83511b
    • Rafael J. Wysocki's avatar
      ACPI / PM: Drop special ACPI wakeup flags · 7fa69baf
      Rafael J. Wysocki authored
      Drop special ACPI wakeup flags, wakeup.state.enabled and
      wakeup.flags.always_enabled, that aren't necessary any more after
      we've started to use standard device wakeup flags for handling ACPI
      wakeup devices.
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      7fa69baf
    • Rafael J. Wysocki's avatar
      ACPI / PM: Use device wakeup flags for handling ACPI wakeup devices · f2b56bc8
      Rafael J. Wysocki authored
      There are ACPI devices (buttons and the laptop lid) that can wake up
      the system from sleep states and have no "physical" companion
      devices.  The ACPI subsystem uses two flags, wakeup.state.enabled and
      wakeup.flags.always_enabled, for handling those devices, but they
      are not accessible through the standard device wakeup infrastructure.
      User space can only control them via the /proc/acpi/wakeup interface
      that is not really convenient (e.g. the way in which devices are
      enabled to wake up the system is not portable between different
      systems, because it requires one to know the devices' "names" used in
      the system's ACPI tables).
      
      To address this problem, use standard device wakeup flags instead of
      the special ACPI flags for handling those devices.  In particular,
      use device_set_wakeup_capable() to mark the ACPI wakeup devices
      during initialization and use device_set_wakeup_enable() to allow
      or disallow them to wake up the system from sleep states.  Rework
      the /proc/acpi/wakeup interface to take these changes into account.
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      f2b56bc8
    • Rafael J. Wysocki's avatar
      ACPI / PM: Do not enable multiple devices to wake up simultaneously · b014f4f1
      Rafael J. Wysocki authored
      If a device is enabled to wake up the system from sleep states via
      /proc/acpi/wakeup and there are other devices associated with the
      same wakeup GPE, all of these devices are automatically enabled to
      wake up the system.  This isn't correct, because the fact the GPE is
      shared need not imply that wakeup power has to be enabled for all the
      devices at the same time (i.e. it is possible that one device will
      have its wakeup power enabled and it will wake up the system from a
      sleep state if the shared wakeup GPE is enabled, while another device
      having its wakeup power disabled will not wake up the system even
      though the GPE is enabled).  Rework acpi_system_write_wakeup_device()
      so that it only enables wakeup for one device at a time.
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      b014f4f1
    • Rafael J. Wysocki's avatar
      ACPI / ACPICA: Fix global lock acquisition · 9cd03144
      Rafael J. Wysocki authored
      There are two problems with the ACPICA's current implementation of
      the global lock acquisition.  First, acpi_ev_global_lock_handler(),
      which in fact is an interface to the outside of the kernel, doesn't
      validate its input, so it only works correctly if the other side
      (i.e. the ACPI firmware) is fully specification-compliant (as far
      as the global lock is concerned).  Unfortunately, that's known not
      to be the case on some systems (i.e. we get spurious global lock
      signaling interrupts without the pending flag set on some systems).
      Second, acpi_ev_global_lock_handler() attempts to acquire the global
      lock on behalf of a thread waiting for it without checking if there
      actually is such a thread.  Both of these shortcomings need to be
      addressed to prevent all possible race conditions from happening.
      
      Rework acpi_ev_global_lock_handler() so that it doesn't try to
      acquire the global lock and make it signal the availability of the
      global lock to the waiting thread instead.  Make sure that the
      availability of the global lock can only be signaled when there
      is a thread waiting for it and that it can't be signaled more than
      once in a row (to keep acpi_gbl_global_lock_semaphore in balance).
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      9cd03144