Re: [PATCH: 2/2] [SERIAL] avoid stalling suspend if serial port won't drain

[Russell King]

On Mon, Jan 14, 2008 at 12:49:59AM +0000, Alan Cox wrote:
> > > Is printk() enough for 'we've just lost your data' condition? Maybe we
> > > should abort suspend if we can't drain fifo?
> > 
> > No way. Think about this from a users' perspective. No one wants suspend
> > to ram or hibernate functionality that works sometimes and not others.
> > They want it to work reliably so they don't have to worry about their
> > laptop overheating while they're getting on the bus or airplane.
> > Aborting isn't an option.
> 
> Dumb question on the printk however - what if the port that is sticking
> is the console - don't we recurse and die ?

How do we recurse?  printk never calls the suspend method.

What *might* happen is that printk might call the serial console write
function, which waits a maximum of 10ms per character to be sent without
hardware console flow control, or one second per character with hardware
console flow control.

This will only happen when there isn't something asserting CTS connected
to the console port and hardware console flow control has been configured
at boot time.

This will also happen in normal operation if you set the system up as
above and deassert CTS - there's nothing suspend specific about that.

Finally note that hardware console flow control is entirely separate from
the user-level flow control settings or the hardware's ability.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/