linux-stable.git/drivers/base/power, branch linux-5.0.y Linux kernel stable tree PM / core: Propagate dev->power.wakeup_path when no callbacks 2019-05-31T13:45:07+00:00 Ulf Hansson ulf.hansson@linaro.org 2019-04-10T09:55:16+00:00 414989cd9387ae2ed26228fdf31dd70fa17d7a7e [ Upstream commit dc351d4c5f4fe4d0f274d6d660227be0c3a03317 ] The dev->power.direct_complete flag may become set in device_prepare() in case the device don't have any PM callbacks (dev->power.no_pm_callbacks is set). This leads to a broken behaviour, when there is child having wakeup enabled and relies on its parent to be used in the wakeup path. More precisely, when the direct complete path becomes selected for the child in __device_suspend(), the propagation of the dev->power.wakeup_path becomes skipped as well. Let's address this problem, by checking if the device is a part the wakeup path or has wakeup enabled, then prevent the direct complete path from being used. Reported-by: Loic Pallardy <loic.pallardy@st.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> [ rjw: Comment cleanup ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit dc351d4c5f4fe4d0f274d6d660227be0c3a03317 ]

The dev->power.direct_complete flag may become set in device_prepare() in
case the device don't have any PM callbacks (dev->power.no_pm_callbacks is
set). This leads to a broken behaviour, when there is child having wakeup
enabled and relies on its parent to be used in the wakeup path.

More precisely, when the direct complete path becomes selected for the
child in __device_suspend(), the propagation of the dev->power.wakeup_path
becomes skipped as well.

Let's address this problem, by checking if the device is a part the wakeup
path or has wakeup enabled, then prevent the direct complete path from
being used.

Reported-by: Loic Pallardy <loic.pallardy@st.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
[ rjw: Comment cleanup ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
PM / Domains: Avoid a potential deadlock 2019-04-20T07:16:57+00:00 Jiada Wang jiada_wang@mentor.com 2019-03-12T06:51:28+00:00 8bd30e5e0ec594d6200448f0c2b889bd8bd28a5a [ Upstream commit 2071ac985d37efe496782c34318dbead93beb02f ] Lockdep warns that prepare_lock and genpd->mlock can cause a deadlock the deadlock scenario is like following: First thread is probing cs2000 cs2000_probe() clk_register() __clk_core_init() clk_prepare_lock() ----> acquires prepare_lock cs2000_recalc_rate() i2c_smbus_read_byte_data() rcar_i2c_master_xfer() dma_request_chan() rcar_dmac_of_xlate() rcar_dmac_alloc_chan_resources() pm_runtime_get_sync() __pm_runtime_resume() rpm_resume() rpm_callback() genpd_runtime_resume() ----> acquires genpd->mlock Second thread is attaching any device to the same PM domain genpd_add_device() genpd_lock() ----> acquires genpd->mlock cpg_mssr_attach_dev() of_clk_get_from_provider() __of_clk_get_from_provider() __clk_create_clk() clk_prepare_lock() ----> acquires prepare_lock Since currently no PM provider access genpd's critical section in .attach_dev, and .detach_dev callbacks, so there is no need to protect these two callbacks with genpd->mlock. This patch avoids a potential deadlock by moving out .attach_dev and .detach_dev from genpd->mlock, so that genpd->mlock won't be held when prepare_lock is acquired in .attach_dev and .detach_dev Signed-off-by: Jiada Wang <jiada_wang@mentor.com> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 2071ac985d37efe496782c34318dbead93beb02f ]

Lockdep warns that prepare_lock and genpd->mlock can cause a deadlock
the deadlock scenario is like following:
First thread is probing cs2000
cs2000_probe()
  clk_register()
    __clk_core_init()
      clk_prepare_lock()                            ----> acquires prepare_lock
        cs2000_recalc_rate()
          i2c_smbus_read_byte_data()
            rcar_i2c_master_xfer()
              dma_request_chan()
                rcar_dmac_of_xlate()
                  rcar_dmac_alloc_chan_resources()
                    pm_runtime_get_sync()
                      __pm_runtime_resume()
                        rpm_resume()
                          rpm_callback()
                            genpd_runtime_resume()   ----> acquires genpd->mlock

Second thread is attaching any device to the same PM domain
genpd_add_device()
  genpd_lock()                                       ----> acquires genpd->mlock
    cpg_mssr_attach_dev()
      of_clk_get_from_provider()
        __of_clk_get_from_provider()
          __clk_create_clk()
            clk_prepare_lock()                       ----> acquires prepare_lock

