On Tue, 17 Jul 2012, Sarah Sharp wrote: > On Tue, Jul 17, 2012 at 10:49:26PM +0800, Lan Tianyu wrote: > > 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. > > The reason behind this is because we will lose remote wakeups when the > port is powered off. The port power is completely removed and it looks > like a physical disconnect to both the host and the device. So we can't > power off a port where the device has remote wakeup enabled. Wouldn't it be more accurate to say you _don't want_ to power off such ports, even though you _can_? If you're giving control of port power to userspace, then it doesn't matter what _you_ want. What matters is what the _user_ wants. Furthermore, what happens if you power down a port when the attached device is active (not suspended)? Again it will look like a physical disconnect. So again, you don't want to power off such ports -- even though they don't have remote wakeup enabled. I guess this comes down to deciding how much power you want to give the user. Are you saying that the user should be prevented from powering down a port unless: there is no device attached, or the attached device is suspended with wakeup disabled? But the justification seems weak. If powering down a port looks exactly like a disconnect, then you should allow powering down to the same extent that you allow disconnects. Last time I checked, the kernel did not try to prevent users from unplugging their USB devices. :-) Alan Stern -- 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
