Messages in this thread | | | Date | Fri, 9 Jun 2006 10:46:00 +0200 | From | Pavel Machek <> | Subject | fixing serial console over suspend [was Re: Bisects that are neither good nor bad] |
| |
On Pá 09-06-06 09:42:34, Russell King wrote: > On Fri, Jun 09, 2006 at 10:38:33AM +0200, Pavel Machek wrote: > > > The serial layer does _not_ have access to the "current" termios > > > settings due to the layering by the tty subsystem. If the serial > > > port being used by serial console has been opened once by the user, > > > but is closed at the moment when a suspend/resume cycle occurs, > > > the serial layer and lower level drivers do not have access to the > > > baud rate. > > > > Could serial layer just cache "last baud rate" in some kind of > > software shadow register? Yes, it is slightly ugly, but should do the trick. > > That's not a new suggestion. How do you deal with the case where > you have console on two or more different serial ports? That's > the problem with this approach.
Well, each of serial ports has hardware baud_rate register. I'll need software baud_rate_shadow for every serial port, setting baud_rate_shadow each time baud_rate is set. During resume, I restore baud_rate from baud_rate_shadow for each serial port.
What am I missing?
> The only sane solution is for the tty layer to be adjusted to allow > suspend/resume support for consoles.
Well, solution above is likely to be ugly, but even ugly patch would help people debug s-to-RAM. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |