On Thu, 5 Mar 2026 at 09:25, Markus Armbruster <[email protected]> wrote: > > Disentangling reset is extremely painful -- I don't even know > > what it ought to be doing. Maybe propagating along the QOM tree? > > I think this would make more sense. Unlike the qtree, the QOM > composition tree contains all devices, and reflects the actual > composition. It's certainly closer to the real reset tree than the > qtree is. Is it close enough? I don't know. If yes, there's our reset > tree. If no, I guess we could still use it as a base, with manually > corrected reset lines where the QOM composition tree is off.
Yes. We really don't want to add more boilerplate requirements to how you write "container" type devices like SoC objects. It's already bad enough that you have to have an instance_init that manually calls instance_init on all your subcomponents, and a realize that calls realize on all of them. If we add a requirement that you need to have reset methods for 3 phases that call reset on all your subcomponents, people are going to forget. We need the default to be "do the thing that's right almost every time", not "do the thing that's wrong". (And then of course there is the "how do we get there from here?" question :-)) thanks -- PMM
