Re: fixing serial console over suspend [was Re: Bisects that are neither good nor bad]

[Russell King <rmk+lkml@arm.linux.org.uk>]

On Fri, Jun 09, 2006 at 10:46:00AM +0200, Pavel Machek wrote:
> 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?

What about the other parameters like the bit size, number of stop bits,
etc?

> > 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.

Why not investigate doing the proper solution?  Since you're obviously
one of the ones who is able to reproduce the situation (I'm not), you're
perfectly placed to develop and test such a solution, and I think it's
well within your capability.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core