On Wed, Mar 6, 2013 at 10:51 AM, Ming Lei [off-list ref] wrote:

On Wed, Mar 6, 2013 at 12:08 AM, Bjørn Mork [off-list ref] wrote:

quoted

Ming Lei [off-list ref] writes:

I am starting to wonder why the USB core has combined system suspend and
runtime suspend if we are going to end up with every driver testing
PMSG_IS_AUTO(message) and selecting a completely different code path.

You are right that we will end up with problems if usbnet_resume is
called for a device usbnet hasn't suspended.  But I'd still claim that
is a bug in the USB core, which is the one that decided to ignore the
suspend error and still call resume.

I guess proper error handling here require the USB core to see the
interface driver as dead if it fails to suspend on system suspend, and
do forced rebinding on resume.

The idea should be fine, but may cause regression of user space, suppose
one device with suspend failure can be across suspend-resume cycle and
work well before, but it is no longer with your forced rebinding.

Give the potential cost(user space regression) of doing rebind, I think it
is better to try to recover the device in resume() first, then
consider rebinding
as the last straw.  In fact, I am also wondering if resume() can't recover one
device but probe() can, maybe we can always let resume() recover the
device which experienced suspend failure.

I remember that some guys went against rebinding during system sleep before
in the firmware loading discussion.

Thanks,
--
Ming Lei