netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
To: stern@rowland.harvard.edu
Cc: davem@davemloft.net, edumazet@google.com, jtornosm@redhat.com,
	kuba@kernel.org, linux-kernel@vger.kernel.org,
	linux-usb@vger.kernel.org, netdev@vger.kernel.org,
	oneukum@suse.com, pabeni@redhat.com
Subject: Re: [PATCH] net: usb: ax88179_178a: avoid failed operations when device is disconnected
Date: Thu, 30 Nov 2023 18:25:21 +0100	[thread overview]
Message-ID: <20231130172525.193069-1-jtornosm@redhat.com> (raw)
In-Reply-To: <e2faf901-84de-41ad-804d-6c86bc304ef1@rowland.harvard.edu>

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.

Best regards
José Ignacio


  reply	other threads:[~2023-11-30 17:25 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-29 15:16 [PATCH] net: usb: ax88179_178a: avoid failed operations when device is disconnected Jose Ignacio Tornos Martinez
2023-11-29 15:33 ` Oliver Neukum
2023-11-29 15:40   ` Alan Stern
2023-11-30  8:41     ` Jose Ignacio Tornos Martinez
2023-11-30 15:50       ` Alan Stern
2023-11-30 17:25         ` Jose Ignacio Tornos Martinez [this message]
2023-11-30 18:13           ` Alan Stern
2023-12-01 10:46             ` Jose Ignacio Tornos Martinez
2023-12-01 11:51             ` [PATCH v2] " Jose Ignacio Tornos Martinez
2023-12-01 12:25               ` Greg KH
2023-12-01 13:26                 ` [PATCH v3] " Jose Ignacio Tornos Martinez
2023-12-01 16:13                   ` Alan Stern
2023-12-01 17:27                     ` Jose Ignacio Tornos Martinez
2023-12-01 20:14                   ` Oliver Neukum
2023-12-04 11:31                     ` Jose Ignacio Tornos Martinez
2023-12-05 13:51                     ` [PATCH v4] " Jose Ignacio Tornos Martinez
2023-12-05 18:07                       ` Alan Stern
2023-12-06 12:17                         ` Jose Ignacio Tornos Martinez
2023-12-07 11:42                         ` [PATCH v5] " Jose Ignacio Tornos Martinez
2023-12-07 16:41                           ` Alan Stern
2023-12-07 17:50                             ` [PATCH v6] " Jose Ignacio Tornos Martinez
2023-12-07 20:23                               ` Alan Stern
2023-12-07 20:32                                 ` Jakub Kicinski
2023-12-08  4:56                                   ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20231130172525.193069-1-jtornosm@redhat.com \
    --to=jtornosm@redhat.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=oneukum@suse.com \
    --cc=pabeni@redhat.com \
    --cc=stern@rowland.harvard.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).