Re: 2.6.29-rc3: tg3 dead after resume

[Rafael J. Wysocki]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/