Since currently no PM provider access genpd's critical section
in .attach_dev, and .detach_dev callbacks, so there is no need to protect
these two callbacks with genpd->mlock.
This patch avoids a potential deadlock by moving out .attach_dev and .detach_dev
from genpd->mlock, so that genpd->mlock won't be held when prepare_lock is acquired
in .attach_dev and .detach_dev

Signed-off-by: Jiada Wang <jiada_wang@mentor.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
PM / wakeup: Rework wakeup source timer cancellation 2019-03-23T19:11:36+00:00 Viresh Kumar viresh.kumar@linaro.org 2019-03-08T09:53:11+00:00 c9c0e5f01245d6bf6779401a32f9f194e19deb87 commit 1fad17fb1bbcd73159c2b992668a6957ecc5af8a upstream. If wakeup_source_add() is called right after wakeup_source_remove() for the same wakeup source, timer_setup() may be called for a potentially scheduled timer which is incorrect. To avoid that, move the wakeup source timer cancellation from wakeup_source_drop() to wakeup_source_remove(). Moreover, make wakeup_source_remove() clear the timer function after canceling the timer to let wakeup_source_not_registered() treat unregistered wakeup sources in the same way as the ones that have never been registered. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Cc: 4.4+ <stable@vger.kernel.org> # 4.4+ [ rjw: Subject, changelog, merged two patches together ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 1fad17fb1bbcd73159c2b992668a6957ecc5af8a upstream.

If wakeup_source_add() is called right after wakeup_source_remove()
for the same wakeup source, timer_setup() may be called for a
potentially scheduled timer which is incorrect.

To avoid that, move the wakeup source timer cancellation from
wakeup_source_drop() to wakeup_source_remove().

