On 2012/7/17 22:26, Alan Stern wrote:
On Tue, 17 Jul 2012, Oliver Neukum wrote:
Yeah. Lost some background introduction. I recently try to realize usb
port power off mechanism for ports with device. So design, the port with
device only can be power off when remote wakeup disable.
Why is that? What happens if you power-off a port where the device has
remove wakeup enabled?
I will not power off a port where the device has remote wakeup enabled.
Only when disabled, the port will power off.
But I found
remote wakeup was entirely control by driver and userspace has no
control. needs_remote_wakeup is set to 1 when the device is opened.
What sort of driver are you talking about? An HID driver? Serial
driver?
I can find hid, bcm, serial, mouse, screen and some net device drivers
does such thing. set needs_remote_wakeup to 1 in open() and to 0 in
close(). Some net drivers will set it to 0 when network is stop.
But the driver will not work if you don't use remote wakeup when it needs it.
Under those circumstances you better unbind the driver.
So that means the device's remote wakeup can not be disabled and usb
port can not be powered off. So I try to provide a control of remote
wakeup to userspace. When system becomes idle such as blank screen,
some usb devices may be able to disable remote wakeup and power off.
Yes, this is an unsoved problem. But the approach is no good. Don't
disable remote wakeup behind the driver's back. Tell the driver that a reduced
level of service is acceptable.
The best way to do this might depend on the driver.
But in general, if a driver needs wakeup in order to work properly then
it _won't_ work when the port is powered off. So as Oliver says, the
user might as well unbind the driver first.
You mean userspace app unbind the driver? But some devices maybe work
properly when the port power on again and device is resumed. e.g
keyboard and mouse.
Alan Stern
--
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
