On Thu, Nov 30, 2023 at 06:25:21PM +0100, Jose Ignacio Tornos Martinez wrote: > Hi Alan, > > Thank you again for you comments. > > > What are these unnecessary operations? > Sorry if I was not clear, I was referring to the reading and writing > operations that are commanded within stop and unbind driver functions. > This operations are necessary if we unbind to get the device stopped in > a known state but if the device is detached, they are failing and imho > they are not necessary. That is the reason why I was trying to detect > when the device is really disconnected, to allow sending commands only > if the device was still connected. > > > 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. > Ok, understood, very helpful clarification. > In any case, I was referring to the internal operations during stop and > unbind. And if any failed operations are commanded before and after > disconnection (if any), try to detect with the warning to be sure if there > is any problem. > > I have checked that other drivers are using USB_STATE_NOTATTACHED to check > and confirm the device disconnection. And I am trying to analyze other > drivers to check if this can be done in another way. > If I use -ENODEV as Oliver suggested, I think I wouldn't know if the device > is disconnected previous to any operation. But maybe this is the way. I see. Your approach isn't all that bad. Another possibility would be to have the unbind routine set a flag in the private data structure, and then make the ax88179_write_cmd() and ax88179_read_cmd() routines avoid printing error messages if the flag is set. Or don't bother with the flag, and simply make the routines skip printing an error message if a transfer fails with error code -ENODEV. Alan Stern
