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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
