[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200702231805.44397.duncan.sands@math.u-psud.fr>
Date: Fri, 23 Feb 2007 18:05:44 +0100
From: Duncan Sands <duncan.sands@...h.u-psud.fr>
To: Alan Stern <stern@...land.harvard.edu>
Cc: Pete Zaitcev <zaitcev@...hat.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-usb-devel@...ts.sourceforge.net,
Simon Arlott <254ad70138dc1cdf241hjzcr0007jhhw@...nder.lp0.eu>
Subject: Re: [linux-usb-devel] [PATCH 2/2] usbatm: Detect usb device shutdown and ignore failed urbs.
On Friday 23 February 2007 17:16:24 Alan Stern wrote:
> On Fri, 23 Feb 2007, Duncan Sands wrote:
>
> > if you get ESHUTDOWN, does that mean that you are about to be disconnected,
> > i.e. the disconnect method is about to be called? Or is it possible for the
> > device to just sit there disabled, but not disconnected?
>
> It is possible to receive ESHUTDOWN without being disconnected. For
> instance, a race with suspend could cause it to happen (although if your
> driver is written correctly that race should never occur). Another more
> likely scenario is that you have an active URB while calling
> usb_set_interface(); the endpoints for the old altsetting get disabled and
> the URB returns with an ESHUTDOWN error.
Thanks Alan. The original question was: if an urb fails with an error,
is there any point in resubmitting it after a delay (which is what the
driver usually does) if the error was -ESHUTDOWN? It sounds like there
is no point to it. And if the device is not disconnected, then it could
even be harmful since the urb will be resubmitted endlessly... While on
the topic, are there any other error codes for which an urb should not be
resubmitted?
Thanks again,
Duncan.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists