accel/rocket: clks[].id fix - standalone patch, or would you prefer to split it out?

[Igor Paunovic]

Hi Jiaxing,

I have been working with the rocket NPU driver on RK3588 (Orange Pi 5
Plus) and ran into the missing core->clks[].id initialisation in
rocket_core_init().

I noticed it while reading the live clock tree rather than the source:
/sys/kernel/debug/clk/clk_summary shows four "fdab0000.npu" consumer
handles on aclk_npu0 - and likewise on aclk_npu1/aclk_npu2 for the other
two cores - while hclk_npu0, pclk_npu_root and scmi_clk_npu have no
"fdab0000.npu" consumer at all. The driver believes it owns four clocks
but really holds four handles to the AXI clock.

Before writing anything up I went through the lists, and I see you
already fix exactly this as part of

  [RFC PATCH v2 6/8] accel/rocket: add RK3576 NPU (RKNN) support
  Message-Id: <20260718031146.3368811-7-gahing at gahingwoo.com>

so I would rather ask you first than send something that looks like a
duplicate.

The reason I care: I would like to look into OPP/devfreq support for
rocket later on - Jonas Karlman mentioned it as future work in the
RK3568 thread - and today the driver holds no reference at all to the
clock that actually feeds the NPU ("npu", SCMI_CLK_NPU on RK3588). That
is in the way of any frequency scaling work. The NPU still runs anyway -
clk_summary shows scmi_clk_npu with the hardware enable bit set but no
Linux consumer, i.e. firmware keeps it running - so the bug is latent
rather than fatal.

Timing-wise this also seems like a natural moment to ask: Will has
already picked up the two iommu patches from your v2, and after
Alexey's review you mentioned a v3 respin of the accel patch. Since the
RK3576 inference issue is still being debugged, the clks[].id fix would
otherwise sit inside an RFC for a while, even though it is independent
of that work and the bug it fixes is in mainline today.

Would you prefer to:

 (a) split the clks[].id fix out of your series and send it standalone
     with a Fixes: tag? That way it can land independently of the RK3576
     enablement work and be backported. I would be glad to give it a
     Tested-by on RK3588 / Orange Pi 5 Plus.

 (b) or, if you would rather keep your series as it is, I can send the
     standalone fix with you on Cc and a note under the --- pointing at
     your patch.

Either works for me. I mostly want to avoid us duplicating effort, and
you posted it first.

Thanks,
Igor Paunovic