Hello again On 06/12/2020 00:00, Daniel Scally wrote: > 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. After some more reading, I'm pretty confident that this is the problem now - I.E. that those devices having _ADR of 0 is what's causing this issue to materialise, and that those values should be set to something more appropriate. Still unsure about the best approach to fix it though from a kernel point of view; there doesn't seem to be anything out of whack in the logic, and I believe (correct me if I'm wrong) there can be legitimate instances of child devices sharing _ADR=0 with the parent, so the problem becomes how to identify the illegitimate instances so that they can be discarded. My experience in this is really limited, so I lean towards the conclusion that hard-coding exceptions somewhere might be necessary to handle this without resorting to patched ACPI tables. Whether that's within acpi_find_child_device() to prevent matching occurring there, or else setting the adev->pnp.bus_address to some alternate value after creation to compensate. I recognise that that's a horrible answer though, so I'm really hoping that someone has an idea for how to handle this in a better way.
