Re: [PATCH] net: usb: ax88179_178a: avoid failed operations when device is disconnected

[Alan Stern]

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