From: David Brownell <david-b@pacbell.net>
To: linux-usb-devel@lists.sourceforge.net
Cc: Johannes Berg <johannes@sipsolutions.net>,
rasmit.ranjan@wipro.com, linux-pm@lists.osdl.org,
Linux Kernel list <linux-kernel@vger.kernel.org>,
Pavel Machek <pavel@ucw.cz>
Subject: Re: [linux-pm] Remote wake up not working
Date: Tue, 13 Jun 2006 10:17:58 -0700 [thread overview]
Message-ID: <200606131018.00575.david-b@pacbell.net> (raw)
In-Reply-To: <1150215167.6305.6.camel@johannes>
On Tuesday 13 June 2006 9:12 am, Johannes Berg wrote:
> On Sat, 2006-06-10 at 13:28 +0000, Pavel Machek wrote:
>
> > I do not think we support remote wakeup these days. Code may be there,
> > but as noone ever uses it... perhaps it needs some fixing.
>
> Works fine with bluetooth on my powerbook, but then again, I can't turn
> it *off* which is rather annoying, but I think caused by the missing
> suspend/resume handlers in hci_usb :/
USB remote wakeup basically works today (given CONFIG_USB_SUSPEND),
and has worked for quite a few kernel releases now, given
(a) Working platform support. So for example ACPI will not-infrequently
do the wrong thing on resume, or the video driver misbehaves, and
so on. All too few systems work correctly with either (a1) "standby"
or (a2) "mem" when you write them to /sys/power/state, and the issues
have only rarely been related to USB. (I got some mail over the last
few days about one that boiled down to interrupt controller bugs.)
(b) Support in the USB drivers for suspend/resume. I've seen other
reports lately about hci_usb is missing usb suspend/resume calls,
leading to misbehavior. (I think someone checked in an odd patch
a while ago which change the failure mode for those missing calls
to something that was still broken, just not as obviously.) And
then there are the ALSA drivers, and quite a few others...
That's not to say that it's perfect -- the clock framework is still missing
a hook to help embedded USB hosts behave right, and the /proc/acpi/wakeup
state isn't even vaguely integrated with the driver model wakeup stuff -- but
there are no known blocking issues there inside the USB stack or the main
host controller drivers.
- Dave
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
prev parent reply other threads:[~2006-06-13 17:17 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-08 12:21 Remote wake up not working rasmit.ranjan
2006-06-08 18:46 ` David Brownell
2006-06-10 13:28 ` Pavel Machek
2006-06-13 16:12 ` Johannes Berg
2006-06-13 17:17 ` David Brownell [this message]
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=200606131018.00575.david-b@pacbell.net \
--to=david-b@pacbell.net \
--cc=johannes@sipsolutions.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@lists.osdl.org \
--cc=linux-usb-devel@lists.sourceforge.net \
--cc=pavel@ucw.cz \
--cc=rasmit.ranjan@wipro.com \
/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