On Thu, Nov 30, 2023 at 09:41:36AM +0100, Jose Ignacio Tornos Martinez wrote: > Hi Oliver, > > > I am sorry, but this is a layering violation. You are looking > > at an internal state of the USB layer to surpress logging > > -ENODEV. If you think these messages should go away, filter > > for ENODEV where they are generated. > Thank you for your comments and suggestion. > My intention was also to avoid unnecessary and failed operations > if disconnection was detected. What are these unnecessary operations? > Ok, let me research more and do better. > > Hi Alan, > > > In addition, you should be more careful about the distinction between > > "unbound" and "disconnected". It's possible for the driver to be > > unbound from the device even while the device is still plugged in. In > > this situation, submitting URBs will fail with an error even though the > > device state isn't USB_STATE_NOTATTACHED. > Thank you for you comments. > I also tested "unbound" and stop and unbind operations were correctly > executed. I just wanted to avoid the issues during disconnection, if other > operations are commanded later I think it is better to warn. In general, drivers should treat "unbind" the same as "disconnect" (in both cases, the ->disconnect() routine is called). If a driver tries to send commands to the device while the disconnect routine is running, it should expect that they might fail and not generate an error message if they do. (Also, note that the USB core will allow a driver to send commands to the device during unbind only if the .soft_unbind flag is set in the usb_driver structure.) And in any case, a driver should _never_ try to communicate with the device after the disconnect routine has returned. Alan Stern
