On Wed, 21 Jan 2015, Olivier Sobrie wrote:
I tested your patch. It also fixes the problem I observed.
You can drop mine.
For your info:
My test consists in powering down a usb hso modem while one of its
serial port is opened. It leads to two URB failures, each urb callback
queues a
Hello Alan,
On Tue, Jan 20, 2015 at 10:26:30AM -0500, Alan Stern wrote:
On Tue, 20 Jan 2015, Olivier Sobrie wrote:
When usb_queue_reset() is called it schedules a work in view of
resetting the usb interface. When the reset work is running, it
can be scheduled again (e.g. by the usb
When usb_queue_reset() is called it schedules a work in view of
resetting the usb interface. When the reset work is running, it
can be scheduled again (e.g. by the usb disconnect method of
the driver).
Consider that the reset work is queued again while the reset work
is running and that this work
On Tue, 2015-01-20 at 13:29 +0100, Olivier Sobrie wrote:
When usb_queue_reset() is called it schedules a work in view of
resetting the usb interface. When the reset work is running, it
can be scheduled again (e.g. by the usb disconnect method of
the driver).
Consider that the reset work is
Hi Oliver,
On Tue, Jan 20, 2015 at 02:48:37PM +0100, Oliver Neukum wrote:
On Tue, 2015-01-20 at 13:29 +0100, Olivier Sobrie wrote:
When usb_queue_reset() is called it schedules a work in view of
resetting the usb interface. When the reset work is running, it
can be scheduled again (e.g. by
On Tue, 20 Jan 2015, Olivier Sobrie wrote:
When usb_queue_reset() is called it schedules a work in view of
resetting the usb interface. When the reset work is running, it
can be scheduled again (e.g. by the usb disconnect method of
the driver).
Consider that the reset work is queued again
On Tue, Jan 20, 2015 at 10:26:30AM -0500, Alan Stern wrote:
On Tue, 20 Jan 2015, Olivier Sobrie wrote:
When usb_queue_reset() is called it schedules a work in view of
resetting the usb interface. When the reset work is running, it
can be scheduled again (e.g. by the usb disconnect method
