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
