On Mon, 24 Sep 2012, Rafael J. Wysocki wrote: > I don't mean this. > > Suppose that there are two ports on the hub, A and B, and there's only one > power resource used to put A _and_ B into D3cold. Then, when you call > acpi_bus_set_power(A, D3cold) on A alone, what really happens is that the > power resource's reference counter is decremented and power isn't really > removed from the port. To actually remove power from A you'd need to > call acpi_bus_set_power(B, D3cold) too, but then it would be removed from > _both_ A and B simultaneously. > > Your simple sysfs interface doesn't match this use case. It's not quite that simple. The USB spec does require that a port essentially stop functioning when its power feature is disabled -- even if the port is ganged with others and therefore remains at full power. I don't know if we need to worry about such subtleties. > > > 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. > > > 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. Alan Stern -- 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
