From: "Randy.Dunlap" <rdunlap@xenotime.net>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: mailing list <linux-pm@lists.osdl.org>,
USB development list <linux-usb-devel@lists.sourceforge.net>,
Linux-pm@sc8-sf-spam2.sourceforge.net,
Kernel development list <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] USB device persistence across suspend-to-disk
Date: Tue, 5 Sep 2006 09:13:18 -0700 [thread overview]
Message-ID: <20060905091318.42c273d2.rdunlap@xenotime.net> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0609051104260.14667-100000@iolanthe.rowland.org>
On Tue, 5 Sep 2006 11:26:48 -0400 (EDT) Alan Stern wrote:
> Index: mm/Documentation/usb/persist.txt
> ===================================================================
> --- /dev/null
> +++ mm/Documentation/usb/persist.txt
> @@ -0,0 +1,154 @@
> +
> + What is the solution?
> +
> +Setting the "persist=y" module parameter for usbcore will cause the
persist=1 ??
> +kernel to work around these issues. If usbcore is build into the
s/build/built/
> +main kernel instead of as a separate module, you can put
> +"usbcore.persist=1" on the boot command line. You can also change the
> +kernel's behavior on the fly using sysfs: Type
> +
> + echo y >/sys/module/usbcore/parameters/persist
Does sysfs treat 'y' as '1'?
Anyway, it would be Good to be consistent.
> +to turn the option on, and replace the 'y' with an 'n' to turn it off.
> +
> +The "persist" option enables a mode in which the core USB device data
> +structures are allowed to persist across a power-session disruption.
> +It works like this. If the kernel sees that a USB host controller is
> +not in the expected state during resume (i.e., if the controller was
> +reset or otherwise had lost power) then it applies a persistence check
> +to each of the USB devices below that controller. It doesn't try to
> +resume the device; that can't work once the power session is gone.
> +Instead it issues a USB port reset followed by a re-enumeration.
> +(This is exactly the same thing that happens whenever a USB device is
> +reset.) If the re-enumeration shows that the device now attached to
> +that port has the same descriptors as before, including the Vendor and
> +Product IDs, then the kernel continues to use the same device
> +structure. In effect, the kernel treats the device as though it had
> +merely been reset instead of unplugged.
so does the USB device also retain its same USB address?
> Index: mm/drivers/usb/core/message.c
> ===================================================================
> --- mm.orig/drivers/usb/core/message.c
> +++ mm/drivers/usb/core/message.c
> @@ -764,7 +764,7 @@ int usb_string(struct usb_device *dev, i
> err = -EINVAL;
> goto errout;
> } else {
> - dev->have_langid = -1;
> + dev->have_langid = 1;
> dev->string_langid = tbuf[2] | (tbuf[3]<< 8);
> /* always use the first langid listed */
> dev_dbg (&dev->dev, "default language 0x%04x\n",
Different patch (?).
---
~Randy
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
next prev parent reply other threads:[~2006-09-05 16:13 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-05 15:26 [RFC] USB device persistence across suspend-to-disk Alan Stern
2006-09-05 16:13 ` Randy.Dunlap [this message]
2006-09-05 16:59 ` Alan Stern
2006-09-06 5:36 ` [linux-pm] " Pavel Machek
2006-09-06 15:09 ` Greg KH
2006-09-19 17:52 ` David Brownell
2006-09-19 20:25 ` Alan Stern
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=20060905091318.42c273d2.rdunlap@xenotime.net \
--to=rdunlap@xenotime.net \
--cc=Linux-pm@sc8-sf-spam2.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@lists.osdl.org \
--cc=linux-usb-devel@lists.sourceforge.net \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox