diff options
| author | Myeonghun Pak <mhun512@gmail.com> | 2026-06-23 17:42:23 +0900 |
|---|---|---|
| committer | Herbert Xu <herbert@gondor.apana.org.au> | 2026-07-05 13:27:15 +0800 |
| commit | f8c24e6899e263073fbbeb07fadc1af85ec492f5 (patch) | |
| tree | dbf4b9b32e9b5b2b4168faf0eb69665b38c2d59c /tools/perf/scripts/python/flamegraph.py | |
| parent | ba088974419326daf46c5dc03e2cf6ab6ab701f7 (diff) | |
hwrng: omap - Fix probe error path cleanup
omap_rng_probe() enables runtime PM before acquiring and enabling the
functional clocks. Several later error paths returned or unwound without
undoing all state acquired so far.
If pm_runtime_resume_and_get() failed, the driver returned through the
generic ioremap error label and left runtime PM enabled. If either clock
lookup returned -EPROBE_DEFER, the function returned directly and skipped
the runtime PM cleanup; the register clock defer path could also leave the
already enabled functional clock prepared.
Route these failures through the existing unwind labels so each path only
undoes resources that were acquired successfully. Keep the resume failure
path limited to pm_runtime_disable(), and use the later labels only after
the runtime PM usage count or clocks have been acquired.
This issue was identified during our ongoing static-analysis research while
reviewing kernel code.
Fixes: 61dc0a446e5d ("hwrng: omap - Fix assumption that runtime_get_sync will always succeed")
Fixes: 43ec540e6f9b ("hwrng: omap - move clock related code to omap_rng_probe()")
Fixes: b166be004491 ("hwrng: omap - Fix clock resource by adding a register clock")
Co-developed-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Diffstat (limited to 'tools/perf/scripts/python/flamegraph.py')
0 files changed, 0 insertions, 0 deletions
