Timing of GET_STATUS request and SET_CONFIGURATION request

I have been evaluating KMDF USB Drivers for some USB Configurations.
And I noticed that the KMDF USB Driver issues the GET_STATUS request
automatically.
But, the GET_STATUS request is not issued at the same timing depending on
the USB Configurations.
The following results show timing differeces with regard to the the
GET_STATUS request and the SET_CONFIGURATION request.

[3] Multiple-Interface (Non-Composite) USB Device
- The GET_STATUS request is issued "BEFORE" the SET_CONFIGURATION request.
- The deive is queried for the status in the "Address/Default" state not in
the "Configured" state.

[Questions]
1) When is the the GET_STATUS request issued?
2) Why is the GET_STATUS request issued before the SET_CONFIGURATION request
only in the case of [3]?.
3) Is it possible for the the KMDF USB Driver to issue the GET_STATUS
request at any time? If so, how?
(I would like to issue the GET_STATUS request when the device is in the
"Configured" state. Because the host might get the wrong status information
from the device.)

Advertisements

[Questions]
1) When is the the GET_STATUS request issued?
2) Why is the GET_STATUS request issued before the SET_CONFIGURATION request
only in the case of [3]?.
3) Is it possible for the the KMDF USB Driver to issue the GET_STATUS
request at any time? If so, how?

Click to expand...

I seriously doubt you will get a definitive answer to this. This is all
just implementation detail, so there is no "contract".

(I would like to issue the GET_STATUS request when the device is in the
"Configured" state. Because the host might get the wrong status information
from the device.)

Click to expand...

Sorry, that violates the USB spec. Your device must respond to GET_STATUS
from either "address" or "configured" state. See section 9.4.5.

I'm surprised this is a problem. That request only returns two bits, and
they are typically constant for a device, no matter what state it is in.

Advertisements

I also posted the same report at the site "Microsoft Connect" with the
trace files by USB Bus Analyzer. They might give some comments to me about
this issue.

As you pointed out, the USB device has to respond to the GET_STATUS request
in the "Address" and "Configured" states.
And the USB device can have multiple configurations and the host can select
one of configurations. The device might have different configurations with
regard to the "bMaxPower" field of the configuration descriptor. And the
GET_STATUS request does not include the field for "Configuration Value".
Thus, the host has to change the configuration to get other configuration's
status information. So, I think, it is natural that the status information is
queried after the SET_CONFIGURATION request (in the "Configured" state).

I also noticed that the status information is used for
WdfUsbTargetDeviceRetrieveInformation(). In some of sample KMDF source codes,
WdfUsbTargetDeviceRetrieveInformation() is used to check and set the power
policy in the callback function "EvtDevicePrepareHardware".
I am thinking of issueing the GET_STATUS request via the
WDF_USB_CONTROL_SETUP_PACKED_INIT() and
WdfUsbTargetDeviceSendControlTransferSynchronously() in the callback function
"EvtDevicePrepareHardware", instead of using
WdfUsbTargetDeviceRetrieveInformation(), if there are not other approaches.
One concern is that the system might use the status information anywhere
other than WdfUsbTargetDeviceRetrieveInformation().

By the way, the status information was set when the SET_CONFIGURATION was
received in our USB device sample codes provided by RENESAS. Our device is
self-powered. But, the device was responding to the request as a bus-powered
device by mistake. That is why I noticed this problem.

Thanks.
Ganeshappa.

--
Thanks.
Ganeshappa.

Tim Roberts said:

Ganeshappa said:

[Questions]
1) When is the the GET_STATUS request issued?
2) Why is the GET_STATUS request issued before the SET_CONFIGURATION request
only in the case of [3]?.
3) Is it possible for the the KMDF USB Driver to issue the GET_STATUS
request at any time? If so, how?

Click to expand...

I seriously doubt you will get a definitive answer to this. This is all
just implementation detail, so there is no "contract".

(I would like to issue the GET_STATUS request when the device is in the
"Configured" state. Because the host might get the wrong status information
from the device.)

Click to expand...

Sorry, that violates the USB spec. Your device must respond to GET_STATUS
from either "address" or "configured" state. See section 9.4.5.

I'm surprised this is a problem. That request only returns two bits, and
they are typically constant for a device, no matter what state it is in.

windows really only supports devices with one configuration, not multi
config devices. KMDF was not tested with a multi config device so I don't
know if you will be able to use an alternative config descriptor
successfully. WdfUsbTargetDeviceRetrieveInformation is a KMDF wrapper around
GET_STATUS. as tim said, when windows sends the GET_STATUS is an
implementation detail, not a contract. nor is it a behavior you can change.

d

--

This posting is provided "AS IS" with no warranties, and confers no rights.

Ganeshappa said:

Dear Mr. Tim Roberts;

Thank you for responding to these questions.

I also posted the same report at the site "Microsoft Connect" with the
trace files by USB Bus Analyzer. They might give some comments to me about
this issue.

As you pointed out, the USB device has to respond to the GET_STATUS
request
in the "Address" and "Configured" states.
And the USB device can have multiple configurations and the host can
select
one of configurations. The device might have different configurations with
regard to the "bMaxPower" field of the configuration descriptor. And the
GET_STATUS request does not include the field for "Configuration Value".
Thus, the host has to change the configuration to get other
configuration's
status information. So, I think, it is natural that the status information
is
queried after the SET_CONFIGURATION request (in the "Configured" state).

I also noticed that the status information is used for
WdfUsbTargetDeviceRetrieveInformation(). In some of sample KMDF source
codes,
WdfUsbTargetDeviceRetrieveInformation() is used to check and set the power
policy in the callback function "EvtDevicePrepareHardware".
I am thinking of issueing the GET_STATUS request via the
WDF_USB_CONTROL_SETUP_PACKED_INIT() and
WdfUsbTargetDeviceSendControlTransferSynchronously() in the callback
function
"EvtDevicePrepareHardware", instead of using
WdfUsbTargetDeviceRetrieveInformation(), if there are not other
approaches.
One concern is that the system might use the status information anywhere
other than WdfUsbTargetDeviceRetrieveInformation().

By the way, the status information was set when the SET_CONFIGURATION was
received in our USB device sample codes provided by RENESAS. Our device is
self-powered. But, the device was responding to the request as a
bus-powered
device by mistake. That is why I noticed this problem.

Thanks.
Ganeshappa.

--
Thanks.
Ganeshappa.

Tim Roberts said:

Ganeshappa said:

[Questions]
1) When is the the GET_STATUS request issued?
2) Why is the GET_STATUS request issued before the SET_CONFIGURATION
request
only in the case of [3]?.
3) Is it possible for the the KMDF USB Driver to issue the GET_STATUS
request at any time? If so, how?

Click to expand...

I seriously doubt you will get a definitive answer to this. This is all
just implementation detail, so there is no "contract".

(I would like to issue the GET_STATUS request when the device is in the
"Configured" state. Because the host might get the wrong status
information
from the device.)

Click to expand...

Sorry, that violates the USB spec. Your device must respond to
GET_STATUS
from either "address" or "configured" state. See section 9.4.5.

I'm surprised this is a problem. That request only returns two bits, and
they are typically constant for a device, no matter what state it is in.

I think that there might be no serious problem if a device has only one
configuration and the power policy status is constant.

I will design the protocol, the USB device driver and USB devices under
restrictions of KMDF.

--
Thanks.
Ganeshappa.

Doron Holan said:

windows really only supports devices with one configuration, not multi
config devices. KMDF was not tested with a multi config device so I don't
know if you will be able to use an alternative config descriptor
successfully. WdfUsbTargetDeviceRetrieveInformation is a KMDF wrapper around
GET_STATUS. as tim said, when windows sends the GET_STATUS is an
implementation detail, not a contract. nor is it a behavior you can change.

d

--

This posting is provided "AS IS" with no warranties, and confers no rights.

Ganeshappa said:

Dear Mr. Tim Roberts;

Thank you for responding to these questions.

I also posted the same report at the site "Microsoft Connect" with the
trace files by USB Bus Analyzer. They might give some comments to me about
this issue.

As you pointed out, the USB device has to respond to the GET_STATUS
request
in the "Address" and "Configured" states.
And the USB device can have multiple configurations and the host can
select
one of configurations. The device might have different configurations with
regard to the "bMaxPower" field of the configuration descriptor. And the
GET_STATUS request does not include the field for "Configuration Value".
Thus, the host has to change the configuration to get other
configuration's
status information. So, I think, it is natural that the status information
is
queried after the SET_CONFIGURATION request (in the "Configured" state).

I also noticed that the status information is used for
WdfUsbTargetDeviceRetrieveInformation(). In some of sample KMDF source
codes,
WdfUsbTargetDeviceRetrieveInformation() is used to check and set the power
policy in the callback function "EvtDevicePrepareHardware".
I am thinking of issueing the GET_STATUS request via the
WDF_USB_CONTROL_SETUP_PACKED_INIT() and
WdfUsbTargetDeviceSendControlTransferSynchronously() in the callback
function
"EvtDevicePrepareHardware", instead of using
WdfUsbTargetDeviceRetrieveInformation(), if there are not other
approaches.
One concern is that the system might use the status information anywhere
other than WdfUsbTargetDeviceRetrieveInformation().

By the way, the status information was set when the SET_CONFIGURATION was
received in our USB device sample codes provided by RENESAS. Our device is
self-powered. But, the device was responding to the request as a
bus-powered
device by mistake. That is why I noticed this problem.

Thanks.
Ganeshappa.

--
Thanks.
Ganeshappa.

Tim Roberts said:

[Questions]
1) When is the the GET_STATUS request issued?
2) Why is the GET_STATUS request issued before the SET_CONFIGURATION
request
only in the case of [3]?.
3) Is it possible for the the KMDF USB Driver to issue the GET_STATUS
request at any time? If so, how?

I seriously doubt you will get a definitive answer to this. This is all
just implementation detail, so there is no "contract".

(I would like to issue the GET_STATUS request when the device is in the
"Configured" state. Because the host might get the wrong status
information
from the device.)

Sorry, that violates the USB spec. Your device must respond to
GET_STATUS
from either "address" or "configured" state. See section 9.4.5.

I'm surprised this is a problem. That request only returns two bits, and
they are typically constant for a device, no matter what state it is in.

First, I have to applogize to give you the wrong information about this
matter.

With regard to the case (1), the GET_STATUS request is issued "BEFORE" the
SET_CONFIGURATION request.

(I rechecked the trace file of (1) after the Microsoft USB team pointed out
this matter. And I knew that they were right.)

By the way, I got two replies from the Microsoft USB team with this issue
like below.

<< Response1 form Microsoft USB Team >>

Dear Ganeshappa,
Thank you for sending feedback. Based on the description, this seems to be
XP releated issue. I suggest following up with Microsoft DDK support team for
XP support issues. This feedback is targeted for upcoming Windows 7 OS
release.

<< Response2 form Microsoft USB Team >>

Dear Ganeshappa,

In my previous response, I forgot to add the response to some of your
questions

[Questions]
1) When is the the GET_STATUS request issued?
The URB_FUNCTION_GET_STATUS_FROM_DEVICE request is issued by KMDF during
WdfUsbTargetDeviceCreate()

2) Why is the GET_STATUS request issued before the SET_CONFIGURATION request
only in the case of [3]?.
(2) Contrary to your statement, the URB_FUNCTION_GET_STATUS_FROM_DEVICE
request is issued before the URB_FUNCTION_SELECT_CONFIGURATION request both
in trace [1] SingleDevice.usb and in trace [3]
MultipleIfNonCompositeDevice.usb. It is only in trace [2]
MultipleIfCompositeDevice.usb that the URB_FUNCTION_GET_STATUS_FROM_DEVICE
request is issued after the URB_FUNCTION_SELECT_CONFIGURATION request.

The URB_FUNCTION_GET_STATUS_FROM_DEVICE request is issued after the
URB_FUNCTION_SELECT_CONFIGURATION request in the composite device case
because the USBCCGP composite device driver issues a
URB_FUNCTION_SELECT_CONFIGURATION request at the time it receives the
IRP_MN_START_DEVICE request, which is prior to when
WdfUsbTargetDeviceCreate() would be called.

[Questions]
1) When is the the GET_STATUS request issued?
2) Why is the GET_STATUS request issued before the SET_CONFIGURATION request
only in the case of [3]?.
3) Is it possible for the the KMDF USB Driver to issue the GET_STATUS
request at any time? If so, how?

Click to expand...

I seriously doubt you will get a definitive answer to this. This is all
just implementation detail, so there is no "contract".

(I would like to issue the GET_STATUS request when the device is in the
"Configured" state. Because the host might get the wrong status information
from the device.)

Click to expand...

Sorry, that violates the USB spec. Your device must respond to GET_STATUS
from either "address" or "configured" state. See section 9.4.5.

I'm surprised this is a problem. That request only returns two bits, and
they are typically constant for a device, no matter what state it is in.

First, I have to applogize for giving you the wrong information about this
matter.

With regard to the case (1), the GET_STATUS request is issued "BEFORE" the
SET_CONFIGURATION request.

(I rechecked the trace file of (1) after the Microsoft USB team pointed out
this matter. And I knew that they were right.)

By the way, I got two replies from the Microsoft USB team with this issue
like below.

<< Response1 form Microsoft USB Team >>

Dear Ganeshappa,
Thank you for sending feedback. Based on the description, this seems to be
XP releated issue. I suggest following up with Microsoft DDK support team for
XP support issues. This feedback is targeted for upcoming Windows 7 OS
release.

