none
Question regarding WDK 8.1 \ samples \ usbsamp \ queue.c \ ResetPipe() RRS feed

  • Question

  • I am studying “usbsamp” driver and I am confused with the bulk pipe error handling logic. The completion routine queues up a work item when it detects an error. The work item invokes the function ResetPipe() which in turn, invokes WdfUsbTargetPipeResetSynchronously().I’m having three issues :

    1) Regarding “WdfUsbTargetPipeResetSynchronously(), The spec reads “The driver must call WdfIoTargetStop () before it calls WdfUsbTargetPipeResetSynchronously. After WdfUsbTargetPipeResetSynchronously returns, the driver can call WdfIoTargetStart().”

    Why isn’t ResetPipe() invoking WdfIoTargetStop ()/WdfIoTargetStart() rbefore/after the call to WdfUsbTargetPipeResetSynchronously() ?

    2) Regarding “WdfUsbTargetPipeResetSynchronously(), The spec reads “The driver must not send additional I/O requests to the I/O target until WdfUsbTargetPipeResetSynchronously() returns.”.

    The work item may run in parallel with any READ/WRITE commands issued from an application in user mode.Don’t we have a race condition if an application performs a READ/WRITE request  (which enqueues an bulk IN/OUT request to the target)  after a failed READ/WRITE (which enqueues a work item to reset the pipe)? This would cause I/O requests to be sent while WdfUsbTargetPipeResetSynchronously() is in progress.

    3) Is it ok to call WdfUsbTargetPipeResetSynchronously() in parallel  ? following up on question (2) above; one application may invoke IOCTL IOCTL_USBSAMP_RESET_PIPE while the work item is in progress.


    • Edited by Frederick59 Friday, November 7, 2014 11:39 PM
    Friday, November 7, 2014 10:53 PM

Answers

  • 1) I agree that the sample should call WdfIoTargetStop  and WdfIoTargetStart. It would be much cleaner.

    2) Yes, stopping the IO target would prevent it. As it stands, the IO that happens in parallel can fail or succeed depending on when it hits the USB stack.

    3) It is definitely recommended for a client driver to only initiate one error recovery at a time. However, in this particular case, USB stack will deal with it and will not cause anything bad to happen (assuming IO is not being done in parallel). 

    Tuesday, November 11, 2014 7:33 AM

All replies

  • 1) I agree that the sample should call WdfIoTargetStop  and WdfIoTargetStart. It would be much cleaner.

    2) Yes, stopping the IO target would prevent it. As it stands, the IO that happens in parallel can fail or succeed depending on when it hits the USB stack.

    3) It is definitely recommended for a client driver to only initiate one error recovery at a time. However, in this particular case, USB stack will deal with it and will not cause anything bad to happen (assuming IO is not being done in parallel). 

    Tuesday, November 11, 2014 7:33 AM
  • 1) I agree that the sample should call WdfIoTargetStop  and WdfIoTargetStart. It would be much cleaner.

    2) Yes, stopping the IO target would prevent it. As it stands, the IO that happens in parallel can fail or succeed depending on when it hits the USB stack.

    3) It is definitely recommended for a client driver to only initiate one error recovery at a time. However, in this particular case, USB stack will deal with it and will not cause anything bad to happen (assuming IO is not being done in parallel). 

    Thank you for the clarifications. I have one more question. The spec for "Working with USB Pipes" reads

    >>>If your driver's USB target completes an I/O request with an error status value, your driver should do the following:

    1. Stop the pipe...

    2.Synchronously send an abort request to the pipe.  call WdfUsbTargetPipeAbortSynchronously ()

    3. Synchronously send a reset request to the pipe...

    4. Restart the pipe...

    Why is the sample also missing step 2? Is it because it assumes that there can only be one request(i.e. the one that triggered the work item) pending with the I/O at any given time ?


    • Edited by Frederick59 Wednesday, November 12, 2014 12:49 AM
    Wednesday, November 12, 2014 12:48 AM