On Wednesday 18 July 2012 15:07:14 Sarah Sharp wrote: > On Wed, Jul 18, 2012 at 09:03:59PM +0200, Oliver Neukum wrote: > > No, now that I think about it an attribute for the drivers is necessary. > > Like drivers have "supports_autosuspend" they also should have > > "supports_power_off". In addition it is necessary for ports to have > > an attribute in sysfs which allows user space to block power off. > > > > And it is a bit complicated. Power may be cut, if > > > > a) a port is internal and unpluggable, or > > > > b) a port is internal and it's interfaces' drivers set "supports_power_off", unless: > > > > 1) remote wakeup is requested > > 2) user space has blocked it via the new sysfs attribute > > 3) USB_QUIRK_RESET_MORPHS is set > > Yes, that sounds like a good kernel policy. Thanks for pointing out the > USB_QUIRK_RESET_MORPHS; I didn't know we had a specific quirk for > devices that will morph into a different class of USB devices on a > reset. It is supposed to be set (from user space) for 3G cards that feature a mini-SD card reader which the storage driver would reset during error handling. > What if the user really wants the bluetooth device off? I have only > used the bluetooth on my laptop once in the year I've had it. Whenever I > boot my Ubuntu box, I go up to the bluetooth icon in the tray and turn > it off. It would be nice at that point to have the bluetooth driver > unloaded and the port turned completely off. Unloading the driver is a user space issue. But you are right there is a missing case c) a port is internal and its device's interfaces are all not bound to a driver, if user space has requested it, unless usbfs has claimed an interface. > I think we're going to need to help userspace serialize port power > management somehow. Why not create a new sysfs file with ioctls similar > to the usbfs claim port interface to allow only one userspace process to > control the port power at a time? Because you'd go down a road which is a dead end. We want "auto-power-on" in an ideal case. It has to be triggered by the driver. The driver can be accessed from user space and access to it cannot be serialized by such methods. You'd implement a scheme that would very soon become counter-productive. This can be best seen in the case of the ubiquitous internal webcams. They'd work and save maximum power. But this leaves me with a question. Has anybody ever measured the additional power savings compared to a suspended state for devices? Or are you doing this only as a prelude to become able to send host controllers to D3cold? Furthermore if you go with this scheme you can eventually extend it to external ports. Regards Oliver -- 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
