public inbox for linux-pm@vger.kernel.org
 help / color / mirror / Atom feed
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

  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