On Mon, Jul 30, 2012 at 05:03:27PM -0400, Alan Stern wrote: > On Mon, 30 Jul 2012, Sarah Sharp wrote: > > Possible solutions > > ------------------ > > > > - We need a new interface driver flag to indicate a driver is fine with > > the port being powered off. Something like "supports_power_off". > > > > - In addition to the port power sysfs values of "on" or "off", we also > > need an "auto" value that attempts to apply a smart in-kernel policy > > to when to power off the port. That policy might look like: > > > > 1. If the device is internal and unpluggable, power off the port > > That doesn't sound right. Don't you mean: If the port is internal and > not pluggable and there is no device attached, power off the port? If there's a device attached and the ACPI table reports the port is not "connectable", then there's something wrong with the ACPI table. > If the port is unpluggable and has no device, I don't see what > difference it makes whether the port is internal or external. External ports would never be marked as unpluggable, because the user can plug a device in. Internal ports can be unpluggable or pluggable. > > 2. If the device is internal and suspended, power off the port if all > > the following are true: > > > > a) all interface drivers have supports_power_off set, or no > > interface drivers are bound and usbfs has not claimed the > > device. > > b) remote wakeup is disabled > > c) USB_QUIRK_RESET_MORPHS is not set > > > > - If userspace wants a port to be powered off, and one of the interface > > drivers doesn't set supports_power_off or the driver enables remote > > wakeup, then userspace will need to unbind or unload the driver. > > Like other people, I'm dubious about these conditions. > > > So far, the discussion has been mainly focused on figuring out a smart > > policy for internal USB ports. However, I'd like to see the "auto" > > in-kernel policy extended to external USB ports. > > Really, what's the difference? Are you assuming that internal ports > are always "unpluggable" (i.e., devices cannot be plugged into or > unplugged from the port)? No. Some internal ports can be pluggable, like your card reader, or those ones behind an rfkill switch. But only internal ports can be "unpluggable". I'm apparently not explaining the ACPI methods very well. Can you please take a look at the Microsoft page on them and let me know if it clears up your confusion: http://msdn.microsoft.com/en-us/library/windows/hardware/ff553550%28v=vs.85%29.aspx > I'm not sure even that much is true. For example, my Asus laptop has a > USB card reader that's built-in. The connection is definitely > internal; the user cannot get at it (although I don't know what the > ACPI tables have to say about it). But the card reader disconnects > itself from the USB bus whenever there's no card inserted. > > At any rate, it seems that you should be focusing on pluggable vs. > unpluggable rather than internal vs. external. Ok, fine. I do think the internal vs external information could be useful to userspace to decide whether it should turn off a port, but I agree that unpluggable vs pluggable is more useful. > > Perhaps we need to > > expose the ACPI internal/external port and connectable/unconnectable > > values through sysfs, and apply the policy to both internal and external > > devices? > > > > Then userspace could look at whether a port is internal or external, and > > decide when it makes sense to auto-power-off the port. It could decide > > to set an "auto" policy on all ports when the screen blanks. When the > > user starts interacting with the system and the screen turns back on, > > userspace could change the policy back to "on" for external ports and > > internal connectable ports. > > > > Then policy #1 would just change to "If the device is disconnected, > > power off the port" and policy #2 would apply to both internal and > > external suspended ports. > > > > Thoughts? > > I tend to agree that having the kernel make these decisions is fraught > with difficulties, except in the most simple cases (unpluggable and no > device present). > > Exposing the extra attributes to userspace can't hurt -- unless we want > to change or remove them in the future! Hmm, true. I suppose we could have a "no info" output if the ACPI port info isn't there, and that would allow us to deprecate the API in the future. 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
