linux-stable.git/drivers/base/power, branch v6.1.78

PM: sleep: Fix possible deadlocks in core system-wide PM code

2024-02-01T00:17:09+00:00

[ Upstream commit 7839d0078e0d5e6cc2fa0b0dfbee71de74f1e557 ]

It is reported that in low-memory situations the system-wide resume core
code deadlocks, because async_schedule_dev() executes its argument
function synchronously if it cannot allocate memory (and not only in
that case) and that function attempts to acquire a mutex that is already
held.  Executing the argument function synchronously from within
dpm_async_fn() may also be problematic for ordering reasons (it may
cause a consumer device's resume callback to be invoked before a
requisite supplier device's one, for example).

Address this by changing the code in question to use
async_schedule_dev_nocall() for scheduling the asynchronous
execution of device suspend and resume functions and to directly
run them synchronously if async_schedule_dev_nocall() returns false.

Link: https://lore.kernel.org/linux-pm/ZYvjiqX6EsL15moe@perf/
Reported-by: Youngmin Nam 
Signed-off-by: Rafael J. Wysocki 
Reviewed-by: Stanislaw Gruszka 
Tested-by: Youngmin Nam 
Reviewed-by: Ulf Hansson 
Cc: 5.7+  # 5.7+: 6aa09a5bccd8 async: Split async_schedule_node_domain()
Cc: 5.7+  # 5.7+: 7d4b5d7a37bd async: Introduce async_schedule_dev_nocall()
Cc: 5.7+  # 5.7+
Signed-off-by: Sasha Levin

PM: core: Remove unnecessary (void *) conversions

2024-02-01T00:17:09+00:00

[ Upstream commit 73d73f5ee7fb0c42ff87091d105bee720a9565f1 ]

Assignments from pointer variables of type (void *) do not require
explicit type casts, so remove such type cases from the code in
drivers/base/power/main.c where applicable.

Signed-off-by: Li zeming 
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki 
Stable-dep-of: 7839d0078e0d ("PM: sleep: Fix possible deadlocks in core system-wide PM code")
Signed-off-by: Sasha Levin

rtc: Extend timeout for waiting for UIP to clear to 1s

2024-02-01T00:17:01+00:00

commit cef9ecc8e938dd48a560f7dd9be1246359248d20 upstream.

Specs don't say anything about UIP being cleared within 10ms. They
only say that UIP won't occur for another 244uS. If a long NMI occurs
while UIP is still updating it might not be possible to get valid
data in 10ms.

This has been observed in the wild that around s2idle some calls can
take up to 480ms before UIP is clear.

Adjust callers from outside an interrupt context to wait for up to a
1s instead of 10ms.

Cc:   # 6.1.y
Fixes: ec5895c0f2d8 ("rtc: mc146818-lib: extract mc146818_avoid_UIP")
Reported-by: Carsten Hatger 
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217626
Tested-by: Mateusz Jończyk 
Reviewed-by: Mateusz Jończyk 
Acked-by: Mateusz Jończyk 
Signed-off-by: Mario Limonciello 
Link: https://lore.kernel.org/r/20231128053653.101798-5-mario.limonciello@amd.com
Signed-off-by: Alexandre Belloni 
Signed-off-by: Greg Kroah-Hartman

rtc: Add support for configuring the UIP timeout for RTC reads

2024-02-01T00:17:01+00:00

commit 120931db07b49252aba2073096b595482d71857c upstream.

The UIP timeout is hardcoded to 10ms for all RTC reads, but in some
contexts this might not be enough time. Add a timeout parameter to
mc146818_get_time() and mc146818_get_time_callback().

If UIP timeout is configured by caller to be >=100 ms and a call
takes this long, log a warning.

Make all callers use 10ms to ensure no functional changes.

Cc:   # 6.1.y
Fixes: ec5895c0f2d8 ("rtc: mc146818-lib: extract mc146818_avoid_UIP")
Signed-off-by: Mario Limonciello 
Tested-by: Mateusz Jończyk 
Reviewed-by: Mateusz Jończyk 
Acked-by: Mateusz Jończyk 
Link: https://lore.kernel.org/r/20231128053653.101798-4-mario.limonciello@amd.com
Signed-off-by: Alexandre Belloni 
Signed-off-by: Greg Kroah-Hartman

PM: sleep: wakeirq: fix wake irq arming

2023-08-03T08:24:16+00:00

commit 8527beb12087238d4387607597b4020bc393c4b4 upstream.

The decision whether to enable a wake irq during suspend can not be done
based on the runtime PM state directly as a driver may use wake irqs
without implementing runtime PM. Such drivers specifically leave the
state set to the default 'suspended' and the wake irq is thus never
enabled at suspend.

Add a new wake irq flag to track whether a dedicated wake irq has been
enabled at runtime suspend and therefore must not be enabled at system
suspend.

Note that pm_runtime_enabled() can not be used as runtime PM is always
disabled during late suspend.

Fixes: 69728051f5bf ("PM / wakeirq: Fix unbalanced IRQ enable for wakeirq")
Cc: 4.16+  # 4.16+
Signed-off-by: Johan Hovold 
Reviewed-by: Tony Lindgren 
Tested-by: Tony Lindgren 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

PM: domains: Move the verification of in-params from genpd_add_device()

2023-07-19T14:21:01+00:00

[ Upstream commit 4384a70c8813e8573d1841fd94eee873f80a7e1a ]

Commit f38d1a6d0025 ("PM: domains: Allocate governor data dynamically
based on a genpd governor") started to use the in-parameters in
genpd_add_device(), without first doing a verification of them.

This isn't really a big problem, as most callers do a verification already.

Therefore, let's drop the verification from genpd_add_device() and make
sure all the callers take care of it instead.

Reported-by: Dan Carpenter 
Fixes: f38d1a6d0025 ("PM: domains: Allocate governor data dynamically based on a genpd governor")
Signed-off-by: Ulf Hansson 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin

PM: domains: fix integer overflow issues in genpd_parse_state()

2023-07-19T14:21:00+00:00

[ Upstream commit e5d1c8722083f0332dcd3c85fa1273d85fb6bed8 ]

Currently, while calculating residency and latency values, right
operands may overflow if resulting values are big enough.

To prevent this, albeit unlikely case, play it safe and convert
right operands to left ones' type s64.

Found by Linux Verification Center (linuxtesting.org) with static
analysis tool SVACE.

Fixes: 30f604283e05 ("PM / Domains: Allow domain power states to be read from DT")
Signed-off-by: Nikita Zhandarovich 
Acked-by: Ulf Hansson 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin

PM: domains: fix memory leak with using debugfs_lookup()

2023-03-10T08:33:52+00:00

[ Upstream commit 0b6200e1e9f53dabdc30d0f6c51af9a5f664d32b ]

When calling debugfs_lookup() the result must have dput() called on it,
otherwise the memory will leak over time.  To make things simpler, just
call debugfs_lookup_and_remove() instead which handles all of the logic
at once.

Signed-off-by: Greg Kroah-Hartman 
Reviewed-by: Ulf Hansson 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin

PM: runtime: Do not call __rpm_callback() from rpm_idle()

2022-12-31T12:31:59+00:00

[ Upstream commit bc80c2e438dcbfcf748452ec0f7ad5b79ff3ad88 ]

Calling __rpm_callback() from rpm_idle() after adding device links
support to the former is a clear mistake.

Not only it causes rpm_idle() to carry out unnecessary actions, but it
is also against the assumption regarding the stability of PM-runtime
status across __rpm_callback() invocations, because rpm_suspend() and
rpm_resume() may run in parallel with __rpm_callback() when it is called
by rpm_idle() and the device's PM-runtime status can be updated by any
of them.

Fixes: 21d5c57b3726 ("PM / runtime: Use device links")
Link: https://lore.kernel.org/linux-pm/36aed941-a73e-d937-2721-4f0decd61ce0@quicinc.com
Signed-off-by: Rafael J. Wysocki 
Reviewed-by: Adrian Hunter 
Signed-off-by: Sasha Levin

PM: domains: Fix handling of unavailable/disabled idle states

2022-10-26T11:28:39+00:00

Platforms can provide the information about the availability of each
idle states via status flag. Platforms may have to disable one or more
idle states for various reasons like broken firmware or other unmet
dependencies.

Fix handling of such unavailable/disabled idle states by ignoring them
while parsing the states.

Fixes: a3381e3a65cb ("PM / domains: Fix up domain-idle-states OF parsing")
Signed-off-by: Sudeep Holla 
Reviewed-by: Ulf Hansson 
Signed-off-by: Rafael J. Wysocki