Re: 2.6.29-rc3: tg3 dead after resume

Linus Torvalds
2009-02-01T00:32:37Z

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