From: Pavel Machek <pavel@ucw.cz>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Linux-pm mailing list <linux-pm@lists.osdl.org>
Subject: Re: Re: Hotplug events during sleep transition
Date: Sun, 25 Dec 2005 20:52:39 +0100 [thread overview]
Message-ID: <20051225195239.GA1787@elf.ucw.cz> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0512251133010.31812-100000@netrider.rowland.org>
[-- Attachment #1: Type: text/plain, Size: 3726 bytes --]
Hi!
> > > Add suspend and resume methods to usblp, but make it so they
> > > only cancel outstanding I/O, while relying on usbcore to fail
> > > any new I/O requests?
> >
> > It is not *that* bad, actually. In system suspend/resume cases, no new
> > I/O requests can happen, because userspace is frozen. Because of
> > runtime suspend, you should handle I/O errors properly, but you should
> > handle I/O errors properly, anyway, so... looks like a solution to me.
>
> You're right, it's not really all that bad. Note however that in the PPC
> implementation, Ben H. does not freeze userspace before suspend to RAM.
Perhaps he'll change his mind ;-))))).
Yep, for ppc and runtime power management, this is not really
nice. But if someone forces our device into off state, perhaps
returning errors to userspace is acceptable solution?
> > > Unbind usblp in lieu of suspending it.
> >
> > If this can be done in reasonable ammount of not-too-ugly code, why
> > not? I think that even Patrick can be convinced by nice patch.
>
> This isn't very hard either. A sample patch is given below. I haven't
> tested it with vanilla 2.6.15-rc6, but a similar patch works okay on
> Greg's development tree. Apart from the FIXMEs, it's not bad at
> all.
Well, the FIXMEs look quite nasty to my untrained eye...
Pavel
> Index: linux-2.6.15-rc6/drivers/usb/core/usb.c
> ===================================================================
> --- linux-2.6.15-rc6.orig/drivers/usb/core/usb.c
> +++ linux-2.6.15-rc6/drivers/usb/core/usb.c
> @@ -1431,8 +1431,17 @@ static int usb_generic_suspend(struct de
> else
> mark_quiesced(intf);
> } else {
> - // FIXME else if there's no suspend method, disconnect...
> - dev_warn(dev, "no %s?\n", "suspend");
> + dev_warn(dev, "no suspend for %s? unbinding...\n",
> + driver->name);
> + up(&dev->sem);
> +
> + /*
> + * FIXME: You're not supposed to do this without holding
> + * the USB device lock. But we can't just grab the lock
> + * because our caller might already be holding it.
> + */
> + usb_driver_release_interface(driver, intf);
> + down(&dev->sem);
> status = 0;
> }
> return status;
> @@ -1459,9 +1468,22 @@ static int usb_generic_resume(struct dev
> return usb_resume_device (to_usb_device(dev));
> }
>
> - if ((dev->driver == NULL) ||
> - (dev->driver_data == &usb_generic_driver_data))
> + /* try to bind interfaces that have no driver */
> + if (dev->driver == NULL) {
> + up(&dev->sem);
> +
> + /*
> + * FIXME: You're not supposed to do this without holding
> + * the USB device lock. But we can't just grab the lock
> + * because our caller might already be holding it.
> + */
> + device_attach(dev);
> + down(&dev->sem);
> return 0;
> + }
> +
> + if (dev->driver_data == &usb_generic_driver_data)
> + return 0; /* Shouldn't happen */
>
> intf = to_usb_interface(dev);
> driver = to_usb_driver(dev->driver);
> @@ -1481,7 +1503,7 @@ static int usb_generic_resume(struct dev
> mark_quiesced(intf);
> }
> } else
> - dev_warn(dev, "no %s?\n", "resume");
> + dev_warn(dev, "no resume for %s?\n", driver->name);
> return 0;
> }
>
> Index: linux-2.6.15-rc6/drivers/usb/core/hub.c
> ===================================================================
> --- linux-2.6.15-rc6.orig/drivers/usb/core/hub.c
> +++ linux-2.6.15-rc6/drivers/usb/core/hub.c
> @@ -1838,12 +1838,6 @@ int usb_resume_device(struct usb_device
>
> usb_unlock_device(udev);
>
> - /* rebind drivers that had no suspend() */
> - if (status == 0) {
> - usb_lock_all_devices();
> - bus_rescan_devices(&usb_bus_type);
> - usb_unlock_all_devices();
> - }
> return status;
> }
>
>
--
Thanks, Sharp!
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
next prev parent reply other threads:[~2005-12-25 19:52 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-22 14:28 Hotplug events during sleep transition Alan Stern
2005-12-22 14:34 ` Pavel Machek
2005-12-22 18:20 ` Dmitry Torokhov
2005-12-22 20:52 ` Patrick Mochel
2005-12-22 20:56 ` Randy.Dunlap
2005-12-22 22:13 ` Alan Stern
2005-12-23 3:49 ` Patrick Mochel
2005-12-23 3:52 ` Dmitry Torokhov
2005-12-23 15:20 ` Alan Stern
2005-12-23 15:35 ` Patrick Mochel
2005-12-23 16:52 ` Alan Stern
2005-12-23 17:20 ` Pavel Machek
2005-12-23 21:22 ` Alan Stern
2005-12-23 21:28 ` Greg KH
2005-12-23 22:09 ` Nigel Cunningham
2005-12-23 22:31 ` Pavel Machek
2005-12-23 22:40 ` Nigel Cunningham
2005-12-23 22:48 ` Pavel Machek
2005-12-23 22:57 ` Nigel Cunningham
2005-12-24 0:29 ` Nigel Cunningham
2005-12-24 15:11 ` Alan Stern
2005-12-24 15:28 ` Pavel Machek
2005-12-24 17:02 ` Greg KH
2005-12-23 21:28 ` Pavel Machek
2005-12-23 19:40 ` Greg KH
2005-12-24 0:23 ` Patrick Mochel
2005-12-25 2:56 ` Alan Stern
2005-12-25 8:53 ` Pavel Machek
2005-12-25 16:43 ` Alan Stern
2005-12-25 16:52 ` Dmitry Torokhov
2005-12-25 19:54 ` Pavel Machek
2005-12-25 19:52 ` Pavel Machek [this message]
2005-12-26 3:53 ` Alan Stern
2005-12-26 21:20 ` Patrick Mochel
2005-12-26 22:50 ` Dmitry Torokhov
2005-12-26 23:01 ` Alan Stern
2005-12-27 21:45 ` Dmitry Torokhov
2005-12-27 22:08 ` Pavel Machek
2005-12-27 22:21 ` Dmitry Torokhov
2005-12-27 22:31 ` Pavel Machek
2005-12-27 22:39 ` Dmitry Torokhov
2005-12-27 22:44 ` Pavel Machek
2005-12-29 2:07 ` Alan Stern
2005-12-27 21:09 ` Patrick Mochel
2005-12-27 21:51 ` Dmitry Torokhov
2005-12-28 4:36 ` Patrick Mochel
2005-12-28 6:11 ` Dmitry Torokhov
2005-12-28 10:59 ` Rafael J. Wysocki
2005-12-29 2:18 ` Alan Stern
2005-12-29 2:55 ` Nigel Cunningham
2005-12-29 11:29 ` Rafael J. Wysocki
2005-12-30 17:46 ` Alan Stern
2006-01-04 23:31 ` Pavel Machek
2006-01-05 16:07 ` Alan Stern
2006-01-05 19:05 ` Pavel Machek
2005-12-29 2:13 ` Alan Stern
2005-12-29 2:10 ` Alan Stern
2005-12-29 5:20 ` Dmitry Torokhov
2005-12-30 18:26 ` Alan Stern
2005-12-30 19:18 ` Dmitry Torokhov
2005-12-30 19:26 ` Alan Stern
2005-12-30 19:42 ` Dmitry Torokhov
2005-12-30 20:13 ` Alan Stern
2005-12-29 2:02 ` Alan Stern
2005-12-30 18:34 ` Patrick Mochel
2005-12-30 19:21 ` Alan Stern
2006-01-02 23:49 ` Patrick Mochel
2005-12-26 23:25 ` Alan Stern
2005-12-23 18:32 ` Dmitry Torokhov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20051225195239.GA1787@elf.ucw.cz \
--to=pavel@ucw.cz \
--cc=linux-pm@lists.osdl.org \
--cc=stern@rowland.harvard.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.