Why my USB continous reader can't receive the Interrupt pipe input

Hi,

I’m working the driver of the lower filter of the XUsb11.sys for the third party keypad. I hook the IOCTL_INTERNAL_USB_SUBMIT_URB/URB_FUNCTION_SELECT_CONFIGURATION and call WdfUsbTargetDeviceSelectConfig to get the WdfUsbPipe. After that, I call WdfIoTargetStart for the IoTarget that associated with the pipe. Then I configure the continuous reader for the pipe. All operation succeeds but the problem is that I can’t receive any data from the pipe. The MSDN says WdfIoTargetStart must be called in EvtD0Entry. But in my case, the pipe is not valid in EvtD0Entry. Is it the root cause that I can’t receive the data from that pipe? I dictate some code here for your referece.

//
// After configuration, we can retrieve the pipe handle of keypad for later
// usage. According to the doc, the pipe address of the keypad is always 0x84.
//
status = XFilter_GetKeypadPipe(hDevice,
XFILTER_KEYPAD_PIPE_ADDRESS,
&pDeviceContext->hKeypadPipe
);

//
// Start the pipe to transfer the request
//
status = WdfIoTargetStart(WdfUsbTargetPipeGetIoTarget(pDeviceContext->hKeypadPipe));

//
// Configure the keypad continuous reader
//
status = XFilter_ConfigureKeypadContinuousReader(
hDevice,
pDeviceContext->hKeypadPipe,
XFilter_EvtReadCompleteForKeypad
);

NTSTATUS
XFilter_GetKeypadPipe(
IN WDFDEVICE hDevice,
IN UCHAR ucKeypadPipeAddress,
OUT WDFUSBPIPE *phUsbPipe
)
{
pDeviceContext = XFilter_GetDeviceContext(hDevice);

ucInterfaceNumber = WdfUsbTargetDeviceGetNumInterfaces(pDeviceContext->usbDevice);
for (ucInterfaceIndex = 0; ucInterfaceIndex < ucInterfaceNumber && bFound == FALSE; ucInterfaceIndex++)
{
hUsbInterface = WdfUsbTargetDeviceGetInterface(pDeviceContext->usbDevice, ucInterfaceIndex);
ucPipeNumber = WdfUsbInterfaceGetNumConfiguredPipes(hUsbInterface);
for (ucPipeIndex = 0; ucPipeIndex < ucPipeNumber && bFound == FALSE; ucPipeIndex++)
{
WDF_USB_PIPE_INFORMATION_INIT(&usbPipeInfo);
hUsbPipe = WdfUsbInterfaceGetConfiguredPipe(hUsbInterface, ucPipeIndex, &usbPipeInfo);
if (usbPipeInfo.EndpointAddress == ucKeypadPipeAddress)
{
bFound = TRUE;
*phUsbPipe = hUsbPipe;
}
}
}
return status;
}

NTSTATUS
XFilter_ConfigureKeypadContinuousReader(
IN WDFDEVICE hDevice,
IN WDFUSBPIPE hUsbPipe,
IN PFN_WDF_USB_READER_COMPLETION_ROUTINE pfnUsbReaderCompletionRoutine
)
{
//
// Tell the framework that it’s okay to read less than
// MaximumPacketSize
//
WdfUsbTargetPipeSetNoMaximumPacketSizeCheck(hUsbPipe);

WDF_USB_PIPE_INFORMATION_INIT(&usbPipeInfo);
WdfUsbTargetPipeGetInformation(hUsbPipe, &usbPipeInfo);

WDF_USB_CONTINUOUS_READER_CONFIG_INIT(
&usbContinuousReaderConfig,
pfnUsbReaderCompletionRoutine,
hDevice,
1024
);

//
// Reader requests are not posted to the target automatically.
// Driver must explictly call WdfIoTargetStart to kick start the
// reader.
//
status = WdfUsbTargetPipeConfigContinuousReader(
hUsbPipe,
&usbContinuousReaderConfig
);

return status;
}

xxxxx@hotmail.com wrote:

I’m working the driver of the lower filter of the XUsb11.sys for the third party keypad. I hook the IOCTL_INTERNAL_USB_SUBMIT_URB/URB_FUNCTION_SELECT_CONFIGURATION and call WdfUsbTargetDeviceSelectConfig to get the WdfUsbPipe. After that, I call WdfIoTargetStart for the IoTarget that associated with the pipe. Then I configure the continuous reader for the pipe. All operation succeeds but the problem is that I can’t receive any data from the pipe.

What do you do with the original SELECT_CONFIGURATION call that you
received? Do you pass it on down after you are finished, or do you
complete it yourself? If you pass it down, then that
SELECT_CONFIGURATION is basically going to invalidate yours.
SELECT_CONFIGURATION resets a bunch of data structures in the host
controller driver and creates a new configuration handle. A second
select invalidates the first one.

Isn’t xusb11.sys doing its own continuous reader? Are you intercepting
that as well?

What is the overall goal you are trying to accomplish here?


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

Thanks, Tim.

I complete the original SELECT_CONFIGURATION so that I can retrieve the WdfUsbPipe handle myself. The pipe is XUsb11.sys doesn’t configure the continuous reader on this pipe otherwise my calling should fail with WdfUsbTargetPipeConfigContinuousReader. I used to intercept the URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER as well but see no data through to that pipe.

The purpose of this driver to add the functionality to support the keypad attached to the controller through the earphone interface.

Does it matter that the calling order of WdfIoTargetStart and WdfUsbTargetPipeConfigContinuousReader. Now I call WdfIoTargetStart before WdfUsbTargetPipeConfigContinuousReader.

Thanks,
Marshall

xxxxx@hotmail.com wrote:

I complete the original SELECT_CONFIGURATION so that I can retrieve the WdfUsbPipe handle myself. The pipe is XUsb11.sys doesn’t configure the continuous reader on this pipe otherwise my calling should fail with WdfUsbTargetPipeConfigContinuousReader.

That’s not true. The KMDF continuous reader just submits a series of
read URBs in a loop. There’s nothing in the USB stack that says there
can only be one continuous reader.

When you complete the original SELECT_CONFIGURATION, are you copying the
handle information that you got back? If you don’t pass the
configuration handle back up to xusb11.sys, then it will never be able
to submit any URBs.

Does it matter that the calling order of WdfIoTargetStart and WdfUsbTargetPipeConfigContinuousReader. Now I call WdfIoTargetStart before WdfUsbTargetPipeConfigContinuousReader.

Did you read the documentation?

After calling *WdfUsbTargetPipeConfigContinuousReader* to configure
a continuous reader, your driver must call *WdfIoTargetStart*
http:
to start the reader. To stop the reader, the driver must call
WdfIoTargetStop
http:.

My point is that you need to remember that you do not “own” this
hardware. As a filter driver, you are “borrowing” the hardware. The
driver you are filtering assumes it owns the hardware. You have to be a
good neighbor. Right now, it’s more like you are wrestling complete
control of the device away from xusb11.sys.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.</http:></http:>