From: David Brownell <david-b@pacbell.net>
To: linux-usb-devel@lists.sourceforge.net
Cc: Pavel Machek <pavel@ucw.cz>, Greg KH <greg@kroah.com>,
Andrew Morton <akpm@osdl.org>,
linux-pm@osdl.org, Jiri Slaby <jirislaby@gmail.com>,
linux-kernel@vger.kernel.org, Mattia Dongili <malattia@linux.it>,
Alan Stern <stern@rowland.harvard.edu>
Subject: Re: [PATCH] get USB suspend to work again on 2.6.17-mm1
Date: Tue, 27 Jun 2006 10:38:39 -0700 [thread overview]
Message-ID: <200606271038.40510.david-b@pacbell.net> (raw)
In-Reply-To: <20060627090304.GA29199@elf.ucw.cz>
> > > > And we also need to be able to handle devices in the device tree that do
> > > > not have a suspend/resume function ...
> > >
> > > Ah, there's the rub. If a driver doesn't have suspend/resume methods, is
> > > it because it doesn't need them, or is it because nobody has written them
> > > yet? In the latter case, failing the suspend or unbinding the driver are
> > > the only safe courses.
> >
> > No, if it's not there, just expect that it knows what it is doing, and
> > don't fail the thing. Unless you want to add those methods to _every_
> > driver in the kernel, and that's going to be a lot of work...
It seems reasonable to me to require that drivers have at least
stub "it's actually OK to do nothing here" suspend/resume methods.
> I believe 90% of drivers need them, anyway... Idea is that if we
> refuse the suspend, user has dmesg and did not loose his work. If we
> suspend but can't resume due to driver problems, it is slightly more
> interesting to debug, and user lost open applications.
Or as I put it earlier, a clean failure right at the "suspend/resume
method missing" point is more robust than unpredictable failures much
later (long after that actual failure points).
- Dave
next prev parent reply other threads:[~2006-06-27 17:38 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-22 20:29 [PATCH] get USB suspend to work again on 2.6.17-mm1 Greg KH
2006-06-22 21:27 ` Jiri Slaby
2006-06-22 21:28 ` Mattia Dongili
2006-06-22 21:34 ` Mattia Dongili
2006-06-22 23:24 ` David Brownell
2006-06-22 23:51 ` Greg KH
2006-06-23 2:45 ` Alan Stern
2006-06-23 4:26 ` Greg KH
2006-06-23 14:28 ` Alan Stern
2006-06-23 3:34 ` David Brownell
2006-06-23 4:24 ` Greg KH
2006-06-23 14:51 ` Alan Stern
2006-06-23 15:38 ` David Brownell
2006-06-26 23:57 ` Greg KH
2006-06-27 2:04 ` David Brownell
2006-06-27 15:24 ` Alan Stern
2006-06-27 23:28 ` Greg KH
2006-06-27 23:26 ` Greg KH
2006-06-27 9:03 ` Pavel Machek
2006-06-27 17:38 ` David Brownell [this message]
2006-06-27 23:20 ` Greg KH
2006-06-25 2:42 ` [linux-pm] " Jim Gettys
2006-06-25 4:32 ` David Brownell
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=200606271038.40510.david-b@pacbell.net \
--to=david-b@pacbell.net \
--cc=akpm@osdl.org \
--cc=greg@kroah.com \
--cc=jirislaby@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@osdl.org \
--cc=linux-usb-devel@lists.sourceforge.net \
--cc=malattia@linux.it \
--cc=pavel@ucw.cz \
--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