On Tue, Jul 17, 2012 at 03:00:08PM -0400, Alan Stern wrote: > 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_? Yes. English fail due to cold symptoms. > 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. Ok, yes, point taken. > 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? Ok, here's the "safe" plan that we could implement in the kernel that should have no visible user impact (aside from power savings): 1. If a USB port is empty and the ACPI _UPC and _PLD indicate that it's an internal USB port that will remain empty, power off the port. 2. If an internal USB port is suspended with remote wakeup disabled, power off the port. Add code to the USB core to ignore the device disconnect in this special case, so the driver thinks the device is still suspended. Issue a reset-resume when the driver wants to resume the device. That policy would be safe, because for 1) we would never see a USB device connection, and thus wouldn't miss the connection when we powered off the port. 2) is safe because we won't miss a remote wakeup while the port is powered off, and the device can't be disconnected by the user because it's an internal USB device. There are a couple places in the USB core where we could add hooks to implement those policies. When a hub is enumerated, we could check the ACPI _UPC and _PLC for the port, and power it off if it's an internal empty port. When the USB device is suspended with remote wakeup off, we could power down the port, and repower it when the driver resumes the device. The grand master plan involves userspace knowing when a user is inactive and using the new sysfs files to power off empty external ports. I suppose we would need some sysfs files to expose the ACPI state to userspace in that case. > 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. > :-) Eh, sure. A libusb program could simulate a disconnect of a misbehaving USB device through the sysfs files. Which means we can't prevent userspace from powering off a port for any particular reason. Sarah Sharp -- 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
