[PATCH 1/3] UEAGLE : be suspend friendly

[PATCH 1/3] UEAGLE : be suspend friendly

[matthieu castet]

[-- Attachment #1: Type: text/plain, Size: 185 bytes --]

Hi,


this patch avoid that the kernel thread block the suspend process.
Some work is still need to recover after a resume.


Signed-off-by: Matthieu CASTET <castet.matthieu@free.fr>



[-- Attachment #2: eagle-suspend --]
[-- Type: text/plain, Size: 711 bytes --]

this patch avoid that the kernel thread block the suspend process.
Some work is still need to recover after a resume.

Signed-off-by: matthieu castet <castet.matthieu@free.fr>
Index: linux/drivers/usb/atm/ueagle-atm.c
===================================================================
--- linux.orig/drivers/usb/atm/ueagle-atm.c	2006-09-22 21:39:56.000000000 +0200
+++ linux/drivers/usb/atm/ueagle-atm.c	2006-09-22 21:40:45.000000000 +0200
@@ -1177,6 +1177,9 @@
 			ret = uea_stat(sc);
 		if (ret != -EAGAIN)
 			msleep(1000);
+ 		if (try_to_freeze())
+			uea_err(INS_TO_USBDEV(sc), "suspend/resume not supported, "
+				"please unplug/replug your modem\n");
 	}
 	uea_leaves(INS_TO_USBDEV(sc));
 	return ret;

Re: [PATCH 1/3] UEAGLE : be suspend friendly

[Pavel Machek]

Hi!

You marked all the patches as 1/3, btw.

> this patch avoid that the kernel thread block the suspend process.
> Some work is still need to recover after a resume.
> 
> Signed-off-by: Matthieu CASTET <castet.matthieu@free.fr>
> 
> 

> this patch avoid that the kernel thread block the suspend process.
> Some work is still need to recover after a resume.
> 
> Signed-off-by: matthieu castet <castet.matthieu@free.fr>
> Index: linux/drivers/usb/atm/ueagle-atm.c
> ===================================================================
> --- linux.orig/drivers/usb/atm/ueagle-atm.c	2006-09-22 21:39:56.000000000 +0200
> +++ linux/drivers/usb/atm/ueagle-atm.c	2006-09-22 21:40:45.000000000 +0200
> @@ -1177,6 +1177,9 @@
>  			ret = uea_stat(sc);
>  		if (ret != -EAGAIN)
>  			msleep(1000);
> + 		if (try_to_freeze())
> +			uea_err(INS_TO_USBDEV(sc), "suspend/resume not supported, "
> +				"please unplug/replug your modem\n");

Plug/unplug should be easy enough to simulate from usb driver, no?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH 1/3] UEAGLE : be suspend friendly

[Duncan Sands]

Hi Pavel,

> > Signed-off-by: matthieu castet <castet.matthieu@free.fr>
> > Index: linux/drivers/usb/atm/ueagle-atm.c
> > ===================================================================
> > --- linux.orig/drivers/usb/atm/ueagle-atm.c	2006-09-22 21:39:56.000000000 +0200
> > +++ linux/drivers/usb/atm/ueagle-atm.c	2006-09-22 21:40:45.000000000 +0200
> > @@ -1177,6 +1177,9 @@
> >  			ret = uea_stat(sc);
> >  		if (ret != -EAGAIN)
> >  			msleep(1000);
> > + 		if (try_to_freeze())
> > +			uea_err(INS_TO_USBDEV(sc), "suspend/resume not supported, "
> > +				"please unplug/replug your modem\n");
> 
> Plug/unplug should be easy enough to simulate from usb driver, no?

if a USB driver doesn't define suspend/resume methods, then the core simply
unplugs it on suspend, and replugs on resume (IIRC).  Maybe Matthieu is trying
for something better - hopefully he will explain.  Since this is a modem, it
would be nice if the internet connection sprang back to life on resume, which
requires more work than unplug/plug.  I've no idea what needs to be done to achieve
this.  These modems use the ATM networking layer by the way, I don't know if that
makes things easier or harder.

