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

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/

--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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/

--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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