So for now in my generic parent I’m just trying to forward URBs down to my real device PDO to get a feel for how this is all going to work.
In my child PDO’s internal IOCTL queue dispatch routine, I’m calling WdfRequestFormatRequestUsingCurrentType(Request) and then WdfRequestSend() on the WDFIOTARGET that I got from WdfUsbTargetDeviceGetIoTarget() earlier on when initializing my bus driver FDO.
In my completion routine I’m reading STATUS_SUCCESS for each of the URBs that I’m getting back, but my function driver (which is calling WdfUsbTargetDeviceCreate()) is behaving strangely.
I’m getting IOCTL_INTERNAL_USB_SUBMIT_URB / URB_FUNCTION_GET_DESCRIPTOR_FROM_DEVICE three times in a row, and then I get URB_FUNCTION_GET_STATUS_FROM_DEVICE.
All four URBs return success, and I complete them with those same statuses, but my function driver bangs out after that fourth URB.
I’ve also considered using WdfIoTargetFormatRequestForInternalIoctl() when I pass the URB down, but I don’t know if it will make a difference.
Any ideas?
This is very BubbaGump of me, but after further investigation, I’ve realized the three requests are for the device descriptor, the first 9 bytes of the config descriptor, and then the entire config descriptor, and then the device status just comes back as “01 00”, which probably means “OK”.
Of course, my function driver then sees that my device has 9 interfaces because I haven’t faked any config descriptors yet, decides that’s a wee bit too many, and promptly bails. So, in other words, all is well.
WdfRequestFormatRequestUsingCurrentType is the functional equivalent of IoCopyCurrentIrpStackLocationToNext (which is why it cannot fail, while WdfIoTargetFormatRequestForInternalIoctl can fail since it must track the current state of the request so that it can restore the state when the request is completed). Since URB_FUNCTION_GET_STATUS_FROM_DEVICE is just another URB, WdfRequestFormatRequestUsingCurrentType is fine since both stack locations will have a pointer to the same URB. I would guess the failure is not because the URB completed with failure, but rather the function driver sending this URB is not finding a particular status value bit set, thus failing start. If you have the src for the function driver, debug its start path.
d
Yep, you were right, again. So would you recommend using WdfRequestFormatRequestUsingCurrentType() in situations where I am just passing URBs, rather than messing with WdfIoTargetFormatRequestForInternalIoctl()?
I’m assuming I’ll *need* to use WdfIoTargetFormatRequestForInternalIoctl() when I’m tweaking stuff on the way down. I’m not sure where that will be yet, but we’ll see. I’m planning on precomputing config descriptors and storing them in the child PDO’s device extension, so I’ll be able to complete those synchronously when they come, without talking to the device. Maybe translating select config => select interface if any of the pipe settings, etc. are requested to change (this is what the docs say usbccgp does).
yes, if you are just passing the request to an i/o target, WdfRequestFormatRequestUsingCurrentType is the least overhead to format the next stack location. Yes, you would use WdfIoTargetFormatRequestForInternalIoctl if the stack location you are going to format is not the same as the same as the current one. The thing I would imagine that you would need to alter is, like you said, the select config/interface calls, in which case you will need to either complete it immediately (in the select config case since it is already configured) or send it down (in the select interface setting case where the new setting is not the currently selected one).
d
xxxxx@gmail.com wrote:
This is very BubbaGump of me, but after further investigation, I’ve realized…
So, our favorite newsgroup poster has now become an adjective? 
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Tim Roberts wrote:
xxxxx@gmail.com wrote:
> This is very BubbaGump of me, but after further investigation, I’ve
> realized…
So, our favorite newsgroup poster has now become an
adjective?
Ha. Well, maybe. He doesn’t seem to be on this list, not that I think he would have been offended by my reference.
I really wonder if he does drivers for a living, or is just personally interested. I know I certainly don’t have time to think about all the stuff he posts about (thank you KMDF).
‘think’ is not a a word I would have associated with him. Stream of consciousness is more the term that comes to my mind
d
I keep hoping he will juist go off and create a BLOG. I used to look at
the newsgroups he has come to dominate with excitement, since I typically
could either help someone or learn something new from the majority of the
posting. Now I just put off looking there, since I expect all I will see
is Bubba.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply
wrote in message news:xxxxx@ntdev…
> ‘think’ is not a a word I would have associated with him. Stream of
> consciousness is more the term that comes to my mind
>
> d
>
Come on Don, you can just ignore all those threads and look at the more enjoyable ones 
… although it is a bit much to slog through
d