From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756647Ab0JLH0V (ORCPT ); Tue, 12 Oct 2010 03:26:21 -0400 Received: from smtp1.linux-foundation.org ([140.211.169.13]:58595 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755130Ab0JLH0U (ORCPT ); Tue, 12 Oct 2010 03:26:20 -0400 Date: Tue, 12 Oct 2010 00:27:15 -0700 From: Andrew Morton To: James Hogan Cc: Gary Zambrano , Jiri Pirko , FUJITA Tomonori , Hauke Mehrtens , Larry Finger , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, "David S. Miller" Subject: Re: [PATCH] b44: fix resume, request_irq after hw reset Message-Id: <20101012002715.fd0e3371.akpm@linux-foundation.org> In-Reply-To: <201010120808.05713.james@albanarts.com> References: <201010120022.13171.james@albanarts.com> <20101011163440.072e0227.akpm@linux-foundation.org> <201010120808.05713.james@albanarts.com> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 12 Oct 2010 08:08:05 +0100 James Hogan wrote: > > > @@ -2309,6 +2303,12 @@ static int b44_resume(struct ssb_device *sdev) > > > > > > netif_device_attach(bp->dev); > > > spin_unlock_irq(&bp->lock); > > > > > > + rc = request_irq(dev->irq, b44_interrupt, IRQF_SHARED, dev->name, > dev); > > > + if (rc) { > > > + netdev_err(dev, "request_irq failed\n"); > > > + return rc; > > > + } > > > + > > > > > > b44_enable_ints(bp); > > > netif_wake_queue(dev); > > > > OK, running the interrupt handler before b44_init_hw() is presumably > > the problem here. > > > > The hardware surely won't be generating interrupts until we've run > > b44_init_hw() and b44_enable_ints(), so this patch really is only to > > keep CONFIG_DEBUG_SHIRQ happy. > > For me it's mainly to keep CONFIG_DEBUG_SHIRQ happy (Fedora has this switched > on), but since it's a shared IRQ, there is still a chance it could be > called before enabling it's own interrupts by a different device on the same > IRQ. ooh, yes, you're right, I forgot about that. It's indeed a bug. > It makes sense to me why it's disabling the IRQ now, in case another device > triggers it when it cannot handle it safely. What code are you referring to here? There's no disable_irq() in that area? > I also tried calling the > interrupt directly before the free_irq in the suspend function to check that > it wasn't being done too late, and it didn't fail, so possibly it is the core > suspension that makes it start failing until it is brought back up properly.