CVE-2022-50491

In the Linux kernel, the following vulnerability has been resolved:

coresight: cti: Fix hang in ctidisablehw()

ctienablehw() and ctidisablehw() are called from an atomic context so shouldn't use runtime PM because it can result in a sleep when communicating with firmware.

Since commit 3c6656337852 ("Revert "firmware: arm_scmi: Add clock management to the SCMI power domain""), this causes a hang on Juno when running the Perf Coresight tests or running this command:

perf record -e cs_etm//u -- ls

This was also missed until the revert commit because pmruntimeput() was called with the wrong device until commit 692c9a499b28 ("coresight: cti: Correct the parameter for pmruntimeput")

With lock and scheduler debugging enabled the following is output:

coresight ctisys0: ctienablehw -- dev:ctisys0 parent: 20020000.cti BUG: sleeping function called from invalid context at drivers/base/power/runtime.c:1151 inatomic(): 1, irqsdisabled(): 128, nonblock: 0, pid: 330, name: perf-exec preemptcount: 2, expected: 0 RCU nest depth: 0, expected: 0 INFO: lockdep is turned off. irq event stamp: 0 hardirqs last enabled at (0): [<0000000000000000>] 0x0 hardirqs last disabled at (0): [<ffff80000822b394>] copyprocess+0xa0c/0x1948 softirqs last enabled at (0): [<ffff80000822b394>] copyprocess+0xa0c/0x1948 softirqs last disabled at (0): [<0000000000000000>] 0x0 CPU: 3 PID: 330 Comm: perf-exec Not tainted 6.0.0-00053-g042116d99298 #7 Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Sep 13 2022 Call trace: dumpbacktrace+0x134/0x140 showstack+0x20/0x58 dumpstacklvl+0x8c/0xb8 dump_stack+0x18/0x34 __might_resched+0x180/0x228 __might_sleep+0x50/0x88 __pmruntimeresume+0xac/0xb0 ctienable+0x44/0x120 coresightcontrolassocectdev+0xc0/0x150 coresightenablepath+0xb4/0x288 etmeventstart+0x138/0x170 etmeventadd+0x48/0x70 eventschedin.isra.122+0xb4/0x280 mergeschedin+0x1fc/0x3d0 visitgroupsmerge.constprop.137+0x16c/0x4b0 ctxschedin+0x114/0x1f0 perfeventschedin+0x60/0x90 ctxresched+0x68/0xb0 perfeventexec+0x138/0x508 beginnewexec+0x52c/0xd40 loadelfbinary+0x6b8/0x17d0 bprmexecve+0x360/0x7f8 doexecveat_common.isra.47+0x218/0x238 _arm64sysexecve+0x48/0x60 invokesyscall+0x4c/0x110 el0svccommon.constprop.4+0xfc/0x120 doel0svc+0x34/0xc0 el0svc+0x40/0x98 el0t64synchandler+0x98/0xc0 el0t64sync+0x170/0x174

Fix the issue by removing the runtime PM calls completely. They are not needed here because it must have already been done when building the path for a trace.

[ Fix build warnings ]