> - what if its a port with 256 characters in the FIFO, and its programmed
> for 110 baud?
> - what if loopback isn't supported?
> - what if, while doing this operation, the remote end is sending characters
> because you can't deassert RTS?
More importantly it is unlikely that serial state wil
On Mon, Jan 14, 2008 at 01:40:16PM +1100, [EMAIL PROTECTED] wrote:
> Hi.
>
> 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
On Mon, Jan 14, 2008 at 12:49:59AM +, 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 functio
On Mon, Jan 14, 2008 at 10:04:59AM +0100, Pavel Machek wrote:
> On Mon 2008-01-14 00:29:12, Russell King wrote:
> > If you're suspending because your battery is almost dead what would you
> > prefer - the system being prevented from suspending and losing complete
> > power unexpectedly, resulting i
On Mon 2008-01-14 00:29:12, Russell King wrote:
> On Fri, Jan 11, 2008 at 10:17:21AM +, Pavel Machek wrote:
> > On Tue 2008-01-08 11:57:03, Russell King wrote:
> > > + if (!tries)
> > > + printk(KERN_ERR "%s%s%s%d: Unable to drain
> > > transmitter\n",
> > > +
Hi.
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.
>> T
> > 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 r
On Fri, Jan 11, 2008 at 10:17:21AM +, Pavel Machek wrote:
> On Tue 2008-01-08 11:57:03, Russell King wrote:
> > + if (!tries)
> > + printk(KERN_ERR "%s%s%s%d: Unable to drain
> > transmitter\n",
> > + port->dev ? port->dev->bus_id : "",
> >
On Fri, 2008-01-11 at 10:17 +, Pavel Machek wrote:
> Is printk() enough for 'we've just lost your data' condition? Maybe we
> should abort suspend if we can't drain fifo?
YUCK !
Ben.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMA
Hi.
Pavel Machek wrote:
> On Tue 2008-01-08 11:57:03, Russell King wrote:
>> Some ports seem to be unable to drain their transmitters on shut down.
>> Such a problem can occur if the port is programmed for hardware imposed
>> flow control, characters are in the FIFO but the CTS signal is inactive.
On Tue 2008-01-08 11:57:03, Russell King wrote:
> Some ports seem to be unable to drain their transmitters on shut down.
> Such a problem can occur if the port is programmed for hardware imposed
> flow control, characters are in the FIFO but the CTS signal is inactive.
>
> Normally, this isn't a p
On Tue, Jan 08, 2008 at 04:06:10PM -0800, Andrew Morton wrote:
> One hopes that doing a printk from within uart_suspend_port() will dtrt if
> that port is (was?) being used as a console.
Well, the preceding code shuts down the console side if the port is a
console - so this printk should never mak
> > Give a port 30ms to drain; this is an arbitary value chosen to avoid
> > long delays if there are many such ports in the system, while giving a
> > reasonable chance for a single port to drain. Should a port not drain
> > within this timeout, issue a warning.
30mS is a bit short at low baud r
On Tue, 8 Jan 2008 11:57:03 +
Russell King <[EMAIL PROTECTED]> wrote:
> Some ports seem to be unable to drain their transmitters on shut down.
> Such a problem can occur if the port is programmed for hardware imposed
> flow control, characters are in the FIFO but the CTS signal is inactive.
>
Some ports seem to be unable to drain their transmitters on shut down.
Such a problem can occur if the port is programmed for hardware imposed
flow control, characters are in the FIFO but the CTS signal is inactive.
Normally, this isn't a problem because most places where we wait for the
transmitt
15 matches
Mail list logo
