ed by the normal slew of "new device found" messages.
>
> Git bisect points to this commit:
> f7965c0846d74b270e246c1470ca955d5078eb07
Here's another regression report pointing to that same commit:
http://lkml.org/lkml/2013/1/28/546
"external HDD in USB3 enclosure c
ed by int_in_work() this might cause
int_in_work() to run after the post_reset method, with urb_int_in
already resubmitted, so handle that case gracefully.
Signed-off-by: Tilman Schmidt
---
drivers/isdn/gigaset/bas-gigaset.c | 19 ---
1 files changed, 16 insertions(+), 3 deletions(-)
Am 13.10.2012 05:01, schrieb Ming Lei:
> On Sat, Oct 13, 2012 at 6:11 AM, Tilman Schmidt wrote:
>>
>> There are two cases I have to worry about:
>> (1) a reset triggered by int_in_work()
>> (2) a reset triggered by some other source external to the driver
>>
>&
Am 12.10.2012 16:17, schrieb Ming Lei:
> On Fri, Oct 12, 2012 at 5:26 PM, Tilman Schmidt wrote:
>
>> At first sight, I can simply omit the cancel_work_sync() in
>> the pre_reset() case. In the worst case, the uncancelled
>> int_in_work() will call usb_clear_halt(), try to
he worst case, the uncancelled
int_in_work() will call usb_clear_halt(), try to resubmit the
already submitted URB, fail, and trigger another reset
needlessly. Doesn't sound too bad?
The alternative would be to introduce a new flag in the device
state to skip the cancel_work_sync() ca
and not just "usb-serial:" instead ?
Easier coding - or rather, avoiding the work of re-coding. The info()
macro
is there, it works, why change it?
> can this probable be optimized (as most drivers only print "drivername:"
> anyway) ?
See the redefinition of these
