Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753417AbZBAAct (ORCPT ); Sat, 31 Jan 2009 19:32:49 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752147AbZBAAci (ORCPT ); Sat, 31 Jan 2009 19:32:38 -0500 Received: from smtp1.linux-foundation.org ([140.211.169.13]:53370 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751517AbZBAAch (ORCPT ); Sat, 31 Jan 2009 19:32:37 -0500 Date: Sat, 31 Jan 2009 16:32:31 -0800 (PST) From: Linus Torvalds X-X-Sender: torvalds@localhost.localdomain To: "Rafael J. Wysocki" cc: Parag Warudkar , Matt Carlson , "netdev@vger.kernel.org" , Linux Kernel Mailing List , "David S. Miller" , Andrew Morton Subject: Re: 2.6.29-rc3: tg3 dead after resume In-Reply-To: <200902010111.08433.rjw@sisk.pl> Message-ID: References: <200901312346.35265.rjw@sisk.pl> <200902010111.08433.rjw@sisk.pl> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2167 Lines: 50 On Sun, 1 Feb 2009, Rafael J. Wysocki wrote: > > The problems happen on purely the suspend path. How the f*ck do you know > > that the drivers behind the bridge don't do everything at 'suspend_late' > > time, and expect to be working up until that time? > > DMA from suspend_late? Come on. Rafael. Stop being a total idiot. Read what I wrote. I'm saying that the driver may not do anything at all at suspend() time, and leaves everything until suspend_late. Then, at suspend_late(), it finally really shuts down. That's actually a very reasonable thing to do in some circumstances. It simplifies everything, in particular all interrupt handling, since the device is now fully live all the way while interrupts can happen. For a USB host controller, for example, it really could make sense to do that - just leave all the core host controller stuff running, and the only thing the "suspend()" callback does is to send the commands to the actual devices, it doesn't necessarily touch the host controller itself at all. Then, at suspend_late time, you just clear the "running" bit in the controller (and perhaps not even that - because you want to still push things out for debugging). End result: you never actually had to shut anything down at all, and you could (for example) still run a USB serial port console all the way to shutdown. And yes, I wanted to do basically exactly that when I was debugging some issues a year or two ago. See? The device and driver may be totally alive over a ->suspend() call. And that means that the bridge CANNOT KNOW that it's ok to shut down DMA. Because DMA may be the only way the device communicates (again: USB actually works that way). So dammit, just admit that you were wrong, instead of continually sending these _idiotic_ replies. That "turn off bus mastering" was bogus and idiotic, and had no real cause. Ok to just admit it already? Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/