Re: USB device descriptor IOCTLs strangeness

xxxxx@hotmail.com wrote:

Lower filtering a USB FDO I have noticed that the descriptor requests sent down come back with a different IOCTL code.

No, it doesn’t. Same IOCTL code. Different URB code.

For example,

URB_FUNCTION_GET_DESCRIPTOR_FROM_DEVICE, Irp FFFF9488B0D4E010 DOWN
URB_FUNCTION_CONTROL_TRANSFER, Irp FFFF9488B0D4E010 UP

Has anyone noticed this, and is there a reason for this odd behaviour? Why would the hub driver change the IOCTL?

This is just a trivial implementation detail. About 3/4 of the URB
codes translate directly into simple control pipe requests. So, the hub
driver (or someone in the stack) translates the descriptor, feature,
status, vendor, and class URBs requests into their equivalent control
pipe requests, by setting up the 8-byte control packet and changing the
URB code. That way, the lower level drivers only have to deal with
about 15 different requests, instead of 40 different requests.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Well OK, if you want to be pedantic about it, yes, its still an internal device IOCTL, but its a different URB code. I think you get the meaning alright.

I wouldn’t call the impact trivial though, makes it bloody hard to follow!

Anyway, at least the pip information isnt screwed around with so at least it IS easy to extract fro the URB on the way up.

Anyway, thanks for confirming its basically illogical. For whatever reason.