Messages in this thread | | | Date | Sat, 31 Jan 2009 16:32:31 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: 2.6.29-rc3: tg3 dead after resume |
| |
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
| |