On Tue, May 23, 2017 at 11:40:58PM +0200, Harald Welte wrote: > Dear Linux Kernel USB hackers, > > I'm facing the following overall problem / use case: > > * there is an embedded device, attached to USB, with complex internal > software, which every so often needs to be physically power cycled in > order to reset all of its internal state. In the particular case it's > a cellular modem, but that doesn't really matter here > > * in order to perform the power cycle, I use a (custom built) USB hub > of which I'm sure that disabling the POWER feature of the hub port > actually will control the downstream VBUS supply to the device > > * In absence of any sysfs control or other API exposed to userland, I'm > using uhubctl (https://github.com/mvp/uhubctl) to directly clear the > POWER feature on said downstream USB port of the hub. > > * The Linux kernel USB stack (tested up to 4.11) does notice this state > change (I can see it doing GET_STATUS as a follow-up), but the USB > device still stays in the USB tree, i.e. it shows up in lsusb despite > being powered off. This also means that all associated devices like > cdc_acm, cdc_ether etc. still remain seen by applications, despite the > device being gone Can you provide the kernel logs for when you do this? The hub should recognise that the device is gone, and disconnect everything. Are you sure the hub is handling this correctly? > * Only when the device is turned on again via SET_FEATURE POWER, the > USB device logical structure is remove from the kernel USB stack, and > it subsequently re-enumerates. That's "odd" :) > I know that bypassin the kernel USB hub driver is probably not the > cleanest approach, but in absence of any API/sysfs to do so (forgive me > if I simply didn't find it), we have to resort to issuing CONTROL > requests to the USB hub directly. > > As a work-around, I have found that issuing something like > "echo 1 > /sys/bus/usb/devices/1-4.1/remove" > will clear the ENABLE feature on the port and at the same time the > kernel code will call usb_remove_device() and hence it disappears from > lsusb as well as any associated device nodes re removed. > > Hoewver, in this case I have not found any designated way to re-attach > the device. Given that we're talking about embedded devices in > industrial applications installed at remote locations, and about a mPCIe > physical form factor, re-plugging the device simply won't be an option. > > I'm wondering that after decades of a production-grade Linux USB stack, > why is there no standard method to re-enable such a port. Once again, > if I'm missing it, please let me know. That's because there is no way to reliably do this on USB hubs, there is no required support for this in the spec, so people did not implement it in their hubs. > Given that power cycling was the actual requirement at hand: With ENABLE > cleared via sysfs "remove", the POWER feature is still set and hence > power is still applied to the downstream usb port at this point. But > then, as indicated above, I can use uhubctl to remove the power and > re-enable the power, which will make the device re-enumerate. > > But this weird combination between sysfs on the one hand side and > directly issuing USB hub control requests via uhubctl on the other side > really looks ugly. Is this really how one is supposed to power-cycle a > USB device? It doesn't seam like such a completely odd requirement, > does it? It's not an odd requirement, just one that is not implemented at all in the standard, nor in most hardware. Your hub _should_ be reporting that the port is now gone, but it doesn't sound like it is, which is probably the issue here. If you try a different hub, does that work properly? We can't know if a hub handles this "feature" by probing it, so we can't expose it in the kernel through sysfs or anywhere else, as it would be just as effective as the userspace tool you are using (i.e. sometimes it works, sometimes it doesn't.) That is why it's a userspace tool. sorry, USB sucks :) greg k-h -- 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
