Re: 2.6.29-rc3: tg3 dead after resume

Rafael J. Wysocki
2009-02-01T00:41:59Z

On Sunday 01 February 2009, Linus Torvalds wrote:
>
> 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,

I said I was.

Thanks,
Rafael