<< Response2 form Microsoft USB Team >>

Dear Ganeshappa,

In my previous response, I forgot to add the response to some of your
questions

[Questions]
1) When is the the GET_STATUS request issued?
The URB_FUNCTION_GET_STATUS_FROM_DEVICE request is issued by KMDF during
WdfUsbTargetDeviceCreate()

2) Why is the GET_STATUS request issued before the SET_CONFIGURATION request
only in the case of [3]?.
(2) Contrary to your statement, the URB_FUNCTION_GET_STATUS_FROM_DEVICE
request is issued before the URB_FUNCTION_SELECT_CONFIGURATION request both
in trace [1] SingleDevice.usb and in trace [3]
MultipleIfNonCompositeDevice.usb. It is only in trace [2]
MultipleIfCompositeDevice.usb that the URB_FUNCTION_GET_STATUS_FROM_DEVICE
request is issued after the URB_FUNCTION_SELECT_CONFIGURATION request.

The URB_FUNCTION_GET_STATUS_FROM_DEVICE request is issued after the
URB_FUNCTION_SELECT_CONFIGURATION request in the composite device case
because the USBCCGP composite device driver issues a
URB_FUNCTION_SELECT_CONFIGURATION request at the time it receives the
IRP_MN_START_DEVICE request, which is prior to when
WdfUsbTargetDeviceCreate() would be called.

windows really only supports devices with one configuration, not multi
config devices. KMDF was not tested with a multi config device so I don't
know if you will be able to use an alternative config descriptor
successfully. WdfUsbTargetDeviceRetrieveInformation is a KMDF wrapper around
GET_STATUS. as tim said, when windows sends the GET_STATUS is an
implementation detail, not a contract. nor is it a behavior you can change.

d

--

This posting is provided "AS IS" with no warranties, and confers no rights.

Ganeshappa said:

Dear Mr. Tim Roberts;

Thank you for responding to these questions.

I also posted the same report at the site "Microsoft Connect" with the
trace files by USB Bus Analyzer. They might give some comments to me about
this issue.

As you pointed out, the USB device has to respond to the GET_STATUS
request
in the "Address" and "Configured" states.
And the USB device can have multiple configurations and the host can
select
one of configurations. The device might have different configurations with
regard to the "bMaxPower" field of the configuration descriptor. And the
GET_STATUS request does not include the field for "Configuration Value".
Thus, the host has to change the configuration to get other
configuration's
status information. So, I think, it is natural that the status information
is
queried after the SET_CONFIGURATION request (in the "Configured" state).

I also noticed that the status information is used for
WdfUsbTargetDeviceRetrieveInformation(). In some of sample KMDF source
codes,
WdfUsbTargetDeviceRetrieveInformation() is used to check and set the power
policy in the callback function "EvtDevicePrepareHardware".
I am thinking of issueing the GET_STATUS request via the
WDF_USB_CONTROL_SETUP_PACKED_INIT() and
WdfUsbTargetDeviceSendControlTransferSynchronously() in the callback
function
"EvtDevicePrepareHardware", instead of using
WdfUsbTargetDeviceRetrieveInformation(), if there are not other
approaches.
One concern is that the system might use the status information anywhere
other than WdfUsbTargetDeviceRetrieveInformation().

By the way, the status information was set when the SET_CONFIGURATION was
received in our USB device sample codes provided by RENESAS. Our device is
self-powered. But, the device was responding to the request as a
bus-powered
device by mistake. That is why I noticed this problem.

Thanks.
Ganeshappa.

--
Thanks.
Ganeshappa.

Tim Roberts said:

[Questions]
1) When is the the GET_STATUS request issued?
2) Why is the GET_STATUS request issued before the SET_CONFIGURATION
request
only in the case of [3]?.
3) Is it possible for the the KMDF USB Driver to issue the GET_STATUS
request at any time? If so, how?

I seriously doubt you will get a definitive answer to this. This is all
just implementation detail, so there is no "contract".

(I would like to issue the GET_STATUS request when the device is in the
"Configured" state. Because the host might get the wrong status
information
from the device.)

Sorry, that violates the USB spec. Your device must respond to
GET_STATUS
from either "address" or "configured" state. See section 9.4.5.

I'm surprised this is a problem. That request only returns two bits, and
they are typically constant for a device, no matter what state it is in.

Welcome to Windows Vista Tips

Welcome to Windows Vista Tips, your resource for help for any tech support and computing help with Windows Vista..

Please join our friendly community by clicking the button below - it only takes a few seconds and is totally free. You'll be able to ask questions about Vista or chat with the community and help others.
Ask a Question