public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Maxim <maximlevitsky@gmail.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Kernel development list <linux-kernel@vger.kernel.org>,
	USB development list <linux-usb-devel@lists.sourceforge.net>,
	gregkh@suse.de
Subject: Re: USB: on suspend to ram/disk all usb devices are replugged
Date: Tue, 27 Mar 2007 19:54:42 +0200	[thread overview]
Message-ID: <200703271954.42628.maximlevitsky@gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0703271306230.2558-100000@iolanthe.rowland.org>

On Tuesday 27 March 2007 19:15:14 Alan Stern wrote:
> On Tue, 27 Mar 2007, Maxim Levitsky wrote:
> 
> > Hi,
> > 	I noticed that after suspend/resume cycle all my usb devices are unplugged/replugged by uhci driver.
> > While it is not that big problem to me, that can be a real problem if a device is a flash card with mounted 
> > file-system, because disappeared device will cause file-system corruption.
> > 
> > I found why this happens.
> > 
> > drivers/usb/host/pci-quirks.c:uhci_check_and_reset_hc checks that the BIOS didn't play with USB controller, and on my system
> > with or without a USB Legacy support turned on in the BIOS, the BIOS does meddle with USB controller,
> > 
> > But I suggest adding a option that will allow the user to bypass that check, because for example on my system USB works perfectly
> > if I disable the checks that this function does (but I agree that those checks are  very valuable, since I almost sure that on many systems USB
> > won't work without resetting the USB controller.)
> 
> No.  It just isn't safe to do that.  If the BIOS has done something to the
> controller then it may very well have reset the attached devices too.  Or
> changed their addresses, or done something else equally drastic.

I agree, I was only saying a option to override this check, for users who know that this is not the case.

> 
> > Secondary,  this function checks for UHCI_USBCMD_CONFIGURE, that is not set on resume,
> > According to both UHCI and ICH8 documentation this is software only bit, but I didn't find any place in kernel where it is set,
> > (But such place exist, because reading from usb IO ports confirm that it is set during normal work, I will try to find it)
> 
> It is set in drivers/usb/host/uhci-hcd.c:start_rh().
Thanks a lot, it would take a lot of time to find that out to me,
> 
> > Disabling both check for UHCI_USBLEGSUP and UHCI_USBCMD_CONFIGURE makes all usb devices (I have mouse,keyborad, and joystick)
> > work fine on resume from ram without this "virtual" replugging.
> 
> The UHCI specification is rather sparse in many respects, and it doesn't 
> say what the host firmware should or should not do during a resume.  So 
> the driver has to be very conservative and assume that any indication of a 
> change means that the entire controller must be reset.
> 
> > Suspend to disk still causes "virtual replugging"  and I think that controller is reset and will unplug/replug devices anyway
> > Resolving this problem is very difficult. Maybe it possible to check on unplugging event that this caused by suspend  if the same device is
> > replugged then don't remove/reinstall driver, but this is very difficult to implement properly,
> > Maybe just refuse to suspend if some valuable device is connected (sorry if it is done this way already)
> 
> Long ago I posted a patch that would take care of all this.  Not just for
> UHCI, but for any USB controller.  Maybe I should dig it out, update it,
> and submit it.
This sounds great, where is it ? .... :-)
This will improve linux suspend to ram/disk a lot.
> 
> > Also I want to note that I didn't yet checked any EHCI devices, because I don't have any (I am going to buy a usb stick soon)
> > But I feel that the above will be true for ehci too....
> 
> EHCI controllers tend to be better behaved than UHCI controllers, perhaps
> because the specification is much more careful to explain what must be
> done.  In many cases a computer can resume from suspend-to-RAM with all 
> the EHCI-connected devices still intact.
Big thanks, maybe usb stick I am going to buy will work with suspend to ram....
> 
> Alan Stern
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Hi,

	Thanks a lot for so quick reply,
	I want to note to myself that making a assumptions generally a bad idea,
	Until now I thought that linux always unplugs/re plugs usb devices on suspend/resume,
	that this is normal, but it looks that linux is better... :-)

	Best regards,
		Maxim Levitsky

  reply	other threads:[~2007-03-27 17:54 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-27 16:24 USB: on suspend to ram/disk all usb devices are replugged Maxim Levitsky
2007-03-27 17:15 ` Alan Stern
2007-03-27 17:54   ` Maxim [this message]
2007-03-27 18:05   ` Pete Zaitcev
2007-03-27 23:29     ` Maxim
2007-04-01 15:29       ` Pavel Machek
2007-04-01 17:42         ` David Zeuthen
2007-04-01 17:50           ` Pavel Machek
2007-04-01 18:01             ` David Zeuthen
2007-04-01 18:29               ` Pavel Machek
2007-04-01 18:26             ` Alan Stern
2007-04-01 18:34               ` Pavel Machek
2007-04-01 20:53                 ` Rafael J. Wysocki
2007-04-02  2:54                   ` Alan Stern
2007-04-02 20:37                     ` Rafael J. Wysocki
2007-04-02 18:38               ` Chuck Ebbert
2007-04-02 19:36                 ` Pavel Machek
2007-04-06 22:23                   ` Nigel Cunningham
2007-04-02 14:49             ` Mark Lord
2007-04-02 18:28               ` Pavel Machek
2007-03-29 13:19 ` Mark Lord
2007-03-29 15:56   ` Alan Stern
2007-03-29 16:03     ` Mark Lord

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=200703271954.42628.maximlevitsky@gmail.com \
    --to=maximlevitsky@gmail.com \
    --cc=gregkh@suse.de \
    --cc=linux-kernel@vger.kernel.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