1. 08 8月, 2019 4 次提交
  2. 30 7月, 2019 1 次提交
    • R
      ACPI: PM: Set up EC GPE for system wakeup from drivers that need it · 10a08fd6
      Rafael J. Wysocki 提交于
      The EC GPE needs to be set up for system wakeup only if there is a
      driver depending on it, either intel-hid or intel-vbtn, bound to a
      button device that is expected to wake up the system from sleep (such
      as the power button on some Dell systems, like the XPS13 9360).  It
      doesn't need to be set up for waking up the system from sleep in any
      other cases and whether or not it is expected to wake up the system
      from sleep doesn't depend on whether or not the LPS0 device is
      present in the ACPI namespace.
      
      For this reason, rearrange the ACPI suspend-to-idle code to make the
      drivers depending on the EC GPE wakeup take care of setting it up and
      decouple that from the LPS0 device handling.
      
      While at it, make intel-hid and intel-vbtn prepare for system wakeup
      only if they are allowed to wake up the system from sleep by user
      space (via sysfs).
      
      [Note that acpi_ec_mark_gpe_for_wake() and acpi_ec_set_gpe_wake_mask()
       are there to prevent the EC GPE from being disabled by the
       acpi_enable_all_wakeup_gpes() call in acpi_s2idle_prepare(), so on
       systems with either intel-hid or intel-vbtn this change doesn't
       affect any interactions with the hardware or platform firmware.]
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
      10a08fd6
  3. 23 7月, 2019 4 次提交
    • R
      PM: sleep: Simplify suspend-to-idle control flow · 56b99184
      Rafael J. Wysocki 提交于
      After commit 33e4f80e ("ACPI / PM: Ignore spurious SCI wakeups
      from suspend-to-idle") the "noirq" phases of device suspend and
      resume may run for multiple times during suspend-to-idle, if there
      are spurious system wakeup events while suspended.  However, this
      is complicated and fragile and actually unnecessary.
      
      The main reason for doing this is that on some systems the EC may
      signal system wakeup events (power button events, for example) as
      well as events that should not cause the system to resume (spurious
      system wakeup events).  Thus, in order to determine whether or not
      a given event signaled by the EC while suspended is a proper system
      wakeup one, the EC GPE needs to be dispatched and to start with that
      was achieved by allowing the ACPI SCI action handler to run, which
      was only possible after calling resume_device_irqs().
      
      However, dispatching the EC GPE this way turned out to take too much
      time in some cases and some EC events might be missed due to that, so
      commit 68e22011 ("ACPI: EC: Dispatch the EC GPE directly on
      s2idle wake") started to dispatch the EC GPE right after a wakeup
      event has been detected, so in fact the full ACPI SCI action handler
      doesn't need to run any more to deal with the wakeups coming from the
      EC.
      
      Use this observation to simplify the suspend-to-idle control flow
      so that the "noirq" phases of device suspend and resume are each
      run only once in every suspend-to-idle cycle, which is reported to
      significantly reduce power drawn by some systems when suspended to
      idle (by allowing them to reach a deep platform-wide low-power state
      through the suspend-to-idle flow).  [What appears to happen is that
      the "noirq" resume of devices after a spurious EC wakeup brings some
      devices into a state in which they prevent the platform from reaching
      the deep low-power state going forward, even after a subsequent
      "noirq" suspend phase, and on some systems the EC triggers such
      wakeups already when the "noirq" suspend of devices is running for
      the first time in the given suspend/resume cycle, so the platform
      cannot reach the deep low-power state at all.]
      
      First, make acpi_s2idle_wake() use the acpi_ec_dispatch_gpe() return
      value to determine whether or not the wakeup may have been triggered
      by the EC (in which case the system wakeup is canceled and ACPI
      events are processed in order to determine whether or not the event
      is a proper system wakeup one) and use rearm_wake_irq() (introduced
      by a previous change) in it to rearm the ACPI SCI for system wakeup
      detection in case the system will remain suspended.
      
      Second, drop acpi_s2idle_sync(), which is not needed any more, and
      the corresponding global platform suspend-to-idle callback.
      
      Next, drop the pm_wakeup_pending() check (which is an optimization
      only) from __device_suspend_noirq() to prevent it from returning
      errors on system wakeups occurring before the "noirq" phase of
      device suspend is complete (as in the case of suspend-to-idle it is
      not known whether or not these wakeups are suprious at that point),
      in order to avoid having to carry out a "noirq" resume of devices
      on a spurious system wakeup.
      
      Finally, change the code flow in s2idle_loop() to (1) run the
      "noirq" suspend of devices once before starting the loop, (2) check
      for spurious EC wakeups (via the platform ->wake callback) for the
      first time before calling s2idle_enter(), and (3) run the "noirq"
      resume of devices once after leaving the loop.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      56b99184
    • R
      ACPI: PM: Set s2idle_wakeup earlier and clear it later · 41275eb5
      Rafael J. Wysocki 提交于
      The role of the s2idle_wakeup variable is to cause
      acpi_pm_wakeup_event() and acpi_pm_notify_handler() to
      increment pm_abort_suspend and trigger a wakeup from
      suspend-to-idle in case the ACPI SCI wakeup was canceled
      by acpi_s2idle_wake().
      
      However, for this purpose it need not be set in acpi_s2idle_wake()
      and cleared in acpi_s2idle_sync(), respectively.  In fact, it
      may be set as early as in acpi_s2idle_prepare() and cleared as
      late as in acpi_s2idle_restore(), so do that to allow subsequent
      changes to be simpler.
      
      This change is not expected to alter functionality.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      41275eb5
    • R
      ACPI: EC: Return bool from acpi_ec_dispatch_gpe() · 9089f16e
      Rafael J. Wysocki 提交于
      On some systems, if suspend-to-idle is used, the EC may signal system
      wakeup events (power button events, for example) as well as events
      that should not cause the system to resume and acpi_ec_dispatch_gpe()
      needs to be called to determine whether or not the system should
      resume then.  In particular, if acpi_ec_dispatch_gpe() doesn't detect
      any EC events at all, the system should remain suspended, so it is
      useful to know when that is the case.
      
      For this reason, make acpi_ec_dispatch_gpe() return a bool value
      indicating whether or not any EC events have been detected by it.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      9089f16e
    • R
      ACPICA: Return u32 from acpi_dispatch_gpe() · 6921de89
      Rafael J. Wysocki 提交于
      In some cases it is useful to know whether or not the
      acpi_ev_detect_gpe() called by acpi_dispatch_gpe() has found
      the GPE to be active, so return the return value of it (whose
      data type is u32) from latter.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      6921de89
  4. 19 7月, 2019 1 次提交
    • D
      mm/memory_hotplug: rename walk_memory_range() and pass start+size instead of pfns · fbcf73ce
      David Hildenbrand 提交于
      walk_memory_range() was once used to iterate over sections.  Now, it
      iterates over memory blocks.  Rename the function, fixup the
      documentation.
      
      Also, pass start+size instead of PFNs, which is what most callers
      already have at hand.  (we'll rework link_mem_sections() most probably
      soon)
      
      Follow-up patches will rework, simplify, and move walk_memory_blocks()
      to drivers/base/memory.c.
      
      Note: walk_memory_blocks() only works correctly right now if the
      start_pfn is aligned to a section start.  This is the case right now,
      but we'll generalize the function in a follow up patch so the semantics
      match the documentation.
      
      [akpm@linux-foundation.org: remove unused variable]
      Link: http://lkml.kernel.org/r/20190614100114.311-5-david@redhat.comSigned-off-by: NDavid Hildenbrand <david@redhat.com>
      Reviewed-by: NAndrew Morton <akpm@linux-foundation.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Cc: Len Brown <lenb@kernel.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: David Hildenbrand <david@redhat.com>
      Cc: Rashmica Gupta <rashmica.g@gmail.com>
      Cc: Pavel Tatashin <pasha.tatashin@soleen.com>
      Cc: Anshuman Khandual <anshuman.khandual@arm.com>
      Cc: Michael Neuling <mikey@neuling.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Oscar Salvador <osalvador@suse.de>
      Cc: Michal Hocko <mhocko@suse.com>
      Cc: Wei Yang <richard.weiyang@gmail.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Qian Cai <cai@lca.pw>
      Cc: Arun KS <arunks@codeaurora.org>
      Cc: Nick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      fbcf73ce
  5. 16 7月, 2019 1 次提交
  6. 12 7月, 2019 2 次提交
  7. 10 7月, 2019 1 次提交
  8. 06 7月, 2019 2 次提交
    • D
      ACPI: PM: Make acpi_sleep_state_supported() non-static · ad5a449b
      Dexuan Cui 提交于
      With some upcoming patches to save/restore the Hyper-V drivers related
      states, a Linux VM running on Hyper-V will be able to hibernate. When
      a Linux VM hibernates, unluckily we must disable the memory hot-add/remove
      and balloon up/down capabilities in the hv_balloon driver
      (drivers/hv/hv_balloon.c), because these can not really work according to
      the design of the related back-end driver on the host.
      
      By default, Hyper-V does not enable the virtual ACPI S4 state for a VM;
      on recent Hyper-V hosts, the administrator is able to enable the virtual
      ACPI S4 state for a VM, so we hope to use the presence of the virtual ACPI
      S4 state as a hint for hv_balloon to disable the aforementioned
      capabilities. In this way, hibernation will work more reliably, from the
      user's perspective.
      
      By marking acpi_sleep_state_supported() non-static, we'll be able to
      implement a hv_is_hibernation_supported() API in the always-built-in
      module arch/x86/hyperv/hv_init.c, and the API will be called by hv_balloon.
      Signed-off-by: NDexuan Cui <decui@microsoft.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      ad5a449b
    • P
      libnvdimm: nd_region flush callback support · c5d4355d
      Pankaj Gupta 提交于
      This patch adds functionality to perform flush from guest
      to host over VIRTIO. We are registering a callback based
      on 'nd_region' type. virtio_pmem driver requires this special
      flush function. For rest of the region types we are registering
      existing flush function. Report error returned by host fsync
      failure to userspace.
      Signed-off-by: NPankaj Gupta <pagupta@redhat.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      c5d4355d
  9. 05 7月, 2019 1 次提交
  10. 04 7月, 2019 5 次提交
  11. 03 7月, 2019 5 次提交
  12. 27 6月, 2019 5 次提交
    • J
      ACPI/PPTT: Add function to return ACPI 6.3 Identical tokens · 56855a99
      Jeremy Linton 提交于
      ACPI 6.3 adds a flag to indicate that child nodes are all
      identical cores. This is useful to authoritatively determine
      if a set of (possibly offline) cores are identical or not.
      
      Since the flag doesn't give us a unique id we can generate
      one and use it to create bitmaps of sibling nodes, or simply
      in a loop to determine if a subset of cores are identical.
      Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: NHanjun Guo <hanjun.guo@linaro.org>
      Reviewed-by: NSudeep Holla <sudeep.holla@arm.com>
      Signed-off-by: NJeremy Linton <jeremy.linton@arm.com>
      Signed-off-by: NWill Deacon <will@kernel.org>
      56855a99
    • J
      ACPI/PPTT: Modify node flag detection to find last IDENTICAL · ed2b664f
      Jeremy Linton 提交于
      The ACPI specification implies that the IDENTICAL flag should be
      set on all non leaf nodes where the children are identical.
      This means that we need to be searching for the last node with
      the identical flag set rather than the first one.
      
      Since this flag is also dependent on the table revision, we
      need to add a bit of extra code to verify the table revision,
      and the next node's state in the traversal. Since we want to
      avoid function pointers here, lets just special case
      the IDENTICAL flag.
      Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: NHanjun Guo <hanjun.guo@linaro.org>
      Reviewed-by: NSudeep Holla <sudeep.holla@arm.com>
      Signed-off-by: NJeremy Linton <jeremy.linton@arm.com>
      Signed-off-by: NWill Deacon <will@kernel.org>
      ed2b664f
    • M
      ACPI / PM: Introduce concept of a _PR0 dependent device · 4533771c
      Mika Westerberg 提交于
      If there are shared power resources between otherwise unrelated devices
      turning them on causes the other devices sharing them to be powered up
      as well. In case of PCI devices go into D0uninitialized state meaning
      that if they were configured to trigger wake that configuration is lost
      at this point.
      
      For this reason introduce a concept of "_PR0 dependent device" that can
      be added to any ACPI device that has power resources. The dependent
      device will be included in a list of dependent devices for all power
      resources returned by the ACPI device's _PR0 (assuming it has one).
      Whenever a power resource having dependent devices is turned physically
      on (its _ON method is called) we runtime resume all of them to allow
      their driver or in case of PCI the PCI core to re-initialize the device
      and its wake configuration.
      
      This adds two functions that can be used to add and remove these
      dependent devices. Note the dependent device does not necessary need
      share power resources so this functionality can be used to add "software
      dependencies" as well if needed.
      Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      4533771c
    • R
      ACPI: PM: Allow transitions to D0 to occur in special cases · f850a48a
      Rafael J. Wysocki 提交于
      If a device with ACPI PM is left in D0 during a system-wide
      transition to the S3 (suspend-to-RAM) or S4 (hibernation) sleep
      state, the actual state of the device need not be D0 during resume
      from it, although its power.state value will still reflect D0 (that
      is, the power state from before the system-wide transition).
      
      In that case, the acpi_device_set_power() call made to ensure that
      the power state of the device will be D0 going forward has no effect,
      because the new state (D0) is equal to the one reflected by the
      device's power.state value.  That does not affect power resources,
      which are taken care of by acpi_resume_power_resources() called from
      acpi_pm_finish() during resume from system-wide sleep states, but it
      still may be necessary to invoke _PS0 for the device on top of that
      in order to finalize its transition to D0.
      
      For this reason, modify acpi_device_set_power() to allow transitions
      to D0 to occur even if D0 is the current power state of the device
      according to its power.state value.
      
      That will not affect power resources, which are assumed to be in
      the right configuration already (as reflected by the current values
      of their reference counters), but it may cause _PS0 to be evaluated
      for the device.  However, evaluating _PS0 for a device already in D0
      may lead to confusion in general, so invoke _PSC (if present) to
      check the device's current power state upfront and only evaluate
      _PS0 for it if _PSC has returned a power state different from D0.
      [If _PSC is not present or the evaluation of it fails, the power
      state of the device is assumed to be D0 at this point.]
      
      Fixes: 20dacb71 (ACPI / PM: Rework device power management to follow ACPI 6)
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      f850a48a
    • R
      ACPI: PM: Avoid evaluating _PS3 on transitions from D3hot to D3cold · 21ba2379
      Rafael J. Wysocki 提交于
      If the power state of a device with ACPI PM is changed from D3hot to
      D3cold, it merely is a matter of dropping references to additional
      power resources (specifically, those in the list returned by _PR3),
      and the _PS3 method should not be invoked for the device then (as
      it has already been evaluated during the previous transition to
      D3hot).
      
      Fixes: 20dacb71 (ACPI / PM: Rework device power management to follow ACPI 6)
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      21ba2379
  13. 24 6月, 2019 2 次提交
    • S
      bus_find_device: Unify the match callback with class_find_device · 418e3ea1
      Suzuki K Poulose 提交于
      There is an arbitrary difference between the prototypes of
      bus_find_device() and class_find_device() preventing their callers
      from passing the same pair of data and match() arguments to both of
      them, which is the const qualifier used in the prototype of
      class_find_device().  If that qualifier is also used in the
      bus_find_device() prototype, it will be possible to pass the same
      match() callback function to both bus_find_device() and
      class_find_device(), which will allow some optimizations to be made in
      order to avoid code duplication going forward.  Also with that, constify
      the "data" parameter as it is passed as a const to the match function.
      
      For this reason, change the prototype of bus_find_device() to match
      the prototype of class_find_device() and adjust its callers to use the
      const qualifier in accordance with the new prototype of it.
      
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andrew Lunn <andrew@lunn.ch>
      Cc: Andreas Noever <andreas.noever@gmail.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Corey Minyard <minyard@acm.org>
      Cc: Christian Borntraeger <borntraeger@de.ibm.com>
      Cc: David Kershner <david.kershner@unisys.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: David Airlie <airlied@linux.ie>
      Cc: Felipe Balbi <balbi@kernel.org>
      Cc: Frank Rowand <frowand.list@gmail.com>
      Cc: Grygorii Strashko <grygorii.strashko@ti.com>
      Cc: Harald Freudenberger <freude@linux.ibm.com>
      Cc: Hartmut Knaack <knaack.h@gmx.de>
      Cc: Heiko Stuebner <heiko@sntech.de>
      Cc: Jason Gunthorpe <jgg@ziepe.ca>
      Cc: Jonathan Cameron <jic23@kernel.org>
      Cc: "James E.J. Bottomley" <jejb@linux.ibm.com>
      Cc: Len Brown <lenb@kernel.org>
      Cc: Mark Brown <broonie@kernel.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Michael Jamet <michael.jamet@intel.com>
      Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
      Cc: Peter Oberparleiter <oberpar@linux.ibm.com>
      Cc: Sebastian Ott <sebott@linux.ibm.com>
      Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
      Cc: Yehezkel Bernat <YehezkelShB@gmail.com>
      Cc: rafael@kernel.org
      Acked-by: NCorey Minyard <minyard@acm.org>
      Acked-by: NDavid Kershner <david.kershner@unisys.com>
      Acked-by: NMark Brown <broonie@kernel.org>
      Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
      Acked-by: Wolfram Sang <wsa@the-dreams.de> # for the I2C parts
      Acked-by: NRob Herring <robh@kernel.org>
      Signed-off-by: NSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      418e3ea1
    • S
      acpi: utils: Cleanup acpi_dev_match_cb · e6374f6b
      Suzuki K Poulose 提交于
      The prototype of bus_find_device() will be unified with that of
      class_find_device() subsequently, but for this purpose the callback
      functions passed to it need to take (const void *) as the second
      argument.  Consequently, they cannot modify the memory pointed to by
      that argument which currently is not the case for acpi_dev_match_cb().
      However, acpi_dev_match_cb() really need not modify the "match" object
      passed to it, because acpi_dev_get_first_match_dev() which uses it via
      bus_find_device() can easily convert the result of bus_find_device()
      into the pointer to return.
      
      For this reason, update acpi_dev_match_cb() to avoid the redundant
      memory updates.
      
      Cc: Len Brown <lenb@kernel.org>
      Cc: linux-acpi@vger.kernel.org
      Signed-off-by: NSuzuki K Poulose <suzuki.poulose@arm.com>
      Reviewed-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e6374f6b
  14. 22 6月, 2019 3 次提交
  15. 20 6月, 2019 1 次提交
  16. 19 6月, 2019 2 次提交