On Wed, Oct 13, 2010 at 01:26:45PM +0200, Stanislav Brabec wrote: > On Wed, 13 Oct 2010 15:38:13 +0900, MyungJoo Ham wrote: > > On Wed, Oct 13, 2010 at 3:26 PM, Greg KH <gregkh@xxxxxxx> wrote: > > > On Wed, Oct 13, 2010 at 02:58:06PM +0900, MyungJoo Ham wrote: > > > > Is this a regression? If so, from what working kernel? Or has this > > > always been this way? > > > > I don't think this is a regression to the previous version. Logically, > > it's matching the console_stop()-console_start() pair. > > This disparity appeared deliberately in 4547be78. If you need > no_console_suspend and the hardware lets the device in an undefined > state after resume (i. e. PXA270), you need to call subset of the > resume, even if the suspend counterpart was not called. Yes, I can > imagine that it may be a source of problems. > > Did you try the latest patches from Jason Wang from linux-serial list? > > > Such hang in serial and its mitigation is observed in 2.6.36 at > > arch/arm/mach-s5pv310 machines. In these machines, it hanged with > > console_suspend_enabled == 0 every time. > > It seems that support for no_console_suspend for all devices is becoming > more complicated. I guess that a new driver calls (maybe "save_state" > and "resume_state") or support for no_console_suspend directly in > drivers may be useful. Ok, so I'm guessing that this patch is not to be applied then, correct? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
