linux-stable.git/drivers/base/power, branch v3.16.52

PM / QoS: return -EINVAL for bogus strings

2017-10-12T14:28:05+00:00

commit 2ca30331c156ca9e97643ad05dd8930b8fe78b01 upstream.

In the current code, if the user accidentally writes a bogus command to
this sysfs file, then we set the latency tolerance to an uninitialized
variable.

Fixes: 2d984ad132a8 (PM / QoS: Introcuce latency tolerance device PM QoS type)
Signed-off-by: Dan Carpenter 
Acked-by: Pavel Machek 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Ben Hutchings

PM / Domains: Fix unsafe iteration over modified list of device links

2017-10-12T14:27:56+00:00

commit c6e83cac3eda5f7dd32ee1453df2f7abb5c6cd46 upstream.

pm_genpd_remove_subdomain() iterates over domain's master_links list and
removes matching element thus it has to use safe version of list
iteration.

Fixes: f721889ff65a ("PM / Domains: Support for generic I/O PM domains (v8)")
Signed-off-by: Krzysztof Kozlowski 
Acked-by: Ulf Hansson 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Ben Hutchings

PM / QoS: Fix memory leak on resume_latency.notifiers

2017-06-05T20:17:11+00:00

commit e84b4a84e52d4cd8770b4242cd09df0133333f63 upstream.

Since commit 2d984ad132a8 (PM / QoS: Introcuce latency tolerance device
PM QoS type) we reassign "c" to point at qos->latency_tolerance before
freeing c->notifiers, but the notifiers field of latency_tolerance is
never used.

Restore the original behaviour of freeing the notifiers pointer on
qos->resume_latency, which is used, and fix the following kmemleak
warning.

unreferenced object 0xed9dba00 (size 64):
  comm "kworker/0:1", pid 36, jiffies 4294670128 (age 15202.983s)
  hex dump (first 32 bytes):
    00 00 00 00 04 ba 9d ed 04 ba 9d ed 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [] kmemleak_alloc+0x74/0xb8
    [] kmem_cache_alloc_trace+0x170/0x25c
    [] dev_pm_qos_constraints_allocate+0x3c/0xe4
    [] __dev_pm_qos_add_request+0x84/0x1a0
    [] dev_pm_qos_add_request+0x3c/0x54
    [] usb_hub_create_port_device+0x110/0x2b8
    [] hub_probe+0xadc/0xc80
    [] usb_probe_interface+0x1b4/0x260
    [] driver_probe_device+0x198/0x40c
    [] __device_attach_driver+0x8c/0x98
    [] bus_for_each_drv+0x8c/0x9c
    [] __device_attach+0x98/0x138
    [] device_initial_probe+0x14/0x18
    [] bus_probe_device+0x30/0x88
    [] device_add+0x430/0x554
    [] usb_set_configuration+0x660/0x6fc

Fixes: 2d984ad132a8 (PM / QoS: Introcuce latency tolerance device PM QoS type)
Signed-off-by: John Keeping 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Ben Hutchings

PM / sleep: don't suspend parent when async child suspend_{noirq, late} fails

2017-02-23T03:54:32+00:00

commit 6f75c3fd56daf547d684127a7f83c283c3c160d1 upstream.

Consider two devices, A and B, where B is a child of A, and B utilizes
asynchronous suspend (it does not matter whether A is sync or async). If
B fails to suspend_noirq() or suspend_late(), or is interrupted by a
wakeup (pm_wakeup_pending()), then it aborts and sets the async_error
variable. However, device A does not (immediately) check the async_error
variable; it may continue to run its own suspend_noirq()/suspend_late()
callback. This is bad.

We can resolve this problem by doing our error and wakeup checking
(particularly, for the async_error flag) after waiting for children to
suspend, instead of before. This also helps align the logic for the noirq and
late suspend cases with the logic in __device_suspend().

It's easy to observe this erroneous behavior by, for example, forcing a
device to sleep a bit in its suspend_noirq() (to ensure the parent is
waiting for the child to complete), then return an error, and watch the
parent suspend_noirq() still get called. (Or similarly, fake a wakeup
event at the right (or is it wrong?) time.)

Fixes: de377b397272 (PM / sleep: Asynchronous threads for suspend_late)
Fixes: 28b6fd6e3779 (PM / sleep: Asynchronous threads for suspend_noirq)
Reported-by: Jeffy Chen 
Signed-off-by: Brian Norris 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Ben Hutchings

