Hi, On Fri, Oct 20, 2023 at 8:46 AM Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > On Fri, Oct 20, 2023 at 08:31:38AM -0700, Douglas Anderson wrote: > > When we call usb_reset_device() and a driver doesn't implement > > pre_reset() and post_reset() methods then the USB core will attempt to > > unbind and rebind the driver in order to make reset work. This is a > > great general solution, but it has the potential to loop forever. > > Specifically, if the USB device is in a state that the USB device > > driver issues another usb_reset_device() after each rebind then we'll > > just continually unbind and rebind with no end. > > > > It's difficult to address this condition in a USB device driver > > because it's hard for the driver to keep state across each > > unbind/bind. > > How about just adding appropriate pre_reset() and post_reset() methods? > This is precisely what they are meant for. Then the the unbind/rebind > loop wouldn't ever get started. Right, and we have pre_reset() and post_reset() in the r1852 driver. The issue is that we are seeing occasional control transfer errors while the r8152 driver is still running its probe() routine and we want to reset in response to those. It is relatively difficult to have the pre_reset() and post_reset() methods work properly if failures happen and probe() hasn't finished yet. The current proposal I have for the r8152 driver is to have the pre_reset() routine return -EIO if we saw errors during probe, which tells the USB core to unbind/rebind us. This gets us to a known good state. If we need to do a reset later on (after probe finished successfully) then pre_reset() and post_reset() can avoid the unbind/bind. The worry was that this could cause an infinite loop. Hence this patch. ;-) -Doug
