Re: [RFC PATCH 1/2] hw/misc/k230_rmu: add Kendryte K230 Reset Management Unit model

[Junze Cao <caojunze424@gmail.com>]

Hi Wang,

Thanks for working on the K230 RMU model.

I reviewed this series against the K230 TRM and the upstream Linux
reset-k230 driver. The series builds and the supplied qtest passes, but
I found several issues that should be addressed in v2.

1. The RMU currently acknowledges reset requests without actually
resetting the target devices. Please connect at least the existing K230
watchdog devices and add a qtest which verifies that their state is
reset through the RMU.

2. The register reset state does not match the TRM. Please initialize
each modelled register with its documented reset value and update the
reset-value test accordingly.

3. Some register access permissions and reset types are incorrect. In
particular, some upper SW_DONE reset lines cannot be changed, reserved
bits are writable, and CPU1 is treated as self-clearing even though it
requires separate assert and deassert operations.

4. Patch 1 adds k230-rmu-test while the K230 machine still uses the
unimplemented RMU stub. K230_RMU is enabled and wired only by patch 2,
so patch 1 cannot pass its own test when checked out independently.
Please reorder the changes, move the test to patch 2, or squash the two
patches.

5. The new source, header and qtest files should be added to the K230
section in MAINTAINERS. Please address the checkpatch errors and
warnings before sending v2 as well.

6. Please consider modelling the reset timing registers. At minimum,
their reset values and writable fields should be represented. Real-time
delays may remain simplified if the zero-latency behavior is documented
and preserves guest-visible ordering.

7. Please add coverage for the corrected reset values, CPU1
transitions, upper SW_DONE fields, reserved bits, and reset propagation
to the watchdogs.

Regards,
Junze Cao