Re: [PATCH] usb: core: don't try to reset_device() a port that got just disconnected

2013-07-31 Thread Julius Werner
> An odd sort of bug. You'd think that not getting a response back would > be one of the first types of error the hardware designers would check > for. You'd think that, right? But apparently they didn't. I've now also tried just hacking a pointless SET_INTERFACE message into the

Re: [PATCH] usb: core: don't try to reset_device() a port that got just disconnected

2013-07-31 Thread Sarah Sharp
On Tue, Jul 30, 2013 at 07:33:46PM -0700, Julius Werner wrote: > > Wait a moment. Why does each of these attempts lead to a 5-second > > timeout? Why don't they fail immediately? > > Now that you mention it, that's a very good question. The kernel > enqueues a control transfer to the now

Re: [PATCH] usb: core: don't try to reset_device() a port that got just disconnected

2013-07-31 Thread Alan Stern
On Tue, 30 Jul 2013, Julius Werner wrote: > > Wait a moment. Why does each of these attempts lead to a 5-second > > timeout? Why don't they fail immediately? > > Now that you mention it, that's a very good question. I have brought this up with Sarah on more than one occasion, but we never

Re: [PATCH] usb: core: don't try to reset_device() a port that got just disconnected

2013-07-31 Thread Alan Stern
On Tue, 30 Jul 2013, Julius Werner wrote: Wait a moment. Why does each of these attempts lead to a 5-second timeout? Why don't they fail immediately? Now that you mention it, that's a very good question. I have brought this up with Sarah on more than one occasion, but we never found a

Re: [PATCH] usb: core: don't try to reset_device() a port that got just disconnected

2013-07-31 Thread Sarah Sharp
On Tue, Jul 30, 2013 at 07:33:46PM -0700, Julius Werner wrote: Wait a moment. Why does each of these attempts lead to a 5-second timeout? Why don't they fail immediately? Now that you mention it, that's a very good question. The kernel enqueues a control transfer to the now disconnected

Re: [PATCH] usb: core: don't try to reset_device() a port that got just disconnected

2013-07-31 Thread Julius Werner
An odd sort of bug. You'd think that not getting a response back would be one of the first types of error the hardware designers would check for. You'd think that, right? But apparently they didn't. I've now also tried just hacking a pointless SET_INTERFACE message into the

Re: [PATCH] usb: core: don't try to reset_device() a port that got just disconnected

2013-07-30 Thread Julius Werner
> Wait a moment. Why does each of these attempts lead to a 5-second > timeout? Why don't they fail immediately? Now that you mention it, that's a very good question. The kernel enqueues a control transfer to the now disconnected address because it's internal bookkeeping is not yet updated, but

Re: [PATCH] usb: core: don't try to reset_device() a port that got just disconnected

2013-07-30 Thread Alan Stern
On Tue, 30 Jul 2013, Julius Werner wrote: > The USB hub driver's event handler contains a check to catch SuperSpeed > devices that transitioned into the SS.Inactive state and tries to fix > them with a reset. It decides whether to do a plain hub port reset or > call the usb_reset_device() method

Re: [PATCH] usb: core: don't try to reset_device() a port that got just disconnected

2013-07-30 Thread Julius Werner
-andiry.xu... he wrote that section originally but it seems that his address is no longer available. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

[PATCH] usb: core: don't try to reset_device() a port that got just disconnected

2013-07-30 Thread Julius Werner
The USB hub driver's event handler contains a check to catch SuperSpeed devices that transitioned into the SS.Inactive state and tries to fix them with a reset. It decides whether to do a plain hub port reset or call the usb_reset_device() method based on whether there was a device attached to the

[PATCH] usb: core: don't try to reset_device() a port that got just disconnected

2013-07-30 Thread Julius Werner
The USB hub driver's event handler contains a check to catch SuperSpeed devices that transitioned into the SS.Inactive state and tries to fix them with a reset. It decides whether to do a plain hub port reset or call the usb_reset_device() method based on whether there was a device attached to the

Re: [PATCH] usb: core: don't try to reset_device() a port that got just disconnected

2013-07-30 Thread Julius Werner
-andiry.xu... he wrote that section originally but it seems that his address is no longer available. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: core: don't try to reset_device() a port that got just disconnected

2013-07-30 Thread Alan Stern
On Tue, 30 Jul 2013, Julius Werner wrote: The USB hub driver's event handler contains a check to catch SuperSpeed devices that transitioned into the SS.Inactive state and tries to fix them with a reset. It decides whether to do a plain hub port reset or call the usb_reset_device() method

Re: [PATCH] usb: core: don't try to reset_device() a port that got just disconnected

2013-07-30 Thread Julius Werner
Wait a moment. Why does each of these attempts lead to a 5-second timeout? Why don't they fail immediately? Now that you mention it, that's a very good question. The kernel enqueues a control transfer to the now disconnected address because it's internal bookkeeping is not yet updated, but I