On Fri, 23 Feb 2007, Duncan Sands wrote:
> 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.
No, there
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
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
Hi Pete,
On Friday 23 February 2007 00:53:18 Pete Zaitcev wrote:
> On Thu, 22 Feb 2007 11:43:38 +0100, Duncan Sands <[EMAIL PROTECTED]> wrote:
> > > + /* the module/device has probably been removed */
> > > + if (urb->status == -ESHUTDOWN)
> > > + return;
> > > +
>
Hi Pete,
On Friday 23 February 2007 00:53:18 Pete Zaitcev wrote:
On Thu, 22 Feb 2007 11:43:38 +0100, Duncan Sands [EMAIL PROTECTED] wrote:
+ /* the module/device has probably been removed */
+ if (urb-status == -ESHUTDOWN)
+ return;
+
if
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
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
On Fri, 23 Feb 2007, Duncan Sands wrote:
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.
No, there isn't.
On Thu, 22 Feb 2007 11:43:38 +0100, Duncan Sands <[EMAIL PROTECTED]> wrote:
> > + /* the module/device has probably been removed */
> > + if (urb->status == -ESHUTDOWN)
> > + return;
> > +
> > if (printk_ratelimit())
> >
> + /* the module/device has probably been removed */
> + if (urb->status == -ESHUTDOWN)
> + return;
> +
> if (printk_ratelimit())
> atm_warn(channel->usbatm, "%s: urb 0x%p failed (%d)!\n",
>
+ /* the module/device has probably been removed */
+ if (urb-status == -ESHUTDOWN)
+ return;
+
if (printk_ratelimit())
atm_warn(channel-usbatm, %s: urb 0x%p failed (%d)!\n,
On Thu, 22 Feb 2007 11:43:38 +0100, Duncan Sands [EMAIL PROTECTED] wrote:
+ /* the module/device has probably been removed */
+ if (urb-status == -ESHUTDOWN)
+ return;
+
if (printk_ratelimit())
Detect usb device shutdown and ignore failed urbs. This happens when the driver
is unloaded or the device is unplugged.
Signed-off-by: Simon Arlott <[EMAIL PROTECTED]>
---
drivers/usb/atm/usbatm.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git
Detect usb device shutdown and ignore failed urbs. This happens when the driver
is unloaded or the device is unplugged.
Signed-off-by: Simon Arlott [EMAIL PROTECTED]
---
drivers/usb/atm/usbatm.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/atm/usbatm.c
14 matches
Mail list logo
