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 <[email protected]>
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;
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 <[email protected]>
>
>
> 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 <[email protected]>
> 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
Hi Pavel,
> > Signed-off-by: matthieu castet <[email protected]>
> > 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.
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
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
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
> 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.
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