1. 25 4月, 2014 1 次提交
  2. 05 3月, 2014 1 次提交
  3. 22 2月, 2014 1 次提交
  4. 07 2月, 2014 1 次提交
    • R
      ACPI / hotplug / PCI: Hotplug notifications from acpi_bus_notify() · 1a699476
      Rafael J. Wysocki 提交于
      Since acpi_bus_notify() is executed on all notifications for all
      devices anyway, make it execute acpi_device_hotplug() for all
      hotplug events instead of installing notify handlers pointing to
      the same function for all hotplug devices.
      
      This change reduces both the size and complexity of ACPI-based device
      hotplug code.  Moreover, since acpi_device_hotplug() only does
      significant things for devices that have either an ACPI scan handler,
      or a hotplug context with .eject() defined, and those devices
      had notify handlers pointing to acpi_hotplug_notify_cb() installed
      before anyway, this modification shouldn't change functionality.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      1a699476
  5. 06 2月, 2014 1 次提交
    • R
      ACPI / hotplug: Fix potential race in acpi_bus_notify() · 78ea4639
      Rafael J. Wysocki 提交于
      There is a slight possibility for the ACPI device object pointed to
      by adev in acpi_hotplug_notify_cb() to become invalid between the
      acpi_bus_get_device() that it comes from and the subsequent dereference
      of that pointer under get_device().  Namely, if acpi_scan_drop_device()
      runs in parallel with acpi_hotplug_notify_cb(), acpi_device_del_work_fn()
      queued up by it may delete the device object in question right after
      a successful execution of acpi_bus_get_device() in acpi_bus_notify().
      
      An analogous problem is present in acpi_bus_notify() where the device
      pointer coming from acpi_bus_get_device() may become invalid before
      it subsequent dereference in the "if" block.
      
      To prevent that from happening, introduce a new function,
      acpi_bus_get_acpi_device(), working analogously to acpi_bus_get_device()
      except that it will grab a reference to the ACPI device object returned
      by it and it will do that under the ACPICA's namespace mutex.  Then,
      make both acpi_hotplug_notify_cb() and acpi_bus_notify() use
      acpi_bus_get_acpi_device() instead of acpi_bus_get_device() so as to
      ensure that the pointers used by them will not become stale at one
      point.
      
      In addition to that, introduce acpi_bus_put_acpi_device() as a wrapper
      around put_device() to be used along with acpi_bus_get_acpi_device()
      and make the (new) users of the latter use acpi_bus_put_acpi_device()
      too.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      78ea4639
  6. 29 1月, 2014 1 次提交
    • M
      ACPI / init: Flag use of ACPI and ACPI idioms for power supplies to regulator API · 49a12877
      Mark Brown 提交于
      There is currently no facility in ACPI to express the hookup of voltage
      regulators, the expectation is that the regulators that exist in the
      system will be handled transparently by firmware if they need software
      control at all. This means that if for some reason the regulator API is
      enabled on such a system it should assume that any supplies that devices
      need are provided by the system at all relevant times without any software
      intervention.
      
      Tell the regulator core to make this assumption by calling
      regulator_has_full_constraints(). Do this as soon as we know we are using
      ACPI so that the information is available to the regulator core as early
      as possible. This will cause the regulator core to pretend that there is
      an always on regulator supplying any supply that is requested but that has
      not otherwise been mapped which is the behaviour expected on a system with
      ACPI.
      
      Should the ability to specify regulators be added in future revisions of
      ACPI then once we have support for ACPI mappings in the kernel the same
      assumptions will apply. It is also likely that systems will default to a
      mode of operation which does not require any interpretation of these
      mappings in order to be compatible with existing operating system releases
      so it should remain safe to make these assumptions even if the mappings
      exist but are not supported by the kernel.
      Signed-off-by: NMark Brown <broonie@linaro.org>
      Cc: All applicable <stable@vger.kernel.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      49a12877
  7. 31 12月, 2013 1 次提交
    • R
      ACPIPHP / radeon / nouveau: Fix VGA switcheroo problem related to hotplug · f244d8b6
      Rafael J. Wysocki 提交于
      The changes in the ACPI-based PCI hotplug (ACPIPHP) subsystem made
      during the 3.12 development cycle uncovered a problem with VGA
      switcheroo that on some systems, when the device-specific method
      (ATPX in the radeon case, _DSM in the nouveau case) is used to turn
      off the discrete graphics, the BIOS generates ACPI hotplug events for
      that device and those events cause ACPIPHP to attempt to remove the
      device from the system (they are events for a device that was present
      previously and is not present any more, so that's what should be done
      according to the spec).  Then, the system stops functioning correctly.
      
      Since the hotplug events in question were simply silently ignored
      previously, the least intrusive way to address that problem is to
      make ACPIPHP ignore them again.  For this purpose, introduce a new
      ACPI device flag, no_hotplug, and modify ACPIPHP to ignore hotplug
      events for PCI devices whose ACPI companions have that flag set.
      Next, make the radeon and nouveau switcheroo detection code set the
      no_hotplug flag for the discrete graphics' ACPI companion.
      
      Fixes: bbd34fcd (ACPI / hotplug / PCI: Register all devices under the given bridge)
      References: https://bugzilla.kernel.org/show_bug.cgi?id=61891
      References: https://bugzilla.kernel.org/show_bug.cgi?id=64891Reported-and-tested-by: NMike Lothian <mike@fireburn.co.uk>
      Reported-and-tested-by: <madcatx@atlas.cz>
      Reported-and-tested-by: NJoaquín Aramendía <samsagax@gmail.com>
      Cc: Alex Deucher <alexdeucher@gmail.com>
      Cc: Dave Airlie <airlied@linux.ie>
      Cc: Takashi Iwai <tiwai@suse.de>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: 3.12+ <stable@vger.kernel.org> # 3.12+
      f244d8b6
  8. 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
  9. 23 11月, 2013 2 次提交
  10. 24 10月, 2013 1 次提交
  11. 24 9月, 2013 1 次提交
  12. 06 8月, 2013 1 次提交
  13. 26 7月, 2013 1 次提交
  14. 15 7月, 2013 3 次提交
  15. 20 6月, 2013 1 次提交
  16. 25 3月, 2013 1 次提交
  17. 20 1月, 2013 1 次提交
  18. 17 1月, 2013 3 次提交
  19. 16 11月, 2012 1 次提交
  20. 15 11月, 2012 1 次提交
    • R
      ACPI / PM: Provide device PM functions operating on struct acpi_device · 078eb126
      Rafael J. Wysocki 提交于
      If the caller of acpi_bus_set_power() already has a pointer to the
      struct acpi_device object corresponding to the device in question, it
      doesn't make sense for it to go through acpi_bus_get_device(), which
      may be costly, because it involves acquiring the global ACPI
      namespace mutex.
      
      For this reason, export the function operating on struct acpi_device
      objects used internally by acpi_bus_set_power(), so that it may be
      called instead of acpi_bus_set_power() in the above case, and change
      its name to acpi_device_set_power().
      
      Additionally, introduce two inline wrappers for checking ACPI PM
      capabilities of devices represented by struct acpi_device objects.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      078eb126
  21. 25 9月, 2012 1 次提交
  22. 14 9月, 2012 1 次提交
    • R
      ACPI / PM: Infer parent power state from child if unknown, v2 · 8f7412a7
      Rafael J. Wysocki 提交于
      It turns out that there are ACPI BIOSes defining device objects with
      _PSx and without either _PSC or _PRx.  For devices corresponding to
      those ACPI objetcs __acpi_bus_get_power() returns ACPI_STATE_UNKNOWN
      and their initial power states are regarded as unknown as a result.
      If such a device is a parent of another power-manageable device, the
      child cannot be put into a low-power state through ACPI, because
      __acpi_bus_set_power() refuses to change power states of devices
      whose parents' power states are unknown.
      
      To work around this problem, observe that the ACPI power state of
      a device cannot be higher-power (lower-number) than the power state
      of its parent.  Thus, if the device's _PSC method or the
      configuration of its power resources indicates that the device is
      in D0, the device's parent has to be in D0 as well.  Consequently,
      if the parent's power state is unknown when we've just learned that
      its child's power state is D0, we can safely set the parent's
      power.state field to ACPI_STATE_D0.
      Tested-by: NAaron Lu <aaron.lu@intel.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      8f7412a7
  23. 04 6月, 2012 1 次提交
  24. 30 5月, 2012 2 次提交
    • R
      ACPI / PM: Make __acpi_bus_get_power() cover D3cold correctly · 38c92fff
      Rafael J. Wysocki 提交于
      After recent changes of the ACPI device power states definitions, if
      power resources are not used for the device's power management, the
      state returned by __acpi_bus_get_power() cannot exceed D3hot, because
      the return values of _PSC are 0 through 3.  However, if the _PR3
      method is not present for the device and _PS3 returns 3, we have to
      assume that the device is in D3cold, so the value returned by
      __acpi_bus_get_power() in that case should be 4.
      
      Similarly, acpi_power_get_inferred_state() should take the power
      resources for the D3hot state into account in general, so that it
      can return 3 if those resources are "on" or 4 (D3cold) otherwise.
      
      Fix the the above two issues and make sure that if both _PSC and
      _PR3 are present for the device, the power resources listed by _PR3
      will be used to determine if the number 3 returned by _PSC is meant
      to represent D3cold or D3hot.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      38c92fff
    • R
      ACPI / PM: Fix error messages in drivers/acpi/bus.c · 63a1a765
      Rafael J. Wysocki 提交于
      After recent changes of the ACPI device low-power states definitions
      kernel messages in drivers/acpi/bus.c need to be updated so that they
      include the correct names of the states in question (currently is
      "D3" for D3hot and "D4" for D3cold, which is incorrect).
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      63a1a765
  25. 18 5月, 2012 1 次提交
    • R
      ACPI / PCI / PM: Fix device PM regression related to D3hot/D3cold · 5c7dd710
      Rafael J. Wysocki 提交于
      Commit 1cc0c998 ("ACPI: Fix D3hot v D3cold confusion") introduced a
      bug in __acpi_bus_set_power() and changed the behavior of
      acpi_pci_set_power_state() in such a way that it generally doesn't work
      as expected if PCI_D3hot is passed to it as the second argument.
      
      First off, if ACPI_STATE_D3 (equal to ACPI_STATE_D3_COLD) is passed to
      __acpi_bus_set_power() and the explicit_set flag is set for the D3cold
      state, the function will try to execute AML method called "_PS4", which
      doesn't exist.
      
      Fix this by adding a check to ensure that the name of the AML method
      to execute for transitions to ACPI_STATE_D3_COLD is correct in
      __acpi_bus_set_power().  Also make sure that the explicit_set flag
      for ACPI_STATE_D3_COLD will be set if _PS3 is present and modify
      acpi_power_transition() to avoid accessing power resources for
      ACPI_STATE_D3_COLD, because they don't exist.
      
      Second, if PCI_D3hot is passed to acpi_pci_set_power_state() as the
      target state, the function will request a transition to
      ACPI_STATE_D3_HOT instead of ACPI_STATE_D3.  However,
      ACPI_STATE_D3_HOT is now only marked as supported if the _PR3 AML
      method is defined for the given device, which is rare.  This causes
      problems to happen on systems where devices were successfully put
      into ACPI D3 by pci_set_power_state(PCI_D3hot) which doesn't work
      now.  In particular, some unused graphics adapters are not turned
      off as a result.
      
      To fix this issue restore the old behavior of
      acpi_pci_set_power_state(), which is to request a transition to
      ACPI_STATE_D3 (equal to ACPI_STATE_D3_COLD) if either PCI_D3hot or
      PCI_D3cold is passed to it as the argument.
      
      This approach is not ideal, because generally power should not
      be removed from devices if PCI_D3hot is the target power state,
      but since this behavior is relied on, we have no choice but to
      restore it at the moment and spend more time on designing a
      better solution in the future.
      
      References: https://bugzilla.kernel.org/show_bug.cgi?id=43228Reported-by: Nrocko <rockorequin@hotmail.com>
      Reported-by: NCristian Rodríguez <crrodriguez@opensuse.org>
      Reported-and-tested-by: NPeter <lekensteyn@gmail.com>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5c7dd710
  26. 30 3月, 2012 1 次提交
  27. 07 11月, 2011 1 次提交
  28. 03 8月, 2011 1 次提交
  29. 14 7月, 2011 1 次提交
    • H
      ACPI, APEI, Add APEI bit support in generic _OSC call · eccddd32
      Huang Ying 提交于
      In APEI firmware first mode, hardware error is reported by hardware to
      firmware firstly, then firmware reports the error to Linux in a GHES
      error record via POLL/SCI/IRQ/NMI etc.
      
      This may result in some issues if OS has no full APEI support.  So
      some firmware implementation will work in a back-compatible mode by
      default.  Where firmware will only notify OS in old-fashion, without
      GHES record.  For example, for a fatal hardware error, only NMI is
      signaled, no GHES record.
      
      To gain full APEI power on these machines, APEI bit in generic _OSC
      call can be specified to tell firmware that Linux has full APEI
      support.  This patch adds the APEI bit support in generic _OSC call.
      Signed-off-by: NHuang Ying <ying.huang@intel.com>
      Reviewed-by: NAndi Kleen <ak@linux.intel.com>
      Reviewed-by: NMatthew Garrett <mjg@redhat.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      eccddd32
  30. 29 5月, 2011 1 次提交
  31. 15 3月, 2011 2 次提交
  32. 12 1月, 2011 2 次提交
    • R
      ACPI / PM: Drop acpi_power_nocheck · 53eac700
      Rafael J. Wysocki 提交于
      Since acpi_bus_set_power() should not use __acpi_bus_get_power() to
      update the device's device->power.state field before changing its
      power state (this may cause device->power.state to be inconsistent
      with the device power resources' reference counters), remove this
      call from it.  In consequence, the acpi_power_nocheck variable is not
      necessary any more, so it can be dropped along with the DMI table
      used for setting that variable for HP Pavilion 05.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      53eac700
    • R
      ACPI / PM: Drop acpi_bus_get_power() · f6767dcf
      Rafael J. Wysocki 提交于
      There are no more users of acpi_bus_get_power(), so it can be
      dropped.  Moreover, it should be dropped, because it modifies
      the device->power.state field of an ACPI device without updating
      the reference counters of the device's power resources, which is
      wrong.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      f6767dcf