On Monday, September 24, 2012, Alan Stern wrote: > 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.
OK > > > > 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? > > > > 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? Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
