Re: [PATCH 2/2] [RFC] pl2303 autosuspend

On Tue, Oct 30, 2007 at 01:42:03PM +0100, Oliver Neukum wrote:
> Am Dienstag 30 Oktober 2007 schrieb Sarah Sharp:
> > > So, does this patch work for you with your devices?
> > 
> > My devices work fine after an autosuspend, but I think they won't work
> > after a suspend.  The urbs will get killed in the suspend function and
> > then won't get resubmitted in the resume function.  You don't notice in
> > the autosuspend case because the urbs are submitted when the tty is
> > opened.  So this patch not ready to be merged; I simply wanted comments
> > on it.
> 
> True, there is a use of the genric function misssing. Does it work with this
> patch?

With your patch (and an additional check in the resume function so that
the URBs are not submitted during autoresume), suspend with a pl2303 HX
chip works for:
 - autosuspend
 - suspending with the tty open or closed
 - hibernate with the tty closed

A hibernate (or a suspend that causes the USB subsystem to lose power)
has issues.  If you have the tty open when you hibernate, a new tty will
be created when the device re-enumerates during resume.  Closing the old
tty will cause the serial driver's shutdown function to be called on a
device that doesn't exist anymore.  Fortunately, that doesn't seem to
have any adverse effects on the functionality of the new tty.

I've tried adding a tty hangup to the suspend function, but that doesn't
seem to have any effect on minicom.  I'm not sure whether minicom
ignores hangups, or if it never gets the hangup.  The tty layer
schedules the hangup; it isn't synchronous.

This seems to be the only issue with adding autosuspend code to the
pl2303.  A hibernate with the tty open didn't work before, so I'm
inclined to send an updated patch later today.

Also, I found out the hard way that some types of pl2303 chips don't
handle suspend correctly.  The HX chip can handle suspend gracefully,
but the type_1 can't.  When it resumes, the host controller detects it
as a low speed device; since it's actually a high speed device, this
fails.  The initialization for the two chips are different (see the
FISH/SOUP mess in pl2303.c), but I haven't experimented to see if
different initialization would help.

Is there somewhere to record devices that handle autosuspend correctly?
I saw some mention that the HAL people will take care of it, but I
haven't heard anything specific.

Sarah


> 
> 	Regards
> 		Oliver
> 
> Signed-off-by: Oliver Neukum <[email protected]>
> 
> ----
> 
> --- linux-2.6.24-rc1/drivers/usb/serial/usb-serial.c.alt	2007-10-30 13:38:10.000000000 +0100
> +++ linux-2.6.24-rc1/drivers/usb/serial/usb-serial.c	2007-10-30 13:38:47.000000000 +0100
> @@ -1249,6 +1249,7 @@ static void fixup_generic(struct usb_ser
>  	set_to_generic_if_null(device, read_bulk_callback);
>  	set_to_generic_if_null(device, write_bulk_callback);
>  	set_to_generic_if_null(device, shutdown);
> +	set_to_generic_if_null(device, resume);
>  }
>  
>  int usb_serial_register(struct usb_serial_driver *driver) /* must be called with BKL held */

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel