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

[Elizabeth Figura (＠zfigura)]

Hi, my sincere apologies for the delay; I've had some life circumstances that have made it a bit difficult to get to review, though still that's no excuse for silence.

2/9 passes even without 1/9, and looking closer at 1/9, I'm confused at how it can have an effect. When we enumerate interfaces, we check one specific interface key or all of them. Regardless of whether we have DIGCF_ALLCLASSES or not, it shouldn't be possible to list a device that has no interfaces. Does this commit actually make a difference for the application? It may be worth splitting into a separate merge request anyway.

From 6/9:

```
+        found_child = FALSE;
+        for (entry = buffer_w; *entry; entry += wcslen(entry) + 1)
+        {
+            /* PnP instance IDs are case-insensitive; the driver reports
+             * "Wine\\Test" while other SetupAPI paths uppercase-normalise. */
+            if (!wcsicmp(entry, L"Wine\\Test\\1"))
+            {
+                found_child = TRUE;
+                break;
+            }
+        }
+        ok(found_child, "expected Wine\\Test\\1 in DEVPKEY_Device_Children\n");
+        SetupDiDestroyDeviceInfoList(bus_set);
```

We've had applications be sensitive to case before. I would prefer to test the proper case instead of using wcsicmp().

And, can't we compare the whole list exactly? We control what children this device has.

DEVPKEY_Device_Siblings is still missing a test.

From 9/9:

```
+    /* CM_Get_Parent on a registered device. The parent property is set by
+     * the PnP manager during bus enumeration; manually created devices may
+     * not have it, so CR_NO_SUCH_DEVNODE is acceptable. */
+    ret = SetupDiRegisterDeviceInfo(set, &device, 0, NULL, NULL, NULL);
+    ok(ret, "SetupDiRegisterDeviceInfo failed: %#lx\n", GetLastError());
+
+    parent = 0;
+    ret = CM_Get_Parent(&parent, device.DevInst, 0);
+    ok(ret == CR_SUCCESS || ret == CR_NO_SUCH_DEVNODE,
+       "CM_Get_Parent: got %#lx\n", ret);
```

Does this imply that we always get CR_NO_SUCH_DEVNODE in practice here? Or is it really variable for some reason? If the former, this test doesn't seem particularly useful where it is, and it should probably be run on the ntoskrnl device instead.

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