Re: BUG: USB Reset-Resume Mechanism does not work for runtime resume

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Mar 06, 2014 at 10:10:48AM +0000, Poulain, Loic wrote:
> I agree, but because it's possible to have many different hardware for the same class driver, you can't predict if all of them will be not broken. So in this case, each USB class driver should have the reset-resume callback.

It is better like this, since .reset-resume is only called when the
normal resume has failed.

> A broken device can be a device which doesn't resume correctly 1 time per thousand (due to timing reason or anything else). Today, this single resume failure is enough to stuck the device (suspended forever).
> because mobile systems are more and more PM agressive, I think we could see this problem occurring more often.

Okay, so the question is we should use the heavy operation to rebind the
class driver at usb core or light operation to reset interface at class
driver? Yes, I agree with you, if the class driver does not supply
light operation like reset its internal fsm, then a heavy operation
like reload driver has to be used.

You can submit a patch to Alan, and see his comment.

> 
> Unbind/rebind is here as a fallback mechanism for drivers that don't know how to restore device after resume failure, and it works pretty well for system PM. For runtime PM, half of the work is done, interface is declared as needs_rebind but never rebind. So either the rebind work should be completed for PM runtime or an other solution found (logical disconnect, reset_resume mandatory...). But I think this dead end should be fixed.
> 

Yes, a patch is welcome.

BTW, using community email style to reply next time please.

Peter

> Regards,
> Loic Poulain
> ________________________________________
> From: Peter Chen [peter.chen@xxxxxxxxxxxxx]
> Sent: Thursday, March 06, 2014 2:10 AM
> To: Alan Stern
> Cc: Poulain, Loic; linux-usb@xxxxxxxxxxxxxxx
> Subject: Re: BUG: USB Reset-Resume Mechanism does not work for runtime resume
> 
> On Wed, Mar 05, 2014 at 11:26:06AM -0500, Alan Stern wrote:
> > On Wed, 5 Mar 2014, Poulain, Loic wrote:
> >
> > > + function 'do_rebind_interface' is in charge of unbind and rebind the interfaces with the 'need_binfind' flag set.
> > > + However this method is only called in 'usb_resume_complete'.
> > > + Problem is that 'usb_resume_complete' is a dev_pm_ops callback (core/usb.h) used by the System PM core which is never called in a runtime PM scenario.
> > > + So interfaces remain suspended forever (or until the next PM system suspend/resume), device is unusable.
> > > (unbinding/rebinding manually the interface via sysfs recovers the device)
> > >
> > > Could you please let me know if it's the expected behavior or a real issue. Should we not call 'do_rebind_interface' in the runtime resume sequence?
> >
> > I suspect this is an oversight.
> >
> > Still, implementing it would be difficult.  In usb_runtime_resume, the
> > device lock may or may not already be held.  Therefore we cannot simply
> > lock the device and call do_rebind_interfaces.
> >
> > Using a work queue for this seems like overkill (and it seems fragile).
> > I don't know what we should do.
> >
> 
> If the autosuspend supported device can't respond resume correctly, eg,
> after resume, it can't respond GET_STATUS correctly in this case, the
> .reset_resume interface is a must for class driver, it just like a
> workaround for broken hardware.
> 
> --
> 
> Best Regards,
> Peter Chen
> 
> ---------------------------------------------------------------------
> Intel Corporation SAS (French simplified joint stock company)
> Registered headquarters: "Les Montalets"- 2, rue de Paris, 
> 92196 Meudon Cedex, France
> Registration Number:  302 456 199 R.C.S. NANTERRE
> Capital: 4,572,000 Euros
> 
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
> 
> 
> 

-- 

Best Regards,
Peter Chen

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux