My impression is that this is just historical legacy, but I'm not
sure how much work a conversion to the new system would require.
I see lots of cpu_reset() calls scattered around the code.
To make it worse, TYPE_CPU do have a DeviceClass::reset method
implemented, but cpu_reset() won't call it because it bypasses
the Device reset system completely. I will do some git
archaeology work to try to find out why the code is this way.
On Mon, Mar 02, 2020 at 05:20:33PM +0000, Peter Maydell wrote:
> Hi; I've just noticed that although TYPE_CPU is a subclass of
> TYPE_DEVICE, it seems to implement its own reset method
> ('reset' field in CPUClass struct) rather than just using the
> DeviceClass's 'reset'.
>
> Is there a reason for doing this, or is it just historical legacy
> from TYPE_CPU originally not being a subclass of TYPE_DEVICE?
>
> I ask because I'd like to be able to use 3-phase reset in the Arm
> CPU, and I'm wondering whether it would be better to make TYPE_CPU
> just use Device's reset system, or to treat TYPE_CPU as its own
> base class and implement Resettable there. The former seems more
> straightforward, unless I'm missing something that means we
> really do need to have the reset method be different.
>
> thanks
> -- PMM
>
--
Eduardo
