linux-kernel - usb autosuspend is history after S2R (also on 2.6.31; UVC?)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090915185145.GA31490@rhlx01.hs-esslingen.de>
Date:	Tue, 15 Sep 2009 20:51:45 +0200
From:	Andreas Mohr <andi@...as.de>
To:	Alan Stern <stern@...land.harvard.edu>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	laurent.pinchart@...net.be, Matthew Garrett <mjg59@...f.ucam.org>
Cc:	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: usb autosuspend is history after S2R (also on 2.6.31; UVC?)

Hi,

currently running 2.6.31, and what I've been suspecting for quite some
time (several weeks) is actually true: after S2R resume
all friendly USB autosuspend settings are history and we're back
to the dreaded old 100% activity (powertop -d):

Recent USB suspend statistics
Active  Device name
100.0%  USB device  5-5 : Acer Crystal Eye webcam (SuYin)
100.0%  USB device usb5 : EHCI Host Controller (Linux 2.6.31 ehci_hcd)
  0.0%  USB device usb4 : UHCI Host Controller (Linux 2.6.31 uhci_hcd)
  0.0%  USB device usb3 : UHCI Host Controller (Linux 2.6.31 uhci_hcd)
  0.0%  USB device usb2 : UHCI Host Controller (Linux 2.6.31 uhci_hcd)
  0.0%  USB device usb1 : UHCI Host Controller (Linux 2.6.31 uhci_hcd)

Is there any fix planned for this? This is possibly even more important
(power wasted due to wakeups, I'd judge it to be up to 1.5W on this 8.5W
Aspire One machine) than any other runtime PM implementation...

OTOH this problem is probably isolated to uvc devices, since:
# lsusb -t
/:  Bus 05.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/8p, 480M
    |__ Port 5: Dev 7, If 0, Class='bInterfaceClass 0x0e not yet handled', Driver=uvcvideo, 480M
    |__ Port 5: Dev 7, If 1, Class='bInterfaceClass 0x0e not yet handled', Driver=uvcvideo, 480M
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M

So, does the uvc driver need a bit of handholding here?
It likely shouldn't simply forget about its autosuspend status after
resume...

Or would Matthew's uvc autosuspend patch
http://osdir.com/ml/fedora-extras-commits/2009-07/msg06079.html
help here?

Thanks,

Andreas Mohr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/