On Mon, Aug 30, 2010 at 7:25 PM, Anthony Liguori <anth...@codemonkey.ws> wrote: > On 08/30/2010 02:16 PM, Blue Swirl wrote: >> >> On Mon, Aug 30, 2010 at 1:03 PM, Anthony Liguori<anth...@codemonkey.ws> >> wrote: >> >>> >>> On 08/30/2010 03:50 AM, Paolo Bonzini wrote: >>> >>>> >>>> On 08/30/2010 09:49 AM, Isaku Yamahata wrote: >>>> >>>>> >>>>> +/* those two functions are obsoleted by cold/warm reset API. */ >>>>> [qemu_register_reset/qemu_unregister_reset] >>>>> >>>> >>>> Are they? >>>> >>> >>> Yes, but introduce more reset functions isn't the right approach. >>> >>> Reset should be a method of the device tree, not a stand alone function. >>> >> >> In theory the reset tree may be very different from device tree. In >> practice the reset tree is probably very flat (global reset signal, a >> few bus reset signals) so device tree approach may get the same >> results. >> > > Well the device tree doesn't really have to be a tree :-)
True, but is the non-tree still always useful for other things besides reset? Again, in theory. > My thinking if we need to support custom reset propagation is that we have > the current reset() handler return 0 to propagate to children, < 0 on error, > and > 0 to not propagate to direct children just as we do with the walkers. > > In the case of > 0, the device can choose to propagate to any device that it > knows about independent of the default walking order. This makes the device > tree a directed graph whereas the transversal path can be arbitrarily > custom. I'd rather not have that much knowledge about the reset tree in the devices. > The only questions in my mind are, do we truly need this and do we need more > than a single type of reset. We could make this almost arbitrarily > complicated if we wanted to but we should try to keep things simply unless > there's a compelling reason not to. Fully agreed, I think current model works. But I'm not opposed to a more generic approach, like VM events, combining also power control with reset. Though events would not help with the disjoint tree problem. With qemu_irq approach, each event would be replaced by a signal type with a few instances. The devices would be as simple as now, but wiring in the board level would be bloated.
