On 2012年07月19日 14:37, Oliver Neukum wrote:
On Wednesday 18 July 2012 15:07:14 Sarah Sharp wrote:
On Wed, Jul 18, 2012 at 09:03:59PM +0200, Oliver Neukum wrote:
No, now that I think about it an attribute for the drivers is necessary.
Like drivers have "supports_autosuspend" they also should have
"supports_power_off". In addition it is necessary for ports to have
an attribute in sysfs which allows user space to block power off.
And it is a bit complicated. Power may be cut, if
a) a port is internal and unpluggable, or
b) a port is internal and it's interfaces' drivers set "supports_power_off", unless:
1) remote wakeup is requested
2) user space has blocked it via the new sysfs attribute
3) USB_QUIRK_RESET_MORPHS is set
Yes, that sounds like a good kernel policy. Thanks for pointing out the
USB_QUIRK_RESET_MORPHS; I didn't know we had a specific quirk for
devices that will morph into a different class of USB devices on a
reset.
It is supposed to be set (from user space) for 3G cards that feature a
mini-SD card reader which the storage driver would reset during error
handling.
What if the user really wants the bluetooth device off? I have only
used the bluetooth on my laptop once in the year I've had it. Whenever I
boot my Ubuntu box, I go up to the bluetooth icon in the tray and turn
it off. It would be nice at that point to have the bluetooth driver
unloaded and the port turned completely off.
Unloading the driver is a user space issue.
But you are right there is a missing case
c) a port is internal and its device's interfaces are all not bound to a driver,
if user space has requested it,
unless usbfs has claimed an interface.
I think we're going to need to help userspace serialize port power
management somehow. Why not create a new sysfs file with ioctls similar
to the usbfs claim port interface to allow only one userspace process to
control the port power at a time?
Because you'd go down a road which is a dead end.
We want "auto-power-on" in an ideal case. It has to be triggered by the driver.
The driver can be accessed from user space and access to it cannot be serialized
by such methods. You'd implement a scheme that would very soon become
counter-productive.
This can be best seen in the case of the ubiquitous internal webcams.
They'd work and save maximum power.
But this leaves me with a question. Has anybody ever measured the additional
power savings compared to a suspended state for devices? Or are you doing
this only as a prelude to become able to send host controllers to D3cold?
hi Oliver:
I have done a test on a usb3.0 ORICO SSD which may cost 3w normally.
Traditional suspend can save 1w. Power off can save additional 2w. I also test
on some other usb2.0 flashs. The additional power saving is very limit. Because
the precision of power meter is not good, I can not get exact power saving.
Furthermore if you go with this scheme you can eventually extend it to external
ports.
Regards
Oliver
--
Best Regards
Tianyu Lan
linux kernel enabling team
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