Moreover, make wakeup_source_remove() clear the timer function after
canceling the timer to let wakeup_source_not_registered() treat
unregistered wakeup sources in the same way as the ones that have
never been registered.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Cc: 4.4+ <stable@vger.kernel.org> # 4.4+
[ rjw: Subject, changelog, merged two patches together ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
PM-runtime: Fix deadlock when canceling hrtimer 2019-02-21T09:29:00+00:00 Vincent Guittot vincent.guittot@linaro.org 2019-02-21T07:59:02+00:00 74fb44863084275b952f21ec6a024af0e2e75cb8 When rpm_resume() desactivates the autosuspend timer, it should only try to cancel hrtimer but not wait for the handler to finish, because both rpm_resume() and pm_suspend_timer_fn() take the power.lock. A deadlock is possible as follows: CPU0 CPU1 rpm_resume() spin_lock_irqsave pm_suspend_timer_fn() spin_lock_irqsave pm_runtime_deactivate_timer() hrtimer_cancel() It is sufficient to call hrtimer_try_to_cancel() from pm_runtime_deactivate_timer(), because dev->power.timer_expires reset to 0 by it, so use that function instead of hrtimer_cancel(). Fixes: 8234f6734c5d ("PM-runtime: Switch autosuspend over to using hrtimers") Reported-by: Sunzhaosheng Sun(Zhaosheng) <sunzhaosheng@hisilicon.com> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org> [ rjw: Changelog ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 
When rpm_resume() desactivates the autosuspend timer, it should only
try to cancel hrtimer but not wait for the handler to finish, because
both rpm_resume() and pm_suspend_timer_fn() take the power.lock.

A deadlock is possible as follows:

CPU0                              CPU1
rpm_resume()
  spin_lock_irqsave
                                  pm_suspend_timer_fn()
                                    spin_lock_irqsave
  pm_runtime_deactivate_timer()
    hrtimer_cancel()

It is sufficient to call hrtimer_try_to_cancel() from
pm_runtime_deactivate_timer(), because dev->power.timer_expires
reset to 0 by it, so use that function instead of hrtimer_cancel().

Fixes: 8234f6734c5d ("PM-runtime: Switch autosuspend over to using hrtimers")
Reported-by: Sunzhaosheng Sun(Zhaosheng) <sunzhaosheng@hisilicon.com>
Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
[ rjw: Changelog ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
PM-runtime: Fix deadlock with ktime_get() 2019-01-30T21:49:06+00:00 Vincent Guittot vincent.guittot@linaro.org 2019-01-30T17:26:02+00:00 15efb47dc560849d0c07db96fdad5121f2cf736e A deadlock has been seen when swicthing clocksources which use PM-runtime. The call path is: change_clocksource ... write_seqcount_begin ... timekeeping_update ... sh_cmt_clocksource_enable ... rpm_resume pm_runtime_mark_last_busy ktime_get do read_seqcount_begin while read_seqcount_retry .... write_seqcount_end Although we should be safe because we haven't yet changed the clocksource at that time, we can't do that because of seqcount protection. Use ktime_get_mono_fast_ns() instead which is lock safe for such cases. With ktime_get_mono_fast_ns, the timestamp is not guaranteed to be monotonic across an update and as a result can goes backward. According to update_fast_timekeeper() description: "In the worst case, this can result is a slightly wrong timestamp (a few nanoseconds)". For PM-runtime autosuspend, this means only that the suspend decision may be slightly suboptimal. Fixes: 8234f6734c5d ("PM-runtime: Switch autosuspend over to using hrtimers") Reported-by: Biju Das <biju.das@bp.renesas.com> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 
A deadlock has been seen when swicthing clocksources which use
PM-runtime.  The call path is:

change_clocksource
    ...
    write_seqcount_begin
    ...
    timekeeping_update
        ...
        sh_cmt_clocksource_enable
            ...
            rpm_resume
                pm_runtime_mark_last_busy
                    ktime_get
                        do
                            read_seqcount_begin
                        while read_seqcount_retry
    ....
    write_seqcount_end

Although we should be safe because we haven't yet changed the
clocksource at that time, we can't do that because of seqcount
protection.

Use ktime_get_mono_fast_ns() instead which is lock safe for such
cases.

With ktime_get_mono_fast_ns, the timestamp is not guaranteed to be
monotonic across an update and as a result can goes backward.
According to update_fast_timekeeper() description: "In the worst
case, this can result is a slightly wrong timestamp (a few
nanoseconds)". For PM-runtime autosuspend, this means only that
the suspend decision may be slightly suboptimal.

Fixes: 8234f6734c5d ("PM-runtime: Switch autosuspend over to using hrtimers")
Reported-by: Biju Das <biju.das@bp.renesas.com>
Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Merge branches 'pm-cpuidle', 'pm-cpufreq' and 'pm-sleep' 2019-01-11T09:09:51+00:00 Rafael J. Wysocki rafael.j.wysocki@intel.com 2019-01-11T09:09:51+00:00 343e60e52a3a093bb7baeca441789724fcac4bb5 * pm-cpuidle: doc: trace: fix reference to cpuidle documentation file cpuidle / Documentation: Update cpuidle MAINTAINERS entry * pm-cpufreq: cpufreq: scmi: Fix frequency invariance in slow path cpufreq: check if policy is inactive early in __cpufreq_get() cpufreq: scpi/scmi: Fix freeing of dynamic OPPs cpufreq / Documentation: Update cpufreq MAINTAINERS entry * pm-sleep: PM: sleep: call devfreq suspend/resume 
* pm-cpuidle:
  doc: trace: fix reference to cpuidle documentation file
  cpuidle / Documentation: Update cpuidle MAINTAINERS entry

* pm-cpufreq:
  cpufreq: scmi: Fix frequency invariance in slow path
  cpufreq: check if policy is inactive early in __cpufreq_get()
  cpufreq: scpi/scmi: Fix freeing of dynamic OPPs
  cpufreq / Documentation: Update cpufreq MAINTAINERS entry

* pm-sleep:
  PM: sleep: call devfreq suspend/resume
PM-runtime: Fix autosuspend_delay on 32bits arch 2019-01-10T09:55:52+00:00 Vincent Guittot vincent.guittot@linaro.org 2019-01-10T09:00:40+00:00 ca27e4cd0bdd87e33fda38e6e3d18d36d54356d4 Cast autosuspend_delay to u64 to make sure that the full computation of 'expires' or slack will be done in u64, even on 32bits arch. Otherwise, any delay greater than 2^31 nsec can overflow if signed 32bits is used when converting delay from msec to nsec. Fixes: 8234f6734c5d (PM-runtime: Switch autosuspend over to using hrtimers) Reported-by: Tony Lindgren <tony@atomide.com> Tested-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 
Cast autosuspend_delay to u64 to make sure that the full computation
of 'expires' or slack will be done in u64, even on 32bits arch.

Otherwise, any delay greater than 2^31 nsec can overflow if signed
32bits is used when converting delay from msec to nsec.

Fixes: 8234f6734c5d (PM-runtime: Switch autosuspend over to using hrtimers)
Reported-by: Tony Lindgren <tony@atomide.com>
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
PM-runtime: Fix 'jiffies' in comments after switch to hrtimers 2019-01-10T09:55:52+00:00 Ladislav Michl ladis@linux-mips.org 2019-01-09T23:19:44+00:00 1f7b7081568bca281f4ef42096206180cfaced00 PM-runtime now uses the hrtimers infrastructure for autosuspend, however comments still reference 'jiffies'. Fixes: 8234f6734c5d (PM-runtime: Switch autosuspend over to using hrtimers) Signed-off-by: Ladislav Michl <ladis@linux-mips.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 
PM-runtime now uses the hrtimers infrastructure for autosuspend, however
comments still reference 'jiffies'.

Fixes: 8234f6734c5d (PM-runtime: Switch autosuspend over to using hrtimers)
Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
PM: sleep: call devfreq suspend/resume 2019-01-02T22:07:41+00:00 Lukasz Luba l.luba@partner.samsung.com 2018-12-05T11:05:55+00:00 6e863844ad6effecac92a67a43b8467a8c2e129f Devfreq framework supports suspend of its devices. Call the the devfreq interface and allow devfreq devices preserve/restore their states during suspend/resume. Suggested-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: Lukasz Luba <l.luba@partner.samsung.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 
Devfreq framework supports suspend of its devices.
Call the the devfreq interface and allow devfreq devices
preserve/restore their states during suspend/resume.

Suggested-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Lukasz Luba <l.luba@partner.samsung.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Merge tag 'rtc-4.21' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux 2019-01-01T21:24:31+00:00 Linus Torvalds torvalds@linux-foundation.org 2019-01-01T21:24:31+00:00 28e8c4bc8eb483c22d977e147a0b98fc63efadf7 Pull RTC updates from Alexandre Belloni: "Subsystem: - new %ptR printk format - rename core files - allow registration of multiple nvmem devices New driver: - i.MX system controller RTC Driver updates: - abx80x: handle voltage ioctls, correct binding doc - m41t80: correct month in alarm reads - pcf85363: add pcf85263 support - pcf8523: properly handle battery low flag - s3c: limit alarm to one year in the future as ALMYEAR is broken - sun6i: rework clock output binding" * tag 'rtc-4.21' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux: (54 commits) rtc: rename core files rtc: nvmem: fix possible use after free rtc: add i.MX system controller RTC support dt-bindings: fsl: scu: add rtc binding rtc: pcf2123: Add Microcrystal rv2123 rtc: class: reimplement devm_rtc_device_register rtc: enforce rtc_timer_init private_data type rtc: abx80x: Implement RTC_VL_READ,CLR ioctls rtc: pcf85363: Add support for NXP pcf85263 rtc dt-bindings: rtc: pcf85363: Document pcf85263 real-time clock rtc: pcf8523: don't return invalid date when battery is low dt-bindings: rtc: use a generic node name for ds1307 PM: Switch to use %ptR m68k/mac: Switch to use %ptR Input: hp_sdc_rtc - Switch to use %ptR rtc: tegra: Switch to use %ptR rtc: s5m: Switch to use %ptR rtc: s3c: Switch to use %ptR rtc: rx8025: Switch to use %ptR rtc: rx6110: Switch to use %ptR ... 
Pull RTC updates from Alexandre Belloni:
 "Subsystem:
   - new %ptR printk format
   - rename core files
   - allow registration of multiple nvmem devices

  New driver:
   - i.MX system controller RTC

  Driver updates:
   - abx80x: handle voltage ioctls, correct binding doc
   - m41t80: correct month in alarm reads
   - pcf85363: add pcf85263 support
   - pcf8523: properly handle battery low flag
   - s3c: limit alarm to one year in the future as ALMYEAR is broken
   - sun6i: rework clock output binding"

* tag 'rtc-4.21' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux: (54 commits)
  rtc: rename core files
  rtc: nvmem: fix possible use after free
  rtc: add i.MX system controller RTC support
  dt-bindings: fsl: scu: add rtc binding
  rtc: pcf2123: Add Microcrystal rv2123
  rtc: class: reimplement devm_rtc_device_register
  rtc: enforce rtc_timer_init private_data type
  rtc: abx80x: Implement RTC_VL_READ,CLR ioctls
  rtc: pcf85363: Add support for NXP pcf85263 rtc
  dt-bindings: rtc: pcf85363: Document pcf85263 real-time clock
  rtc: pcf8523: don't return invalid date when battery is low
  dt-bindings: rtc: use a generic node name for ds1307
  PM: Switch to use %ptR
  m68k/mac: Switch to use %ptR
  Input: hp_sdc_rtc - Switch to use %ptR
  rtc: tegra: Switch to use %ptR
  rtc: s5m: Switch to use %ptR
  rtc: s3c: Switch to use %ptR
  rtc: rx8025: Switch to use %ptR
  rtc: rx6110: Switch to use %ptR
  ...