All of lore.kernel.org
 help / color / mirror / Atom feed
From: Damien Hedde <damien.hedde@greensocs.com>
To: "Eduardo Habkost" <ehabkost@redhat.com>,
	"Philippe Mathieu-Daudé" <philmd@redhat.com>
Cc: qemu-trivial@nongnu.org,
	"Peter Maydell" <peter.maydell@linaro.org>,
	qemu-devel@nongnu.org,
	"Marc-André Lureau" <marcandre.lureau@redhat.com>,
	"Markus Armbruster" <armbru@redhat.com>
Subject: Re: [PATCH 11/11] hw/misc/vmcoreinfo: Convert reset handler to DeviceReset
Date: Wed, 9 Oct 2019 11:04:26 +0200	[thread overview]
Message-ID: <eb4eccc6-ef92-9a41-3d0d-f265166d5a98@greensocs.com> (raw)
In-Reply-To: <20191008133219.GV4084@habkost.net>



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	other threads:[~2019-10-09 17:45 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-26 15:17 [PATCH 00/11] hw: Convert various reset() handler to DeviceReset Philippe Mathieu-Daudé
2019-09-26 15:17 ` [PATCH 01/11] hw/acpi/piix4: Convert reset " Philippe Mathieu-Daudé
2019-10-04 11:32   ` Igor Mammedov
2019-09-26 15:17 ` [PATCH 02/11] hw/ide/piix: " Philippe Mathieu-Daudé
2019-09-26 15:17 ` [PATCH 03/11] hw/isa/piix4: " Philippe Mathieu-Daudé
2019-09-26 15:17 ` [PATCH 04/11] hw/pci-host/piix: " Philippe Mathieu-Daudé
2019-09-26 15:17 ` [PATCH 05/11] hw/ide/sii3112: " Philippe Mathieu-Daudé
2019-09-26 15:17 ` [PATCH 06/11] hw/ide/via82c: " Philippe Mathieu-Daudé
2019-09-26 15:17 ` [PATCH 07/11] hw/isa/vt82c686: " Philippe Mathieu-Daudé
2019-09-26 15:17 ` [PATCH 08/11] hw/input/lm832x: " Philippe Mathieu-Daudé
2019-09-26 15:17 ` [PATCH 09/11] hw/pci-host/bonito: " Philippe Mathieu-Daudé
2019-09-26 15:17 ` [PATCH 10/11] hw/timer/etraxfs: " Philippe Mathieu-Daudé
2019-09-26 15:17 ` [PATCH 11/11] hw/misc/vmcoreinfo: " Philippe Mathieu-Daudé
2019-09-26 16:02   ` Philippe Mathieu-Daudé
2019-10-08 13:32     ` Eduardo Habkost
2019-10-09  9:04       ` Damien Hedde [this message]
2019-10-09 13:51     ` Peter Maydell
2019-09-27  8:47 ` [PATCH 00/11] hw: Convert various reset() " no-reply
2019-10-05 21:46 ` Michael S. Tsirkin
2019-10-07 10:01   ` Philippe Mathieu-Daudé
2019-10-07 21:24     ` Eduardo Habkost
2019-10-08  9:47       ` Peter Maydell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=eb4eccc6-ef92-9a41-3d0d-f265166d5a98@greensocs.com \
    --to=damien.hedde@greensocs.com \
    --cc=armbru@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=philmd@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-trivial@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.