> So we _could_ just save the mode, but that isn't really what this patch is > all about. The patch in question is about a total hack to avoid touching a > piece of hardware that we simply don't consider normal. The driver knows and assumes the chip is stuck back into the right configuration. Things like ttyS0 shared as console and tty won't work right if we simply pray the configuration comes back sane. It may well do on OLPC but on a standard generic PC we can't bet on it. If the user has a high console speed set this patch will do the wrong thing. No suspend console meaning "I'd like to debug suspend/resume" is only useful if we actually put the bits back into a sane state coming out of suspend to ram (and in some cases suspend to disk) Deepak's original patch from 2008 is actually much better. He puts the chip back in the right hardware configuration for the speed. He doesn't randomly regress other platforms and configurations and he does it by calling the standard methods in the driver to do the job. http://dev.laptop.org/~dsaxena/patches/console_suspend_old.patch It also has another advantage - it fixes the behaviour for almost everything in drivers/serial not just a specific uart. Technically he should take tty->termios_mutex before state->mutex in that code path as the upstream code has changed but in every other respect its the proper solution. So can we apply Deepak's original correct 2008 patch instead please ? Alan -- 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