On 7/18/2025 7:28 PM, Arnd Bergmann wrote:
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.
Thank you for pointing it out. I have submitted the following patch to fix this issue. https://lore.kernel.org/linux-arm-msm/20250723-fallback_of_opp_table-v1-1-20...
Arnd