On Wed, Jun 20, 2012 at 4:58 PM, Oliver Neukum [off-list ref] wrote:
Am Mittwoch, 20. Juni 2012, 10:07:55 schrieb Ming Lei:
quoted
BTW, maybe it is better to add below
usbnet_defer_kevent(dev, EVENT_STS_HALT);
for -EPIPE returned from usb_urb_submit if it will be resent.
Why? If it failed once it'll probably also fail the next time.
-EPIPE just means the endpoint is halted, either from usb_urb_submit
or urb->status, so the HALT should be cleared in the situation.
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.
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Am Mittwoch, 20. Juni 2012, 12:15:25 schrieb Ming Lei:
On Wed, Jun 20, 2012 at 4:58 PM, Oliver Neukum [off-list ref] wrote:
quoted
Am Mittwoch, 20. Juni 2012, 10:07:55 schrieb Ming Lei:
quoted
BTW, maybe it is better to add below
usbnet_defer_kevent(dev, EVENT_STS_HALT);
for -EPIPE returned from usb_urb_submit if it will be resent.
Why? If it failed once it'll probably also fail the next time.
-EPIPE just means the endpoint is halted, either from usb_urb_submit
or urb->status, so the HALT should be cleared in the situation.
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.
quoted
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?
Regards
Oliver
On Wed, Jun 20, 2012 at 6:21 PM, Oliver Neukum [off-list ref] 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).
quoted
quoted
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