On Fri, Jul 18, 2025, at 13:13, Naresh Kamboju wrote:
The following Boot regressions are noticed on the Linux next-20250708with gcc-13 and clang-20 toolchains for the dragonboard 410c device.
[ 12.629924] x5 : 0000000000000002 x4 : 00000000c0000000 x3 : 0000000000000001 [ 12.629939] x2 : 0000000000000002 x1 : ffffffffffffffde x0 : ffffffffffffffee [ 12.629956] Call trace: [ 12.629962] dev_pm_opp_put+0x24/0x58 (P) [ 12.629981] core_clks_enable+0x54/0x148 venus_core [ 12.630064] core_power_v1+0x78/0x90 venus_core [ 12.691130] venus_runtime_resume+0x6c/0x98 venus_core
[ 12.817608] Code: 910003fd f9000bf3 91004013 aa1303e0 (f9402821) All code ======== 0: 910003fd mov x29, sp 4: f9000bf3 str x19, [sp, #16] 8: 91004013 add x19, x0, #0x10 c: aa1303e0 mov x0, x19 10:* f9402821 ldr x1, [x1, #80] <-- trapping instruction
It's loading from 'x1', which is an error pointer ffffffffffffffde (-EISCONN). The caller was modified by Renjiang Han (added to Cc) in commit b179234b5e59 ("media: venus: pm_helpers: use opp-table for the frequency").
The new version of the code is now
static int core_clks_enable(struct venus_core *core) { const struct venus_resources *res = core->res; + struct device *dev = core->dev; + unsigned long freq = 0; + struct dev_pm_opp *opp; unsigned int i; int ret;
+ opp = dev_pm_opp_find_freq_ceil(dev, &freq); + dev_pm_opp_put(opp);
Where the 'opp' pointer is the error code and gets passed into dev_pm_opp_put() without checking for the error condition.
Arnd