From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id DCAA0B6F95 for ; Mon, 28 Nov 2011 11:30:20 +1100 (EST) Message-ID: <1322440206.23348.35.camel@pasglop> Subject: Re: [PATCH 01/16] pmac_zilog: fix unexpected irq From: Benjamin Herrenschmidt To: Finn Thain Date: Mon, 28 Nov 2011 11:30:06 +1100 In-Reply-To: References: <20111023141108.856998818@telegraphics.com.au> <20111023141115.208699274@telegraphics.com.au> <20111124145624.24438832@lxorguk.ukuu.org.uk> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Cc: Geert Uytterhoeven , linux-m68k@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-serial@vger.kernel.org, Alan Cox List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , > Removing ifdefs makes the changes more invasive and the suspend/resume > code then has to be addressed, which I've avoided. > > The suspend/resume code path can't be tested on m68k macs and the common > code paths I can't easily test on a powermac. > > This patch should not be needed because the chip reset shouldn't leave the > tx and rx interrupts enabled. Those interrupts are explicitly enabled only > after request_irq(), so patching the master interrupt enable behaviour > should be redundant. But that's not the case in practice. > > The chip reset code is already messy. I was inclined towards ifdefs and > reluctant to share more code after practical experience suggested possible > differences in the SCC/ESCC devices. > > I guess I was hoping that the powermac maintainers might prefer ifdefs to > increased risk of destabilising the driver on powermacs... > > But a more invasive patch would make for better code. I will see if I can > borrow a suitable PCI PowerMac. Please do the more invasive patch, I'll beat it up on powermacs. Cheers, Ben.