Doug Anderson <dianders@xxxxxxxxxxxx> > Sent: Tuesday, October 17, 2023 12:47 AM [... > > > static int generic_ocp_read(struct r8152 *tp, u16 index, u16 size, > > > @@ -8265,6 +8353,19 @@ static int rtl8152_pre_reset(struct > usb_interface > > > *intf) > > > if (!tp) > > > return 0; > > > > > > + /* We can only use the optimized reset if we made it to the end of > > > + * probe without any register access fails, which sets > > > + * `PROBED_WITH_NO_ERRORS` to true. If we didn't have that then return > > > + * an error here which tells the USB framework to fully unbind/rebind > > > + * our driver. > > > > Would you stay in a loop of unbind and rebind, > > if the control transfers in the probe() are not always successful? > > I just think about the worst case that at least one control always fails in probe(). > > We won't! :-) One of the first things that rtl8152_probe() does is to > call rtl8152_get_version(). That goes through to > rtl8152_get_version(). That function _doesn't_ queue up a reset if > there are communication problems, but it does do 3 retries of the > read. So if all 3 reads fail then we will permanently fail probe, > which I think is the correct thing to do. The probe() contains control transfers in 1. rtl8152_get_version() 2. tp->rtl_ops.init() If one of the 3 control transfers in 1) is successful AND any control transfer in 2) fails, you would queue a usb reset which would unbind/rebind the driver. Then, the loop starts. The loop would be broken, if and only if a) all control transfers in 1) fail, OR b) all control transfers in 2) succeed. That is, the loop would be broken when the fail rate of the control transfer is high or low enough. Otherwise, you would queue a usb reset again and again. For example, if the fail rate of the control transfer is 10% ~ 60%, I think you have high probability to keep the loop continually. Would it never happen? Best Regards, Hayes
