On Thu, 25 May 2017, Harald Welte wrote: > What are you referring-to specifically? We have two distinct issues > here: > > a) the fact that you can "remove" the device (disable the "enable" > feature), but there is no similar interface for re-enabling the > "enable" feature (which appears to be done implicitly by setting the > "reset" feature). I think this should be safe and well within the > USB spec, shouldn't it? You misunderstand the interface. The intent of the "remove" file is not to turn off the enable status; it is to tell the kernel that _you_ are about to unplug the device and therefore the kernel should stop using it. In addition, the kernel should put the device into a state where the device thinks it can safely be unplugged (some devices turn on an LED to tell the user when it's okay to unplug them). There's no need for a complementary interface because the kernel automatically starts using a device after it is plugged in. Also, the "remove" file isn't guaranteed to turn off the enable status. This is a side effect, and it differs between USB-2 and USB-3. > b) the fact that the device can be powered off and the kernel learning > about this status change but still happily having the device in its > data structures. You can argue which condition keeps the "connect" > feature, but is there a valid use case for a device without the > "power" feature still being in the internal lists? How can it be > connected without power? Even a self-powered device is not supposed > to become active unless it sees VBus, right? The kernel doesn't specifically check the power status of a port; it looks at the connect and enable statuses. If they indicate the device is still attached and running, the kernel believes them. If a hub is buggy and provides inconsistent information (power off, connect or enable on), how can the kernel tell what to believe? > I guess even if we don't have 'c', 'a' and 'b' can still be adressed: > > * add a mechanism by which the "enable" feature can be set after it has > been removed e.g. by means of the "echo > remove". Not related to > power switching at all, merely a matter of having orthogonal > interfaces: If you can remove it, you can add it again. Non-removable > USB is pretty frequent these days, think of hub chips built onto > mainboards, or USB hub + card reader built into the display. you > cannot re-plug in one chip into the hub on the circuit board next to > it. Resetting the device attached to the port should accomplish what you want. A reset can be issued via an ioctl or libusb. > * as the USB spec states that the "connect" feature should be cleared > when "power" is cleared, and there apparently are hubs out there who > think it's not their job to do so: Should the hub.c kernel driver > work around that by either clearing it by itself, or by doing a > usb_remove_device() in that situation? The kernel driver cannot actually clear the connect status; the USB protocol offers no way of doing this. But we could check for power-off status and treat it as a disconnect. I'm not sure there's any good reason for adding this, however. You'd still face the same problem of how to tell the kernel that the device (or a different device!) is now attached to the port when the power is restored. 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
