From: Filip Navara <filip.navara@gmail.com>
To: Gleb Natapov <gleb@redhat.com>
Cc: Dor Laor <dlaor@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] Register usb-uhci reset function.
Date: Wed, 17 Jun 2009 13:50:49 +0200 [thread overview]
Message-ID: <5b31733c0906170450o12273437t89aa5d37a4c49b8d@mail.gmail.com> (raw)
In-Reply-To: <20090617113918.GZ19508@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1560 bytes --]
On Wed, Jun 17, 2009 at 1:39 PM, Gleb Natapov <gleb@redhat.com> wrote:
> On Wed, Jun 17, 2009 at 02:25:24PM +0300, Dor Laor wrote:
> > Some general comments regarding this thread:
> > Most pci devices register a reset handler and reset the irq line just
> > like this patch.
> > I propose to accept this patch first, since it solves a real problem
> > (and not a theoretical one).
> >
> uhci not registering reset handler is clearly a bug and I hope everyone
> agrees that this should be fixed. I think the main opposition is against
> add qemu_irq() call to the reset handler. And if patch to piix3 is
> applied then qemu_irq() in uhci reset handler can be dropped (it
> shouldn't IMHO but whatever). The question is why maintainers who now argue
> that reset function to piix3 is the beset thing since sliced bread haven't
> applied the patch when it was posted?
+1 for dropping the set_irq in the reset handler and applying the piix3
patch.
I hope we can come to a consensus and finally get the patches in, the bug is
real and it's there. I can't speak for the maintainers since I am not one of
them.
The main reason why I argue for dropping the set_irq is that it's
conceptually wrong to call it. It took me a while to read all the mails
before I understood that and I am only trying to communicate the knowledge
further. I have been hardly bitten by other patches that fixed real problems
in a wrong way in the last month or two and I don't want this to happen
again if there is already a solution that is "more correct".
Best regards,
Filip Navara
[-- Attachment #2: Type: text/html, Size: 2248 bytes --]
next prev parent reply other threads:[~2009-06-17 11:50 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-16 12:47 [Qemu-devel] [PATCH] Register usb-uhci reset function Gleb Natapov
2009-06-16 17:14 ` Paul Brook
2009-06-16 17:37 ` Gleb Natapov
2009-06-16 18:41 ` Paul Brook
2009-06-16 19:11 ` Gleb Natapov
2009-06-16 19:38 ` Paul Brook
2009-06-16 22:57 ` Zachary Amsden
2009-06-17 8:12 ` Gleb Natapov
2009-06-16 18:02 ` Blue Swirl
2009-06-16 19:19 ` Anthony Liguori
2009-06-16 19:26 ` Gleb Natapov
2009-06-17 9:07 ` Filip Navara
2009-06-17 9:43 ` Gleb Natapov
2009-06-17 10:17 ` Filip Navara
2009-06-17 11:06 ` Gleb Natapov
2009-06-17 11:25 ` Dor Laor
2009-06-17 11:39 ` Gleb Natapov
2009-06-17 11:50 ` Filip Navara [this message]
2009-06-17 11:36 ` Filip Navara
2009-06-17 12:12 ` Gleb Natapov
2009-06-17 13:03 ` Filip Navara
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=5b31733c0906170450o12273437t89aa5d37a4c49b8d@mail.gmail.com \
--to=filip.navara@gmail.com \
--cc=dlaor@redhat.com \
--cc=gleb@redhat.com \
--cc=qemu-devel@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 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).