[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