I have seen a discussion about unlinking URBs before suspending the
bus posted at
http://marc.info/?l=linux-usb&m=126296327514946&w=2
I think I have a few more questions about this and would like to seek
for your opinion.
1. Is it really necessary to unlink pending URBs in driver's suspend
method? My observation is that once usb_autopm_put_interface is
called, the pending URB will eventually be cleaned up in function
usb_hcd_flush_endpoint.
usb_autopm_put_interface -> usb_autopm_do_interface ->
usb_suspend_both ->usb_hcd_flush_endpoint
2. When the host decides to suspend the bus, in case there is a
pending IN URB, the driver doesn't really know if the IN URB is in the
middle of DATA transfer stage or the peripheral is NAK'ing the IN
token, the SUSPEND can potentially interrupt an ongoing transfer.
According to the EHCI spec, the hardware guarantees the current
transaction (512 bytes packet for high speed) to be finished before
the SUSPEND taking effect, this would result in an interrupted
transfer with the first half being an integer multiple of 512 bytes
and the second half being finished only after bus RESUME. I have
implement some code in my driver to put these two part together to
recover the interrupted transfer. However, if I do usb_kill_urb in the
suspend method of the driver, sometimes the URB would be given back
with actual_length equals to a number that is not integer multiple of
512 (such as 33 or 66), this broke the mechanism I implemented to
re-assemble the interrupted transfer. I don't know if that
actual_length is really the bytes received (it doesn't look like there
is expected data in the buffer) and how should I handle this kind of
returning URB. Do you know how such a urb->actual_length could happen?
Is it an artifact of usb_kill_urb?
Thanks,
Fei
--
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
