Re: How to safe recover USB driver from broken hardware situation

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

 



On Tue, 23 Apr 2013, Peter Chen wrote:

> On Mon, Apr 22, 2013 at 11:26:05AM -0400, Alan Stern wrote:
> > On Mon, 22 Apr 2013, Peter Chen wrote:
> > 
> > > Hi all,
> > > 
> > > Recently, I have several customers troubled in safe recover USB
> > > function during the ESD situation (or some other situations, like
> > > short dp/dm, ground dp/dm, etc).
> > > 
> > > I designed the ESD detect and recovery process, but I met some
> > > sync problems between host controller driver (eg, ehci) and class
> > > driver (eg, mass storage). For example, when khubd tries to disconnect
> > > usb device, it will try to stop thread usb-storage, but usb-storage
> > > is waiting some transfers to finish, qTD and QH operation may be 
> > > finished (usb_submit_urb does not return error), but no watchdog timer
> > > and completion interrupt are occurred.
> > > 
> > > I have:
> > > esd_detect_process and esd_recovery_process at host controller driver.
> > > At esd_detect_porcess
> > > It will disable usb interrupt and judge ASE and PSE, etc.
> > > At esd_recovery_process:
> > > It needs to reset controller (usbcmd.rst, and toggle portsc.pp bit, etc)
> > > 
> > > I would like to have some synchronization mechanism between usb_submit_urb
> > > or (ehci_urb_enqueue) and my esd_detect_process and esd_recovery_process.
> > > But still not find a safe one, eg, I still met khubd's status changes 
> > > "D" problem described above. Any suggestions are appreciated, Thanks.
> > 
> > Your recovery process should not need to make all these changes to
> > ehci-hcd.  Simply carry out the same actions as the "dead:" statement
> > label in ehci_irq() -- that is, do the same thing as if an interrupt
> > occurred with the STS_FATAL bit set.  That code is all properly 
> > synchronized.
> 
> Sometimes, there are no STS_FATAL and STA_ERR when ESD occurs.
> So, you suggest do the same thing for STS_FATAL at my esd_recovery_process?

Yes.

> > Then unbind the driver from the controller and rebind it.  Rebinding
> > will reset the controller.
> > 
> 
> You mean unbind the controller driver?  Any existed API can be called?
> I can't do rmmod at that time.

You can call device_release_driver, after locking both the controller's 
parent and the controller itself.  See driver_unbind() in 
drivers/base/bus.c.

Or, if you are doing this in userspace, you can write the controllers 
device name to /sys/bus/.../drivers/.../unbind.

Alan Stern

--
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