Re: [Qemu-devel] Re: [PATCH 5/5] RFC: distinguish warm reset from cold reset.

[Anthony Liguori <anthony@codemonkey.ws>]

On 08/30/2010 02:16 PM, Blue Swirl wrote:
> On Mon, Aug 30, 2010 at 1:03 PM, Anthony Liguori<anthony@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 :-)

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.

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.

Regards,

Anthon Liguori

> IIRC on some HW ages ago the CPU could initiate an external device
> reset (without resetting the CPU) but in that case the board caused
> also CPU to be reset so it was useless.
>
> One way to model the disjoint reset trees would be to use an explicit
> qemu_irq signal for reset. It's a bit complex to set up compared to
> the almost flat tree we want though.
>
>