From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MGGQA-0003pz-Eb
	for qemu-devel@nongnu.org; Mon, 15 Jun 2009 13:56:38 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MGGQ5-0003hK-Ma
	for qemu-devel@nongnu.org; Mon, 15 Jun 2009 13:56:38 -0400
Received: from [199.232.76.173] (port=57158 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MGGQ5-0003h3-Gz
	for qemu-devel@nongnu.org; Mon, 15 Jun 2009 13:56:33 -0400
Received: from mx20.gnu.org ([199.232.41.8]:57003)
	by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.60) (envelope-from <paul@codesourcery.com>)
	id 1MGGQ5-0004Rn-5b
	for qemu-devel@nongnu.org; Mon, 15 Jun 2009 13:56:33 -0400
Received: from mail.codesourcery.com ([65.74.133.4])
	by mx20.gnu.org with esmtp (Exim 4.60)
	(envelope-from <paul@codesourcery.com>) id 1MGGQ3-0006qr-52
	for qemu-devel@nongnu.org; Mon, 15 Jun 2009 13:56:31 -0400
From: Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] Register uhci_reset() callback.
Date: Mon, 15 Jun 2009 18:56:26 +0100
References: <20090611084808.GA19508@redhat.com> <4A3674F5.5080403@redhat.com>
	<20090615170201.GA3964@redhat.com>
In-Reply-To: <20090615170201.GA3964@redhat.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200906151856.28009.paul@codesourcery.com>
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org
Cc: Avi Kivity <avi@redhat.com>, Gleb Natapov <gleb@redhat.com>

> 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?

Paul