From: "Michael S. Tsirkin" <mst@redhat.com>
To: Isaku Yamahata <yamahata@valinux.co.jp>
Cc: skandasa@cisco.com, Anthony Liguori <aliguori@us.ibm.com>,
etmartin@cisco.com, qemu-devel@nongnu.org, wexu2@cisco.com
Subject: [Qemu-devel] Re: [PATCH 5/7] pci: make use of qdev reset frame work to pci bus reset.
Date: Thu, 18 Nov 2010 10:58:35 +0200 [thread overview]
Message-ID: <20101118085834.GC16832@redhat.com> (raw)
In-Reply-To: <20101118082250.GT18102@valinux.co.jp>
On Thu, Nov 18, 2010 at 05:22:50PM +0900, Isaku Yamahata wrote:
> On Thu, Nov 18, 2010 at 09:02:35AM +0200, Michael S. Tsirkin wrote:
> > > + /*
> > > + * TODO:
> > > + * each device should know what to do on RST#.
> > > + * move pci_device_reset_default() into each callback.
> > > + */
> >
> > Is this doing anything besides give devices another way to shoot
> > themselves in the foot? Handling this all in one place seems easier,
> > assuming everyone just calls pci_device_reset_default in the end. Or do
> > you expect some devices to avoid calling pci_device_reset_default?
>
> I think only single function per a device should know all about reset
> behavior and if a device overrides reset behavior, it should take care
> of itself fully.
Yes. However devices don't seem to override pci reset behavior
- instead they want a callback to reset the devicestate fields.
> But it seems you don't think so. I can drop the following patch(6/7)
> and eliminate this TODO comment.
Yes, if everyone just calls default reset, let's invoke it from common
core. If we see some devices not call common reset, that's when we
better move it.
--
MST
next prev parent reply other threads:[~2010-11-18 8:58 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-17 4:50 [Qemu-devel] [PATCH 0/7] qdev reset refactoring and pci bus reset Isaku Yamahata
2010-11-17 4:50 ` [Qemu-devel] [PATCH 1/7] qbus: add functions to walk both devices and busses Isaku Yamahata
2010-11-17 11:57 ` [Qemu-devel] " Paolo Bonzini
2010-11-17 4:50 ` [Qemu-devel] [PATCH 2/7] qdev: reset qdev along with qdev tree Isaku Yamahata
2010-11-17 4:50 ` [Qemu-devel] [PATCH 3/7] qdev: introduce reset call back for qbus level Isaku Yamahata
2010-11-17 4:50 ` [Qemu-devel] [PATCH 4/7] qdev: introduce a helper function which triggers reset from a given device Isaku Yamahata
2010-11-17 4:50 ` [Qemu-devel] [PATCH 5/7] pci: make use of qdev reset frame work to pci bus reset Isaku Yamahata
2010-11-18 7:02 ` [Qemu-devel] " Michael S. Tsirkin
2010-11-18 8:22 ` Isaku Yamahata
2010-11-18 8:58 ` Michael S. Tsirkin [this message]
2010-11-17 4:50 ` [Qemu-devel] [PATCH 6/7] pci: teach pci devices that have reset callback how to reset common registers Isaku Yamahata
2010-11-17 4:50 ` [Qemu-devel] [PATCH 7/7] pci bridge: implement secondary bus reset Isaku Yamahata
2010-11-18 7:05 ` [Qemu-devel] " Michael S. Tsirkin
2010-11-18 7:29 ` Isaku Yamahata
2010-11-18 8:46 ` Michael S. Tsirkin
2010-11-19 8:15 ` Isaku Yamahata
2010-11-19 11:27 ` Michael S. Tsirkin
2010-11-19 12:08 ` Michael S. Tsirkin
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=20101118085834.GC16832@redhat.com \
--to=mst@redhat.com \
--cc=aliguori@us.ibm.com \
--cc=etmartin@cisco.com \
--cc=qemu-devel@nongnu.org \
--cc=skandasa@cisco.com \
--cc=wexu2@cisco.com \
--cc=yamahata@valinux.co.jp \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).