[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CACVXFVOJzctAs-giOmC-0J5LfLsp1YSwrcRK4UEyPAejFc05rg@mail.gmail.com>
Date: Wed, 20 Jun 2012 18:56:23 +0800
From: Ming Lei <tom.leiming@...il.com>
To: Oliver Neukum <oneukum@...e.de>
Cc: Huajun Li <huajun.li.lee@...il.com>,
David Miller <davem@...emloft.net>, stern@...land.harvard.edu,
linux-usb@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH] usbnet: Activate halt interrupt endpoint before re-submit URB
On Wed, Jun 20, 2012 at 6:21 PM, Oliver Neukum <oneukum@...e.de> wrote:
> It probably was halted and cleared. However that you cleared
> a halt doesn't mean that the reason for stalling went away.
> So you must cope with an endpoint being halted again right after
> it was cleared.
I only suggested we should handle -EPIPE for usb_submit_urb
on interrupt endpoint, maybe it is the 1st handling, at least it is
per USB spec.
Also from implementation of usb gadget device, generally
ClearFeature(HALT) is to clear the some halt related flag of
endpoint hardware.
Looks the reasons of interrupt endpoint stalling is invisible
for usbnet driver, so it is not easy to handle the situation
you described(halted and cleared repeatedly).
>
>> > In that case we'd need to do something more intrusive
>> > like resetting the device, but that cannot be done well
>> > in the generic usbnet part.
>>
>> IMO, resetting is not needed for -EPIPE, but may be needed for
>> -EPROTO failure.
>
> We don't need it for a single failure, but what else would we do
> if we keep getting -EPIPE?
Suppose the case will happen, what is the appropriate actions
usbnet should take on the failure? I am not sure RESET can deal
with it.
Also is it a actual failure case or only a theory case?
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists