On Wed, 31 Jan 2024 at 03:44, Zhao Liu <zhao1....@intel.com> wrote: > > On Fri, Jan 19, 2024 at 04:35:12PM +0000, Peter Maydell wrote: > > Date: Fri, 19 Jan 2024 16:35:12 +0000 > > From: Peter Maydell <peter.mayd...@linaro.org> > > Subject: [PATCH 5/5] hw/core: Remove transitional infrastructure from > > BusClass > > X-Mailer: git-send-email 2.34.1 > > > > BusClass currently has transitional infrastructure to support > > subclasses which implement the legacy BusClass::reset method rather > > than the Resettable interface. We have now removed all the users of > > BusClass::reset in the tree, so we can remove the transitional > > infrastructure. > > > > Signed-off-by: Peter Maydell <peter.mayd...@linaro.org> > > --- > > include/hw/qdev-core.h | 2 -- > > hw/core/bus.c | 67 ------------------------------------------ > > 2 files changed, 69 deletions(-) > > Reviewed-by: Zhao Liu <zhao1....@intel.com> > > It seems the similar cleanup for DeviceClass needs a lot of effort.
Yes and no. It's true that there are a lot of DeviceClass subclasses that implement the legacy reset method still. However, they are all "leaf" classes which provide a single reset method, and don't need to either chain up to a parent class reset implementation or allow a child class to inherit from them. So they don't affect any other classes in the system or block any other classes from being able to use a full three-phase reset. So I'm not too worried if we continue to have a lot of these leaf classes: the old reset method is then just a different way of having a device with a reset 'hold' method and no others. I did an earlier round of refactoring back in 2022 that did the cleanup of the non-leaf classes and the classes that need to chain up to their parent class reset, which mostly updated all of that kind of class to 3-phase. The one exception is that we still have a single user of device_class_set_parent_reset() in the s390 CPU, which is awkward to deal with because it interacts with an s390-specific handling of different levels of reset. I also want to look at providing a 3-phase equivalent of the qdev_register_reset() API at some point: that one is definitely blocking some useful improvements, including dealing with the vfio ordering issue, and also would let me clean up some M-profile ARM CPU reset hacks. thanks -- PMM
