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

2013-04-23 Thread Alan Stern
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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


How to safe recover USB driver from broken hardware situation

2013-04-22 Thread Peter Chen
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.

-- 

Best Regards,
Peter Chen

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


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

2013-04-22 Thread Alan Stern
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.

Then unbind the driver from the controller and rebind it.  Rebinding
will reset the controller.

Alan Stern

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


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

2013-04-22 Thread Peter Chen
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?

 
 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.

Thanks.

-- 

Best Regards,
Peter Chen

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