[PATCH] Serial: BUGFIX: uart_resume_port has an omitted condition.

[PATCH] Serial: BUGFIX: uart_resume_port has an omitted condition.

[MyungJoo Ham]

When console_suspend_enabled == 0, console_stop() was not called at
suspend; thus, it does not need to call console_start() when resume.
Besides, calling console_start() without calling console_stop() before
had been incurring kernel hang with console_suspend_enabled == 0 in a
machine with drivers/serial/samsung.c and s5pc210.

Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
---
 drivers/serial/serial_core.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/serial/serial_core.c b/drivers/serial/serial_core.c
index cd85112..ff21200 100644
--- a/drivers/serial/serial_core.c
+++ b/drivers/serial/serial_core.c
@@ -2065,7 +2065,7 @@ int uart_resume_port(struct uart_driver *drv, struct uart_port *uport)
 	/*
 	 * Re-enable the console device after suspending.
 	 */
-	if (uart_console(uport)) {
+	if (console_suspend_enabled && uart_console(uport)) {
 		uart_change_pm(state, 0);
 		uport->ops->set_termios(uport, &termios, NULL);
 		console_start(uport->cons);
-- 
1.6.3.3

Re: [PATCH] Serial: BUGFIX: uart_resume_port has an omitted condition.

[Greg KH]

On Wed, Oct 13, 2010 at 02:58:06PM +0900, MyungJoo Ham wrote:
> When console_suspend_enabled == 0, console_stop() was not called at
> suspend; thus, it does not need to call console_start() when resume.
> Besides, calling console_start() without calling console_stop() before
> had been incurring kernel hang with console_suspend_enabled == 0 in a
> machine with drivers/serial/samsung.c and s5pc210.

Is this a regression?  If so, from what working kernel?  Or has this
always been this way?

thanks,

greg k-h

Re: [PATCH] Serial: BUGFIX: uart_resume_port has an omitted condition.

[MyungJoo Ham]

On Wed, Oct 13, 2010 at 3:26 PM, Greg KH <gregkh@suse.de> wrote:
> On Wed, Oct 13, 2010 at 02:58:06PM +0900, MyungJoo Ham wrote:
>> When console_suspend_enabled == 0, console_stop() was not called at
>> suspend; thus, it does not need to call console_start() when resume.
>> Besides, calling console_start() without calling console_stop() before
>> had been incurring kernel hang with console_suspend_enabled == 0 in a
>> machine with drivers/serial/samsung.c and s5pc210.
>
> Is this a regression?  If so, from what working kernel?  Or has this
> always been this way?
>
> thanks,
>
> greg k-h
>


I don't think this is a regression to the previous version. Logically,
it's matching the console_stop()-console_start() pair.

Such hang in serial and its mitigation is observed in 2.6.36 at
arch/arm/mach-s5pv310 machines. In these machines, it hanged with
console_suspend_enabled == 0 every time.



Cheers!

- MyungJoo

-- 
MyungJoo Ham (함명주), Ph.D.
Mobile Software Platform Lab,
Digital Media and Communications (DMC) Business
Samsung Electronics
cell: 82-10-6714-2858

Re: [PATCH] Serial: BUGFIX: uart_resume_port has an omitted condition.

[Stanislav Brabec]

On Wed, 13 Oct 2010 15:38:13 +0900, MyungJoo Ham wrote:
> On Wed, Oct 13, 2010 at 3:26 PM, Greg KH <gregkh@suse.de> wrote:
> > On Wed, Oct 13, 2010 at 02:58:06PM +0900, MyungJoo Ham wrote:

> > Is this a regression?  If so, from what working kernel?  Or has this
> > always been this way?
> 
> I don't think this is a regression to the previous version. Logically,
> it's matching the console_stop()-console_start() pair.

This disparity appeared deliberately in 4547be78. If you need
no_console_suspend and the hardware lets the device in an undefined
state after resume (i. e. PXA270), you need to call subset of the
resume, even if the suspend counterpart was not called. Yes, I can
imagine that it may be a source of problems.

Did you try the latest patches from Jason Wang from linux-serial list?

> Such hang in serial and its mitigation is observed in 2.6.36 at
> arch/arm/mach-s5pv310 machines. In these machines, it hanged with
> console_suspend_enabled == 0 every time.

It seems that support for no_console_suspend for all devices is becoming
more complicated. I guess that a new driver calls (maybe "save_state"
and "resume_state") or support for no_console_suspend directly in
drivers may be useful.

-- 
Best Regards / S pozdravem,

Stanislav Brabec
software developer
---------------------------------------------------------------------
SUSE LINUX, s. r. o.                          e-mail: sbrabec@suse.cz
Lihovarská 1060/12           tel: +420 284 028 966, +49 911 740538747
190 00 Praha 9                                  fax: +420 284 028 951
Czech Republic                                    http://www.suse.cz/

Re: [PATCH] Serial: BUGFIX: uart_resume_port has an omitted condition.

[Greg KH]

On Wed, Oct 13, 2010 at 01:26:45PM +0200, Stanislav Brabec wrote:
> On Wed, 13 Oct 2010 15:38:13 +0900, MyungJoo Ham wrote:
> > On Wed, Oct 13, 2010 at 3:26 PM, Greg KH <gregkh@suse.de> wrote:
> > > On Wed, Oct 13, 2010 at 02:58:06PM +0900, MyungJoo Ham wrote:
> 
> > > Is this a regression?  If so, from what working kernel?  Or has this
> > > always been this way?
> > 
> > I don't think this is a regression to the previous version. Logically,
> > it's matching the console_stop()-console_start() pair.
> 
> This disparity appeared deliberately in 4547be78. If you need
> no_console_suspend and the hardware lets the device in an undefined
> state after resume (i. e. PXA270), you need to call subset of the
> resume, even if the suspend counterpart was not called. Yes, I can
> imagine that it may be a source of problems.
> 
> Did you try the latest patches from Jason Wang from linux-serial list?
> 
> > Such hang in serial and its mitigation is observed in 2.6.36 at
> > arch/arm/mach-s5pv310 machines. In these machines, it hanged with
> > console_suspend_enabled == 0 every time.
> 
> It seems that support for no_console_suspend for all devices is becoming
> more complicated. I guess that a new driver calls (maybe "save_state"
> and "resume_state") or support for no_console_suspend directly in
> drivers may be useful.

Ok, so I'm guessing that this patch is not to be applied then, correct?

thanks,

greg k-h

Re: [PATCH] Serial: BUGFIX: uart_resume_port has an omitted condition.

[Stanislav Brabec]

Greg KH wrote: 
> > This disparity appeared deliberately in 4547be78. If you need
> > no_console_suspend and the hardware lets the device in an undefined
> > state after resume (i. e. PXA270), you need to call subset of the
> > resume, even if the suspend counterpart was not called. Yes, I can
> > imagine that it may be a source of problems.
 
> > It seems that support for no_console_suspend for all devices is becoming
> > more complicated. I guess that a new driver calls (maybe "save_state"
> > and "resume_state") or support for no_console_suspend directly in
> > drivers may be useful.
> 
> Ok, so I'm guessing that this patch is not to be applied then, correct?

I just compared it with Jason Wang's patches. MyungJoo Ham's patch is
exactly equal to the PATCH 1/2. So it already has my ACK and it is
pending as:

serial-core: skip call set_termios/console_start when no_console_suspend

Related thread can be found in linux-serial archives from August 2010:
[PATCH RESEND 0/2] two serial_core suspend/resume fixes

To MyungJoo Ham: Could you verify, that Jason Wang's patch 2/2 does not
break your system? My patch to fix PXA270 does not exist yet. I'll ask
you in future for testing.

-- 
Best Regards / S pozdravem,

Stanislav Brabec
software developer
---------------------------------------------------------------------
SUSE LINUX, s. r. o.                          e-mail: sbrabec@suse.cz
Lihovarská 1060/12           tel: +420 284 028 966, +49 911 740538747
190 00 Praha 9                                  fax: +420 284 028 951
Czech Republic                                    http://www.suse.cz/

Re: [PATCH] Serial: BUGFIX: uart_resume_port has an omitted condition.

[Greg KH]

On Thu, Oct 14, 2010 at 09:45:57PM +0200, Stanislav Brabec wrote:
> Greg KH wrote: 
> > > This disparity appeared deliberately in 4547be78. If you need
> > > no_console_suspend and the hardware lets the device in an undefined
> > > state after resume (i. e. PXA270), you need to call subset of the
> > > resume, even if the suspend counterpart was not called. Yes, I can
> > > imagine that it may be a source of problems.
>  
> > > It seems that support for no_console_suspend for all devices is becoming
> > > more complicated. I guess that a new driver calls (maybe "save_state"
> > > and "resume_state") or support for no_console_suspend directly in
> > > drivers may be useful.
> > 
> > Ok, so I'm guessing that this patch is not to be applied then, correct?
> 
> I just compared it with Jason Wang's patches. MyungJoo Ham's patch is
> exactly equal to the PATCH 1/2. So it already has my ACK and it is
> pending as:
> 
> serial-core: skip call set_termios/console_start when no_console_suspend

Ah, ok, thanks for confirming this, no need for me to do anything else
then, I like it :)

thanks,

greg k-h