Messages in this thread | | | Subject | Re: [RESEND][PATCH] Bluetooth: Make request workqueue freezable | From | Marcel Holtmann <> | Date | Thu, 21 May 2015 16:39:16 +0200 |
| |
Hi Alan,
>> Then avoiding the failed firmware is no solution, indeed. >> If it's a new probe, it should be never executed during resume. > > Can you expand this comment? What's wrong with probing during resume? > > The USB stack does carry out probes during resume under certain > circumstances. A driver lacking a reset_resume callback is one of > those circumstances.
in case the platform kills the power to the USB lines, we can never do anything about this. I do not want to hack around this in the driver.
What are the cases where we should implement reset_resume and would it really help here. Since the btusb.ko driver implements suspend/resume support, would reset_resume ever be called?
However I get the feeling someone needs to go back and see if the device is the same one and just gets probed again or if it is a new one from the USB host stack perspective.
Regards
Marcel
| |