From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MGHvU-0005S7-RA for qemu-devel@nongnu.org; Mon, 15 Jun 2009 15:33:04 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MGHvQ-0005Pw-IK for qemu-devel@nongnu.org; Mon, 15 Jun 2009 15:33:04 -0400 Received: from [199.232.76.173] (port=51143 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MGHvQ-0005Pt-Dj for qemu-devel@nongnu.org; Mon, 15 Jun 2009 15:33:00 -0400 Received: from mx20.gnu.org ([199.232.41.8]:60906) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MGHvQ-0003Yl-1Z for qemu-devel@nongnu.org; Mon, 15 Jun 2009 15:33:00 -0400 Received: from mx2.redhat.com ([66.187.237.31]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MGHvP-0003LA-Ce for qemu-devel@nongnu.org; Mon, 15 Jun 2009 15:32:59 -0400 Date: Mon, 15 Jun 2009 22:30:54 +0300 From: Gleb Natapov Subject: Re: [Qemu-devel] Register uhci_reset() callback. Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: Avi Kivity , Paul Brook , qemu-devel@nongnu.org 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. -- Gleb.