On 2012/7/17 21:48, Oliver Neukum wrote:
On Tuesday 17 July 2012 21:35:00 Lan Tianyu wrote:
On 2012/7/16 22:13, Alan Stern wrote:
On Mon, 16 Jul 2012, Lan Tianyu wrote:
Currently, "power/wakeup" sysfs file can't control remote wakeup in the runtime
suspend. It only depends on "usb_interface->needs_remote_wakeup" to determine
whether enable remote wakeup or not when runtime suspending. Usr space has no
choice. This patch is to enable "power/wakeup" to control remote wakeup in the
runtime suspend.
As Oliver pointed out, you need to explain why this is needed.
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. 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.
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.
hi Oliver:
Thanks for reply. Why unbind driver? I am sorry I don't understand it.
Can you elaborate it for me? :)
When device is suspended, that means driver will not work, right?
Disable remote wakeup is to keep device being suspended in some
circumstances(system idle) which may be not willing to see device resuming.
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.
How to tell the driver?
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
