From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MGIC5-000339-6B for qemu-devel@nongnu.org; Mon, 15 Jun 2009 15:50:13 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MGIBz-0002ym-Gu for qemu-devel@nongnu.org; Mon, 15 Jun 2009 15:50:11 -0400 Received: from [199.232.76.173] (port=54617 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MGIBz-0002ye-BJ for qemu-devel@nongnu.org; Mon, 15 Jun 2009 15:50:07 -0400 Received: from mail-bw0-f223.google.com ([209.85.218.223]:52058) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MGIBy-0001iO-Km for qemu-devel@nongnu.org; Mon, 15 Jun 2009 15:50:07 -0400 Received: by bwz23 with SMTP id 23so3206665bwz.34 for ; Mon, 15 Jun 2009 12:50:04 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20090615193054.GB782@redhat.com> References: <20090611084808.GA19508@redhat.com> <4A3674F5.5080403@redhat.com> <20090615170201.GA3964@redhat.com> <200906151856.28009.paul@codesourcery.com> <20090615181622.GA782@redhat.com> <20090615193054.GB782@redhat.com> Date: Mon, 15 Jun 2009 22:50:04 +0300 Message-ID: Subject: Re: [Qemu-devel] Register uhci_reset() callback. From: Blue Swirl Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: Avi Kivity , Paul Brook , qemu-devel@nongnu.org On 6/15/09, Gleb Natapov wrote: > On Mon, Jun 15, 2009 at 09:57:54PM +0300, Blue Swirl wrote: > > On 6/15/09, Gleb Natapov wrote: > > > On Mon, Jun 15, 2009 at 06:56:26PM +0100, Paul Brook wrote: > > > > > May be, but in this case after previous patch to reset interrupt level > > > > > for each device at PCI bridge level was rejected on the premise that > > > > > device should lower its own irq line on reset and since patches started > > > > > flowing in to do just that, I did not expect that eloquent explanation > > > > > would be needed for such trivial and obviously correct change. > > > > > > > > This argument makes no sense. The fact that you'd recently submitted very > > > > similar looking patches which either got rejected or need modification is a > > > > good argument for providing an explanation. How else are we supposed to know > > > > that you're not just making the same mistake again? > > > > > > They was not even "similar looking". Have you followed the discussion > > > that those patches generated? Look at this commit and especially its commit > > > message: 32c86e95b. This commit is a direct result of the discussion > > > previous patches generated. Look at my patch now. Looks similar, no? So > > > people with commit permissions can follow lower standards that we mere > > > mortals? > > > > I find nothing wrong with your commit message (for completeness, it > > could mention that it installs a reset handler). > > > > It does in subject line. Subject line goes to log message with git-am. > > > > Maybe lowering the irq should actually be unnecessary, qemu_irq is not > > equal to hardware interrupt line. > > Racing irq from pci device will call piix3_set_irq(). piix3_set_irq() > will remember current level in pci_irq_levels[]. The PIC line will be > triggered if one of pci_irq_levels[] is set (depends on piix3 config). > If for instance pci_irq_levels[0] and pci_irq_levels[1] are mapped to > the same PIC irq and during reset pci_irq_levels[1] == 1, but device > that drives pci_irq_levels[0] is initialized first the device will not > be able to lower irq line. Maybe, but then the other device is reset also piix3 at some point.