On Mon, Apr 24, 2006 at 02:29:51PM -0700, David Brownell wrote: > I recently observed this myself and tracked down one problem. The solution > involves what kexec() does in much the same situation: before starting a > new kernel, most hardware needs to be reset. Today, swsusp will suspend it > instead, which is the root cause of the problem. I'm not sure that is a good thing to do for a lot of video chipsets on x86 platforms. For many, we do not have a way to reinitialize them from scratch, so if we do a reset on them then we shoot ourselves in the foot. Now, maybe some/most/all video chipsets wouldn't do anything when it gets the reset call. But, if you have one driver that does reset the hardware (e.g. because the hardware is buggy and needs it before system reset), then this patch will prevent that one chipset from working, so you'll have to work around that, possibly by passing a flag to the reset method. At that point, you have something very similar to just calling suspend with a different flag than FREEZE (or an additional flag). I don't disagree with the intent or justification of the patch, but ultimately it is up to the drivers to decide what to do for a particular piece of hardware in a particular context. Maybe the driver does the same thing for all hardware in all situations, like reset the device. Or, maybe all drivers do the same thing in a particular context. It's very difficult to know what every single device needs, so we should just be honest with the drivers - tell them exactly what we're about to do - and let them handle it as appropriate.. Pat
