Re: [RESEND][PATCH] Bluetooth: Make request workqueue freezable

Hi Alan,

quoted

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