> - 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
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
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
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
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",
> > > +
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,
+
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 in
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 functionality that
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
to ram or
- 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 will or
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.
>>
> > 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
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
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
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
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
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 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 [EMAIL
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 : ,
+
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
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.
They want it
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
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 make
> > 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
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
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
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.
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 rates -
30 matches
Mail list logo