PM / sleep: Handle failures in device_suspend_late() consistently

2016-08-22T21:38:03+00:00

commit 3a17fb329da68cb00558721aff876a80bba2fdb9 upstream.

Grygorii Strashko reports:

 The PM runtime will be left disabled for the device if its
 .suspend_late() callback fails and async suspend is not allowed
 for this device. In this case device will not be added in
 dpm_late_early_list and dpm_resume_early() will ignore this
 device, as result PM runtime will be disabled for it forever
 (side effect: after 8 subsequent failures for the same device
 the PM runtime will be reenabled due to disable_depth overflow).

To fix this problem, add devices to dpm_late_early_list regardless
of whether or not device_suspend_late() returns errors for them.

That will ensure failures in there to be handled consistently for
all devices regardless of their async suspend/resume status.

Reported-by: Grygorii Strashko 
Tested-by: Grygorii Strashko 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Ben Hutchings

PM / Runtime: Fix error path in pm_runtime_force_resume()

2016-08-22T21:37:51+00:00

commit 0ae3aeefabbeef26294e7a349b51f1c761d46c9f upstream.

As pm_runtime_set_active() may fail because the device's parent isn't
active, we can end up executing the ->runtime_resume() callback for the
device when it isn't allowed.

Fix this by invoking pm_runtime_set_active() before running the callback
and let's also deal with the error code.

Fixes: 37f204164dfb (PM: Add pm_runtime_suspend|resume_force functions)
Signed-off-by: Ulf Hansson 
Reviewed-by: Linus Walleij 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Ben Hutchings

PM / Sleep: fix async suspend_late/freeze_late error handling

2014-11-13T11:48:48+00:00

commit 246ef766743618a7cab059d6c4993270075b173e upstream.

If an asynchronous suspend_late or freeze_late callback fails
during the SUSPEND, FREEZE or QUIESCE phases, we don't propagate the
corresponding error correctly, in effect ignoring the error and
continuing the suspend-to-ram/hibernation. During suspend-to-ram this
could leave some devices without a valid saved context, leading to a
failure to reinitialize them during resume. During hibernation this
could leave some devices active interfeering with the creation /
restoration of the hibernation image. Also this could leave the
corresponding devices without a valid saved context and failure to
reinitialize them during resume.

Fixes: de377b397272 (PM / sleep: Asynchronous threads for suspend_late)
Signed-off-by: Imre Deak 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Luis Henriques

PM / clk: Fix crash in clocks management code if !CONFIG_PM_RUNTIME

2014-11-03T10:52:06+00:00

commit a968bed78b549b4c61d4a46e59161fc1f60f96a6 upstream.

Unlike the clocks management code for runtime PM, the code used for
system suspend does not check the pm_clock_entry.status field.
If pm_clk_acquire() failed, ce->status will be PCE_STATUS_ERROR, and
ce->clk will be a negative error code (e.g. 0xfffffffe = -2 = -ENOENT).

Depending on the clock implementation, suspend or resume may crash with:

    Unable to handle kernel NULL pointer dereference at virtual address 00000026

(CCF clk_disable() has an IS_ERR_OR_NULL() check, while CCF clk_enable()
 only has a NULL check; pre-CCF implementations may behave differently)

While just checking for PCE_STATUS_ERROR would be sufficient, it doesn't
hurt to use the same state machine as is done for runtime PM, as this
makes the two versions more similar, and eligible for a future
consolidation.

Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Luis Henriques

Merge branch 'pm-sleep'

2014-06-12T11:43:08+00:00

* pm-sleep:
  PM / sleep: trace events for device PM callbacks
  PM / sleep: trace events for suspend/resume

PM / sleep: trace events for device PM callbacks

2014-06-11T00:16:48+00:00

Adds two trace events which supply the same info that initcall_debug
provides, but via ftrace instead of dmesg. The existing initcall_debug
calls require the pm_print_times_enabled var to be set (either via
sysfs or via the kernel cmd line). The new trace events provide all the
same info as the initcall_debug prints but with less overhead, and also
with coverage of device prepare and complete device callbacks.

These events replace the device_pm_report_time event (which has been
removed). device_pm_callback_start is called first and provides the device
and callback info. device_pm_callback_end is called after with the
device name and error info. The time and pid are gathered from the trace
data headers.

Signed-off-by: Todd Brandt 
Signed-off-by: Rafael J. Wysocki