00:27 <CyReVolt> looks like the DDR PHY on the RK356x (and possibly other recent SoCs) is coming from INNOSILICON https://innosilicon.shop/html/ip-solution/1.html

06:43 <mmind00> diederik: does https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f0f2b992d818 help for that LED thing?

09:07 <diederik> mmind00: AFAICT no. That commit is part of 6.16-rc7 and the kernel I tested with is (based on) 6.16-rc7

09:08 <mmind00> diederik: ok, good to know

09:08 <diederik> But I'll do some additional checking/tests to make sure as it indeed sound very applicable

09:08 <mmind00> was just suggested on #armlinux yesterday evening

09:10 <diederik> The main logical reason why not is that that commit seems connected to detach/remove which I *assume* did/does not happen in my case

09:12 <diederik> But the mere enabling of PROVE_LOCKING and dyndbg did alter what went wrong. It turned out to be very useful, but it seems a different problem then I initially encountered

09:14 <diederik> "There is a corresponding deadlock on the open/register side of things (and that one is reported by lockdep), but it requires a race while this one is deterministic." <- that could be my actual problem

09:18 <warpme> detlevc : is see new ver of add-vdpu381-and-383-to-rkvdec-v2 Should i give it try & report or rather it is too early wip to play with?

09:19 <warpme> is->I

09:44 <diederik> mmind00: Now I'm sure that commit doesn't help. My first/initial 6.16-rc7 kernel was just upstream 6.16-rc7 and I first removed the WAN trigger, then the LAN triggers, but it was only after removing both WAN and LAN triggers that the "hung task" problem went away

09:46 <diederik> To find out why that was, I built a kernel with PROVE_LOCKING and that's when the OOPSies started

10:29 <robmur01> diederik: yup, I suspect that race is exactly what your system manages to hit - userspace does the ioctl that leads to stmmac_open()->phy_led_triggers_register(), while the ledtrig_netdev module is still loading and registering/activating its triggers on another thread

10:41 <robmur01> one might consider that unlikely on paper, but here it is

10:44 <robmur01> might be enough to just reply to the patch to show that deadlock is real

10:45 <robmur01> (although it looks like the -next commit that Adrian pointed to should indeed make sdhci happy for now if you still fancy double-checking lockdep)

11:04 <diederik> robmur01: I seem to be good at hitting (unlikely) issues that others don't ;-P

11:05 <robmur01> at least it's a valuable skill for the health of Linux, even if not for you personally :)

11:06 <diederik> yep :) There are a few others still open and some which already have a fix :)

11:09 <diederik> Next up for me is building a kernel with the mmc commit Adrian pointed at and then I can play with PRINTK_CALLER in the mean time to see if that brings new insights.

11:10 <diederik> And when the new kernel is built, try to see if that solves the immediate problem ... which potentially brings the original issue back but hopefully then with more 'debug info'

14:18 <detlevc> warpme_: too early still :p

14:19 <warpme_> ah ok. just keeping eye on your so far great work !

14:20 <detlevc> Thanks ! I'm currently moving the calculation of hevc RPS ST and LT parameters in the driver (which will help with ffmpeg support)

14:50 <TahomaSoft> Thank you the folks here that gave me excellent comments and suggestions on improving my patch request for LinkStar H68K