Ciao,

Duncan.

Re: [linux-usb-devel] [PATCH 1/3] UEAGLE : be suspend friendly

[Alan Stern]

On Thu, 5 Oct 2006, Duncan Sands wrote:

> > Plug/unplug should be easy enough to simulate from usb driver, no?
> 
> if a USB driver doesn't define suspend/resume methods, then the core simply
> unplugs it on suspend, and replugs on resume (IIRC).

No longer true, and IIRC it never was.  All that happens is that URB 
submissions fail with -EHOSTUNREACH once the device is suspended.

Alan Stern

Re: [linux-usb-devel] [PATCH 1/3] UEAGLE : be suspend friendly

[Pavel Machek]

Hi!

> > > Plug/unplug should be easy enough to simulate from usb driver, no?
> > 
> > if a USB driver doesn't define suspend/resume methods, then the core simply
> > unplugs it on suspend, and replugs on resume (IIRC).
> 
> No longer true, and IIRC it never was.  All that happens is that URB 
> submissions fail with -EHOSTUNREACH once the device is suspended.

Could we get "old" behaviour for devices like this? "printk("please
unplug/replug me\n")" is not a good solution.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [linux-usb-devel] [PATCH 1/3] UEAGLE : be suspend friendly

[Alan Stern]

On Thu, 5 Oct 2006, Pavel Machek wrote:

> Hi!
> 
> > > > Plug/unplug should be easy enough to simulate from usb driver, no?
> > > 
> > > if a USB driver doesn't define suspend/resume methods, then the core simply
> > > unplugs it on suspend, and replugs on resume (IIRC).
> > 
> > No longer true, and IIRC it never was.  All that happens is that URB 
> > submissions fail with -EHOSTUNREACH once the device is suspended.
> 
> Could we get "old" behaviour for devices like this? "printk("please
> unplug/replug me\n")" is not a good solution.

I would much rather see this fixed in the driver itself.

For the time being, a "dummy" suspend routine could look like this:

static int foo_suspend(struct usb_interface *intf, pm_message_t msg)
{
	up(&intf->dev.sem);
	device_release_driver(&intf->dev);
	down(&intf->dev.sem);
	return 0;
}

Getting reprobed during resume would be more difficult; it would need help 
from userspace.

Maybe UEAGLE can do something a little more sensible...

Alan Stern

Re: [linux-usb-devel] [PATCH 1/3] UEAGLE : be suspend friendly

[Duncan Sands]

> Maybe UEAGLE can do something a little more sensible...

What is the modem supposed to do if it receives a packet to
transmit after it has been told to suspend?  This is a real
question, I'm not pretending!  I've never thought about or
read about suspend/resume and have no idea how it is supposed
to work.  Should it just reject it, or should it wake the
modem up?

Ciao,

Duncan.

Re: [linux-usb-devel] [PATCH 1/3] UEAGLE : be suspend friendly

[Alan Stern]

On Fri, 6 Oct 2006, Duncan Sands wrote:

> > Maybe UEAGLE can do something a little more sensible...
> 
> What is the modem supposed to do if it receives a packet to
> transmit after it has been told to suspend?  This is a real
> question, I'm not pretending!  I've never thought about or
> read about suspend/resume and have no idea how it is supposed
> to work.  Should it just reject it, or should it wake the
> modem up?

It depends on the context in which the modem was suspended.  If this was a 
regular system sleep transition, or some other suspend request coming from 
outside the driver, then packets should be dropped.

But if the suspend originated within the driver itself, as a power-saving 
measure while the connection was idle, then new packets should cause the 
driver to wake the modem up.  That is, self-originated suspends should be 
transparent.  Outside-originated suspends are someone else's problem.

Alan Stern