Re: [PATCH v2 0/4] MR10604: setupapi, ntoskrnl: Implement CM_Get_Parent with device tree properties

[Jan Robert Gerigk (＠RgSg86)]

On Thu Apr  9 01:29:48 2026 +0000, Jan Robert Gerigk wrote:
> Great detailed feedback, thanks! That is a lot to work through, I think
> it will take me a while.
> I think I have addressed all feedback points:

ntoskrnl:

Removed the unnecessary comment and the if (parent_device) check. enumerate_new_device now receives the parent device object directly (no original_parent field). Uses wcslen/malloc instead of lstrlenW/HeapAlloc. Removed error handling gymnastics for get_device_instance_id, if it fails there's no point proceeding. Children and Siblings are stored in separate commits, comments removed. Removed unnecessary if (relations-\>Count \> 0) check. Siblings moved out to their own block. 

cfgmgr32:

CM_Get_Parent implemented in cfgmgr32, setupapi forwards to it.

Tests:

Simplified CM_Get_Parent error check to CR_SUCCESS || CR_NO_SUCH_DEVNODE. Kept the if (ret == CR_SUCCESS) guard before CM_Get_Device_IDA. The test device is created manually via SetupDiCreateDeviceInfoW, not through bus enumeration, so DEVPKEY_Device_Parent is never stored for it. CM_Get_Parent returns CR_NO_SUCH_DEVNODE in this case, and calling CM_Get_Device_IDA on an uninitialized devnode would crash. Added ok() check for SetupDiRemoveDevice.

New commit: 

cfgmgr32: Fix reading device properties stored as registry subkeys.

While switching to cfgmgr32 s internal APIs (devnode_get_device + get_device_property), I found that query_property cannot read properties stored by SetupDiSetDevicePropertyW. It tries to read them as flat value names, but setupapi stores them as registry subkey hierarchies (Properties{GUID}\\XXXX with the data in the default value). Added a fallback to open the property subkey when the flat lookup fails.

The final version has been tested locally with a freshly compiled Wine build including all these patches. All tests pass on my local maschine. (26430 ntoskrnl, 4366 setupapi devinst, 235 shcore, 0 failures). 

Also verified again with my real use-case, CM_Get_Parent correctly returns the USB parent device. The USB license dongle is correctly detected and used by the software.

That was incredibly complex for me, I hope I did not miss anything.

-- 
https://gitlab.winehq.org/wine/wine/-/merge_requests/10604#note_135887