qemu-trivial
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 11/11] hw/misc/vmcoreinfo: Convert reset handler to DeviceRes


From: Damien Hedde
Subject: Re: [PATCH 11/11] hw/misc/vmcoreinfo: Convert reset handler to DeviceReset
Date: Wed, 9 Oct 2019 11:04:26 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.0


On 10/8/19 3:32 PM, Eduardo Habkost wrote:
> On Thu, Sep 26, 2019 at 06:02:47PM +0200, Philippe Mathieu-Daudé wrote:
>> On 9/26/19 5:17 PM, Philippe Mathieu-Daudé wrote:
>>> Convert the reset handler into a proper Device reset method.
>>
>> Marc-André noticed this one is incorrect, because while being QDEV it is
>> not connected to a QBUS.
>>
>> Maybe we can add a Device::unconnected property, and when set, the
>> parent realize() calls 'qemu_register_reset(dev->reset, dev);'?
>> This might look the same, but at least Devices implementations could
>> stop to use this function...
> 
> Can we make this automatic instead of requiring another explicit
> setting?
> 
> Today we have at least 3 different ways of getting a device to be
> reset: qemu_register_reset(); explicit device_reset_all() call in
> another reset handler; and implicit device_reset_all() call done
> through parent buses/devices.  I wouldn't like to create a 4th
> method.
> 
> What I really wish for, is a opt-out mechanism for reset (meaning
> all devices would be guaranteed to be reset unless they
> explicitly opt out), instead of 3 or 4 different opt-in
> mechanisms.
> 

Sorry for the stupid question, but why would we not reset a device ? Are
there some cases when a device must be "initialized" not in its reset
state ?

Regarding the reset guarantee. Can this be done by doing first
qemu_register_reset() on each device and eventually unregistering
it in case of opt-out or wanting to reset it by other means (eg when
putting it into a bus) ?

Damien



reply via email to

[Prev in Thread] Current Thread [Next in Thread]