About the OSRUSBFX2 sample driver

NTDEV
1

Hi folks,

I am studying the OSRUSBFX2 driver and have a few questions:

  1. If WdfUsbTargetDeviceResetPortSynchronously fails, is it still OK
    to call WdfIoTargetStart trying to start all pipes? The code is as follows:

// From ioctl.c, ResetDevice(.)

win2k = IsItWin2k();

…

if (win2k) { StopAllPipes(pDeviceContext); }

status =
WdfUsbTargetDeviceResetPortSynchronously(pDeviceContext->UsbDevice);

if (!NT_SUCCESS(status)) {

TraceEvents(TRACE_LEVEL_ERROR, DBG_IOCTL, “ResetDevice failed - 0x%x\n”,
status);

}

if (win2k) {

StartAllPipes(pDeviceContext); // this calls WdfIoTargetStart

}

  1. MSDN said: “The driver must call WdfIoTargetStop before it calls
    WdfUsbTargetDeviceResetPortSynchronously. After
    WdfUsbTargetDeviceResetPortSynchronously returns, the driver can call
    WdfIoTargetStart.”. So drivers are required to stop all pipes before calling
    WdfUsbTargetDeviceResetPortSynchronously. Does this rule only apply to win2k
    (or the versions after)?

  2. In EvtDeviceReleaseHardware, should the driver try to stop all
    pipes and deconfigure the device; or the bus (hub) driver will do the job
    instead?

Thank you very much.

Juncao Li

2

For 3, releasehw() is called after the power down path (ie D0Exit and friends). The power down path already stops the pipes, so releasehw() does not need to do that. The underlying bus will deconfig the device, you don’t have to do that either. WdfIoTargetStop/Start do not know about WdfUsbTargetDeviceResetPortSynchronously, so in the case of faiiure being returned from WdfUsbTargetDeviceResetPortSynchronously you can start the WDFUSBDEVICE again, but any new IO you send may fail b/c of invalidate state due to the previous reset failure. As for requiring all io on the pipes be stopped before the reset, I don’t remember what the rules are there

d

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Juncao Li
Sent: Thursday, June 03, 2010 9:31 PM
To: Windows System Software Devs Interest List
Cc: ‘Juncao Li’
Subject: [ntdev] About the OSRUSBFX2 sample driver

Hi folks,

I am studying the OSRUSBFX2 driver and have a few questions:

  1. If WdfUsbTargetDeviceResetPortSynchronously fails, is it still OK to call WdfIoTargetStart trying to start all pipes? The code is as follows:

// From ioctl.c, ResetDevice(…)

win2k = IsItWin2k();
…
if (win2k) { StopAllPipes(pDeviceContext); }

status = WdfUsbTargetDeviceResetPortSynchronously(pDeviceContext->UsbDevice);
if (!NT_SUCCESS(status)) {

TraceEvents(TRACE_LEVEL_ERROR, DBG_IOCTL, “ResetDevice failed - 0x%x\n”, status);
}

if (win2k) {

StartAllPipes(pDeviceContext); // this calls WdfIoTargetStart

}

  1. MSDN said: “The driver must call WdfIoTargetStop before it calls WdfUsbTargetDeviceResetPortSynchronously. After WdfUsbTargetDeviceResetPortSynchronously returns, the driver can call WdfIoTargetStart.”. So drivers are required to stop all pipes before calling WdfUsbTargetDeviceResetPortSynchronously. Does this rule only apply to win2k (or the versions after)?

  2. In EvtDeviceReleaseHardware, should the driver try to stop all pipes and deconfigure the device; or the bus (hub) driver will do the job instead?

Thank you very much.

Juncao Li

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

3

Thanks, Doron.

Does the driver need to stop all pipes on the power down path, e.g. in
D0Exit? Or only the interrupt pipe should be stopped?

Best wishes,

Juncao Li

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Thursday, June 03, 2010 9:48 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] About the OSRUSBFX2 sample driver

For 3, releasehw() is called after the power down path (ie D0Exit and
friends). The power down path already stops the pipes, so releasehw() does
not need to do that. The underlying bus will deconfig the device, you don’t
have to do that either. WdfIoTargetStop/Start do not know about
WdfUsbTargetDeviceResetPortSynchronously, so in the case of faiiure being
returned from WdfUsbTargetDeviceResetPortSynchronously you can start the
WDFUSBDEVICE again, but any new IO you send may fail b/c of invalidate state
due to the previous reset failure. As for requiring all io on the pipes be
stopped before the reset, I don’t remember what the rules are there

