Hi,
I am writing a bus driver for windows XP.
Till now (after reading some previous posts)I have written the code to parse the Configuration descriptor, create per PDO configuration descriptor and create the PDO(s) for the chid devices.
Some queries :
- Does usbccgp.sys supports the Union Function Descriptor(UFD) on windows XP SP2 ?
As when I installed usbccgp.sys for my composite device , it creted PDO for every interface and not according to the UFD. changing the CdcFlags has no effect on enumeration
Using inf file from the following link
http://msdn.microsoft.com/en-us/library/ff537100(VS.85).aspx
the same inf files enumerate according to UFD’s on windows 7 .
- When Installed one of my child device on my custom bus driver, child never sets theTransferFlags USBD_DEFAULT_PIPE_TRANSFER , so in my composite bus driver I am manually setting this flag for every URB_FUNCTION_CONTROL_TRANSFER.
Is this correct ? To my understanding , child device should set this flag if it wants to send it to default pipe.child driver is sending a request using WdfUsbTargetDeviceSendControlTransferSynchronously with Request parameter NULL.
but when I install the same child driver over usbccgp.sys it sets the TransferFlags USBD_DEFAULT_PIPE_TRANSFER. confused what is going wrong here?
- Is it necessary for composite bus driver to handle IOCTL_INTERNAL_USB_GET_PORT_STATUS?
If i do not handle it in my composite bus driver, the device manger shows respective entries for my composite bus driver and child drivers even after surprise removal.
If I intercept IOCTL_INTERNAL_USB_GET_PORT_STATUS and then call WdfUsbTargetDeviceIsConnectedSynchronous and complete the IOCTL request with status returned , surprise removes works fine.
So, do I have to handle this IOCTL or can just pass it to lower driver (hub) and the hub will handle it ? what is correct behaviour?
tried my best to give all necessary information.
thanks in advance
JItender Singh wrote:
- Does usbccgp.sys supports the Union Function Descriptor(UFD)
on windows XP SP2 ?
Well, let’s see:
As when I installed usbccgp.sys for my composite device , it creted
PDO for every interface and not according to the UFD.
It seems like the answer is “no”.
- When Installed one of my child device on my custom bus driver,
child never sets theTransferFlags USBD_DEFAULT_PIPE_TRANSFER ,
so in my composite bus driver I am manually setting this flag for every
URB_FUNCTION_CONTROL_TRANSFER.
What interface number are you reporting in your faux PDO’s config descriptor?
- Is it necessary for composite bus driver to handle
IOCTL_INTERNAL_USB_GET_PORT_STATUS?
If i do not handle it in my composite bus driver, the device manger
shows respective entries for my composite bus driver and child
drivers even after surprise removal.
If I intercept IOCTL_INTERNAL_USB_GET_PORT_STATUS and
then call WdfUsbTargetDeviceIsConnectedSynchronous and
complete the IOCTL request with status returned , surprise
removes works fine.
Well, think of it this way. If you report a port status that indicates some sort of failure or problem, the child function driver is probably going to initiate some action to try to reset the device because it thinks it’s the sole owner. Are you prepared to manage that among the other child devices? If not, I would just return success (my code says 0x03, USBD_PORT_ENABLED | USBD_PORT_CONNECTED).
To Chris ,
One thing confuses me for the IOCTL_INTERNAL_USB_GET_PORT_STATUS
The comment for this snippet says , this request might be issued in a locked scenario (I suppose Dispatch level). I also add some debug code and verifies there are such kind of cases (seems this request is from USB mass storage). However , MSDN says this request should be issued in Passive level . So , does it violate the description of MSDN ???
Please feel free to point out my incorrectness .
To OP,
Reply to the question 2 , device state changing IRP seems to be blocked and they are hanging in device manager accordingly . You can check where the hang happens using windbg …
To Chris ,
If 0x03 is returned explicitly , it might give rise to a potential defect.
Consider this case ,
If a composite device is unplugged unexpectedly(surprise removed) , child device driver would send several request of IOCTL_INTERNAL_USB_GET_PORT_STATUS to retrieve “real” device state to determine what should it do next . If 0x03 is simply returned , it might make child device misunderstand and accordingly unloading procedure is delayed.
thanks for clarifying my doubts.
Do I missed something to add in faux config descriptor for Default endpoint ?
In per PDO Config descriptors I have structure similar to usb devices’ config descriptor .
I am creating PDO according to UFD, so in PDOs’ faux config descriptor I am concatenating the master interface and slave interfaces
Configuration Descriptor
Interface Desc (say 0)
Functional Descriptor(s )
Endpoint Descriptor(s)
Interface Desc (say 1)
Functional Descriptor(s)
Endpoint Descriptor(s)
… and so on
Daniel Xie wrote:
The comment for this snippet says , this request might be
issued in a locked scenario (I suppose Dispatch level). I also
add some debug code and verifies there are such kind of cases
(seems this request is from USB mass storage). However ,
MSDN says this request should be issued in Passive level .
So , does it violate the description of MSDN ???
Ahh, where would I be without Daniel to air my dirty laundry… 
I think the real problem is that the child PDO is set up with WdfSynchronizationScopeDevice, so all the internal IOCTLs coming into the child PDO’s default queue are going to be seen with the device spinlock held, yes? Thus you’re going to be at dispatch…
As for your other concern, sure, the function driver for the virtual child device might get a bogus successful status, but who cares? Those stacks are going to get torn down themselves anyway, if they are blocking because they received a successful PORT_STATUS followed by a surprise remove, then that is a bug, in my opinion…
>>>>>I think the real problem is that the child PDO is set up with WdfSynchronizationScopeDevice, so all the internal IOCTLs …
Fully understand…
Then I fully understand the issue I raised several days ago : http://www.osronline.com/showthread.cfm?link=180796
the irps which should have been issued in Passive level is boosted to Dispatch ,saying IOCTL_INTERNAL_USB_CYCLE_PORT and will make the call to lower level driver hang …
… .
I need to dispatch a workitem for it
Daniel Xie wrote:
I need to dispatch a workitem for it
I think it would be easier to change WdfSynchronizationScopeDevice to WdfSynchronizationScopeNone. I don’t think the device-level locking does you any good in this situation.