Sorry for the delay, I have been distracted by a number of things. On Monday 24 of September 2012 15:10:36 Sarah Sharp wrote: > On Tue, Sep 25, 2012 at 12:09:06AM +0200, Rafael J. Wysocki wrote: > > On Monday, September 24, 2012, Alan Stern wrote: > > > On Mon, 24 Sep 2012, Rafael J. Wysocki wrote: > > > > > > Second, I'm not sure if there's any way for user space to figure out what > > > > > > ports are connected to what sockets visible to user space. If there is such > > > > > > a way, I wonder what it is, if not, the proposed interface is just plain > > > > > > dangerous. > > > > > ACPI _PLD method provides a lot of information to describe where the > > > > > port located in. But currently it is not exposed to user space. > > > > > > > > Well, precisely. Which means that the user would have to apply trial-and-error > > > > to figure out which sysfs file corresponds to which physical port on his/her > > > > machine. > > > > > > > > That doesn't sound really user friendly. > > > > > > It doesn't have to be trial-and-error. We should add symlinks between > > > the sysfs directory for a USB device and the directory for the port it > > > is plugged into. > > > > > > In fact, Tianyu, that would be a good patch to do next. > > > > Well, in my opinion it's rather requisite for adding the direct port power > > control interface. > > > > What about hubs connected to such ports? I don't think they're going to > > work when power is removed from it, are they? > > USB hubs would have remote wakeup enabled, so we would never power off > their port with the "auto" policy. Here's my idea how to arrange things. Why don't make runtime PM manage the USB port power on/off such that the port's .runtime_suspend() routine will remove power from it, if PM_QOS_FLAG_NO_POWER_OFF is not (effectively) set for it, and its .runtime_resume() will restore power to it (if removed previously). The USB core will then do pm_runtime_get_sync() on the port every time a device depending on it is added and pm_runtime_put() every time such a device is removed. The initial setting of PM_QOS_FLAG_NO_POWER_OFF in the PM QoS request structure used by user space will depend on the type of the port (e.g. it will be unset for ports that aren't visible to the user and connectable). That should allow things to work automatically and it should allow user space to override the defaults in any case, either by disabling runtime PM for the ports altogether (by writing "on" to their device objects' "control" sysfs files), or by setting/unsetting PM_QOS_FLAG_NO_POWER_OFF in the PM QoS request controlled by it as desired. > > > > > > Finally, it follows from my experience that interfaces of this kind often > > > > > > are sources of pain and grief for distro support folks who need to handle > > > > > > problems reported by users. I used to do that and I know what kind of pain > > > > > > that is. So, in my opinion it's better not to expose low-level functionality > > > > > > to user space directly, like in this case. > > > > > > > > > > You mean force power on and power off? There is a demand that if a usb > > > > > device was abnormal, user space driver or app could make it rework via > > > > > power off. > > > > > > > > Well, then implement it as a "hard reset" attribute on the device. Namely, > > > > if the device is attached to a power-manageable port, writing 1 (for example) > > > > to its "hard reset" attribute will cause the port to be power-cycled (as > > > > long as the port has its own power resource, that is). > > > > > > A few people want to use their USB ports as digital output signals. > > > For this purpose they want to be able to control the port power > > > directly. However, this is relatively rare. > > > > Out of curiosity, does it apply to empty ports or ports with devices connected > > to them? > > There are things like USB lights or fans that pull port power, but don't > actually enumerate as a USB device. So to the OS, those would be > "empty" ports. But they would be external ports, so the default "auto" > policy would never power off external ports. The user could write a > small script to PWM the fan on and off to control the speed. It would > just be a novelty though, as Alan said. For those things we can provide a "raw port driver" with ioctls allowing user space to get the port's physical location information from the kernel, if available, and manipulate the port's power on the low level. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- 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
