Re: [PATCHv4] usbnet: Resubmit interrupt URB once if halted

On Thu, Apr 21, 2011 at 6:43 AM, Alan Stern [off-list ref] wrote:

On Wed, 20 Apr 2011, Paul Stewart wrote:

quoted

On Wed, Apr 20, 2011 at 2:08 PM, Alan Stern [off-list ref] wrote:

quoted

On Tue, 19 Apr 2011, Paul Stewart wrote:

quoted

Set a flag if the interrupt URB completes with ENOENT as this
occurs legitimately during system suspend. �When the usbnet_bh
is called after resume, test this flag and try once to resubmit
the interrupt URB.

No doubt there's a good reason for doing things this way, but it isn't
clear. �Why wait until usbnet_bh() is called after resume? �Why not
resubmit the interrupt URB _during_ usbnet_resume()?

Actually, I was doing this in the bh because of feedback I had gained
early in this process about not doing submit_urb in the resume().

Do you have a URL for that feedback?  In general, there's no reason not
to resubmit URBs during a resume callback; lots of drivers do it.  But
usbnet may have some special requirements of its own that I'm not aware
of.

quoted

 If
that issue doesn't exist, that makes my work a lot easier.  In testing
I found that just setting this to happen in the bh might be problematic
due to firing too early, so this is good news.

quoted

�This would seem
to be the logical approach, seeing as how usbnet_suspend() kills the
interrupt URB.

Aha!  But you'll see from the current version of my patch that we don't
actually ever kill the interrupt URB.  It gets killed all on its own (by the
hcd?) and handed back to us in intr_complete().  This last bit about the
complete function being called was lost on me for a while which is why
in a previous iteration of the patch I was trying to kill the urb in suspend().

Why not kill the interrupt URB while suspending?  It's the proper thing
to do.  Otherwise you run the risk that an event might happen at just
the wrong time, causing the interrupt URB to complete normally, but
_after_ the driver has finished suspending.  There's a good chance the
driver would not process the event correctly.

I don't mind killing the URB. I'd want to set the halt flag as well
(more on why have a flag in response to your other email).  You're
right that there may be a race between an interrupt URB arriving and
the onset of suspend, but I really can't imagine why I can't solve
that by setting the flag if a submit_urb() fails in intr_complete().

Alan Stern

--
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