From db95b4651e079e59353d8bafa84cc5ad23c4f2b1 Mon Sep 17 00:00:00 2001 From: Dmitry Fleytman Date: Thu, 2 Feb 2017 12:04:36 +0200 Subject: [PATCH] FilterDevice: Fix recognition of HUB devices Sometimes UsbDk cannot query device descriptors for USB hubs, in such cases it does not attach to theirs stack during parent bus relations processing. However, since UsbDk is registered as USB hub class filter, WDF will call its AddDevice callback anyway. In this case UsbDk should assume that it is dealing with a hub and assign its usual hub strategy. Signed-off-by: Dmitry Fleytman --- UsbDk/FilterDevice.cpp | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/UsbDk/FilterDevice.cpp b/UsbDk/FilterDevice.cpp index 01dfa82..74704c7 100644 --- a/UsbDk/FilterDevice.cpp +++ b/UsbDk/FilterDevice.cpp @@ -580,8 +580,18 @@ bool CUsbDkFilterDevice::CStrategist::SelectStrategy(PDEVICE_OBJECT DevObj) USB_DEVICE_DESCRIPTOR DevDescr; if (!m_Strategy->GetControlDevice()->GetDeviceDescriptor(ID, DevDescr)) { - TraceEvents(TRACE_LEVEL_ERROR, TRACE_FILTERDEVICE, "%!FUNC! Cannot query cached device descriptor"); - return false; + // If there is no cached device descriptor then we did not + // attach to this device stack during parent bus enumeration + // (see CUsbDkHubFilterStrategy::RegisterNewChild). + // In this case, the fact that WDF called our + // EVT_WDF_DRIVER_DEVICE_ADD callback for this device means that + // we are dealing with USB hub and WDF attached us to its stack + // automatically because UsbDk is registered in PNP manager as + // USB hubs filter + TraceEvents(TRACE_LEVEL_INFORMATION, TRACE_FILTERDEVICE, "%!FUNC! No cached device descriptor, assigning hub strategy"); + m_Strategy->Delete(); + m_Strategy = &m_HubStrategy; + return true; } // Device class is HUB -> Hub strategy