Hi Len, Rafael I'm having some trouble with how the kernel is treating some ACPI devices, and I'm hoping for some help. For reference, the DSDT tables for everything I'm talking about below can be found here. The device in question is a Lenovo Miix 510: https://gist.githubusercontent.com/djrscally/e64d112180517352fa3392878b0f4a7d/raw/88b90b3ea4204fd7845257b6666fdade47cc2981/dsdt.dsl So the problem goes like this; we have a bunch of devices with _HID "INT3472" in those tables. Most of them have _STA=0, but 2 have _STA=15. I expect both of these devices (INT3472:08 and INT3472:09) to be created as platform_devices as well as acpi_devices by the kernel, however it turns out that only INT3472:09 gets a platform_device, :08 doesn't. The reason :08 gets no platform_device is that by the time acpi_create_platform_device() is ran for it, it's already gotten a physical_node. This comes from acpi_bind_one() binding the INT3472:08 acpi_device to a pci device named 0000:00:00.0 during acpi_device_notify(). The flow goes like this: acpi_device_notify(0000:00:00.0) -> acpi_pci_find_companion(0000:00:00.0) -> acpi_find_child_device(PNP0A08:00, 0, false) -> return INT3472:08 The jump to PNP0A08:00 there is acpi_find_companion() fetching the ACPI_COMPANION() for 0000:00:00.0's _parent_ device, named pci0000:00. This isn't behaviour that strikes me as particularly desirable. INT3472:08 is not an acpi device that seems to be a good candidate for binding to 0000:00:00.0; it just happens to be the first child of PNP0A08:08 that shares _ADR 0 and has _STA not set to 0. The comment within acpi_find_child_device() does imply that there should only ever be a single child device with the same _ADR as the parent, so I suppose this is possibly a case of poor ACPI tables confusing the code a bit; given both PNP0A08:00 and _all_ of the INT3472 devices have _ADR set to zero (as indeed do the machine's cameras), but I'm not knowledgeable enough on ACPI to know whether that's to spec (or at least accounted for). The INT3472 devices themselves do not actually seem to represent a physical device (atleast, not in this case...sometimes they do...), rather they're a dummy being used to simply group some GPIO lines under a common _CRS. The sensors are called out as dependent on these "devices" in their _DEP method, which is already a horrible way of doing things so more broken ACPI being to blame wouldn't surprise me. The other problem that that raises is that there seems to be _no_ good candidate for binding to 0000:00:00.0 that's a child of PNP0A08:00 - the only devices sharing _ADR 0 and having _STA != 0 are those two INT3472 entries and the machine's cameras. Any advice on how to go about rectifying this would be very much appreciated. Thanks Dan