d

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Juncao Li
Sent: Thursday, June 03, 2010 9:31 PM
To: Windows System Software Devs Interest List
Cc: ‘Juncao Li’
Subject: [ntdev] About the OSRUSBFX2 sample driver

Hi folks,

I am studying the OSRUSBFX2 driver and have a few questions:

  1. If WdfUsbTargetDeviceResetPortSynchronously fails, is it still OK
    to call WdfIoTargetStart trying to start all pipes? The code is as follows:

// From ioctl.c, ResetDevice(.)

win2k = IsItWin2k();

…

if (win2k) { StopAllPipes(pDeviceContext); }

status =
WdfUsbTargetDeviceResetPortSynchronously(pDeviceContext->UsbDevice);

if (!NT_SUCCESS(status)) {

TraceEvents(TRACE_LEVEL_ERROR, DBG_IOCTL, “ResetDevice failed - 0x%x\n”,
status);

}

if (win2k) {

StartAllPipes(pDeviceContext); // this calls WdfIoTargetStart

}

  1. MSDN said: “The driver must call WdfIoTargetStop before it calls
    WdfUsbTargetDeviceResetPortSynchronously. After
    WdfUsbTargetDeviceResetPortSynchronously returns, the driver can call
    WdfIoTargetStart.”. So drivers are required to stop all pipes before calling
    WdfUsbTargetDeviceResetPortSynchronously. Does this rule only apply to win2k
    (or the versions after)?

  2. In EvtDeviceReleaseHardware, should the driver try to stop all
    pipes and deconfigure the device; or the bus (hub) driver will do the job
    instead?

Thank you very much.

Juncao Li

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

4

you need to stop all io on all pipes when powering down, the usb core does not allow pended io on an endpoint after it has powered down

d

From: xxxxx@lists.osr.com [xxxxx@lists.osr.com] on behalf of Juncao Li [juncao@cs.pdx.edu]
Sent: Thursday, June 03, 2010 10:26 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] About the OSRUSBFX2 sample driver

Thanks, Doron.

Does the driver need to stop all pipes on the power down path, e.g. in D0Exit? Or only the interrupt pipe should be stopped?

Best wishes,
Juncao Li

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Thursday, June 03, 2010 9:48 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] About the OSRUSBFX2 sample driver

For 3, releasehw() is called after the power down path (ie D0Exit and friends). The power down path already stops the pipes, so releasehw() does not need to do that. The underlying bus will deconfig the device, you don?t have to do that either. WdfIoTargetStop/Start do not know about WdfUsbTargetDeviceResetPortSynchronously, so in the case of faiiure being returned from WdfUsbTargetDeviceResetPortSynchronously you can start the WDFUSBDEVICE again, but any new IO you send may fail b/c of invalidate state due to the previous reset failure. As for requiring all io on the pipes be stopped before the reset, I don?t remember what the rules are there

d

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Juncao Li
Sent: Thursday, June 03, 2010 9:31 PM
To: Windows System Software Devs Interest List
Cc: ‘Juncao Li’
Subject: [ntdev] About the OSRUSBFX2 sample driver

Hi folks,

I am studying the OSRUSBFX2 driver and have a few questions:

  1. If WdfUsbTargetDeviceResetPortSynchronously fails, is it still OK to call WdfIoTargetStart trying to start all pipes? The code is as follows:

// From ioctl.c, ResetDevice(?)

win2k = IsItWin2k();
??
if (win2k) { StopAllPipes(pDeviceContext); }

status = WdfUsbTargetDeviceResetPortSynchronously(pDeviceContext->UsbDevice);
if (!NT_SUCCESS(status)) {

TraceEvents(TRACE_LEVEL_ERROR, DBG_IOCTL, “ResetDevice failed - 0x%x\n”, status);
}

if (win2k) {

StartAllPipes(pDeviceContext); // this calls WdfIoTargetStart

}

  1. MSDN said: ?The driver must call WdfIoTargetStop before it calls WdfUsbTargetDeviceResetPortSynchronously. After WdfUsbTargetDeviceResetPortSynchronously returns, the driver can call WdfIoTargetStart.?. So drivers are required to stop all pipes before calling WdfUsbTargetDeviceResetPortSynchronously. Does this rule only apply to win2k (or the versions after)?

  2. In EvtDeviceReleaseHardware, should the driver try to stop all pipes and deconfigure the device; or the bus (hub) driver will do the job instead?

Thank you very much.

Juncao Li

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer