Comment 10 for bug 1827452

Hi latest on this. I've played with about 50 custom kernel patches here and I can see exactly what happens. When uvcvideo looks for webcam devices it finds a perfectly healthy idle webcam on the USB hub (even built-in hub). Then when it starts a stream the webcam obviously requires more power. I've seen this with multiple webcam vendors and a cheap USB extension cable.

The device initializes and then disconnects when it sometimes decides it needs more power. It disconnects via interrupt even though the comments in hub.c:usb_disconnect say "This call is synchronous, and may not be used in an interrupt context." Disconnect usually occurs during uvc_parse_vendor_control, setting all interfaces in the device to NULL just as usb_ifnum_to_if expects it to NOT be NULL implicitly. In the end an active USB HUB or better cable should fix this but IoT field devices and small Raspberry Pi SBCs often don't have that luxury.

I've submitted two options to the kernel maintainers to fix this. One was rejected and one was ignored.

1) usb.c:usb_ifnum_to_if checking NULL before dereferencing interfaces, which would fix this at the usbcore level (which is where the interrupt actually is anyway). This was rejected saying it should be fixed in the driver.

2) uvc_driver.c:uvc_parse_standard_control sleep a few ms (10 or so) to give a device time to decide if it wants to disconnect before proceeding in usb_ifnum_to_if. A device lock would be ideal but I'm still not sure what the best locking strategy would be or if this is the only place it would be required. This inquiry to the uvcvideo maintainers was ignored.

Sorry folks I can't seem to get much traction. A simple patch to usb.c preserves usbcore to avoid wiping out the whole usb subsystem during an error but that's not the ideal fix. I'm guessing the kernel maintainers have heard piles of these issues already and can't/don't care for a universal fix.