On Friday, September 27th, 2024 at 1:23 AM, Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote: > CC lists. > > On Wed, Sep 25, 2024 at 8:36 PM Accardi, Kristen C > kristen.c.accardi@xxxxxxxxx wrote: > > > On Wed, 2024-09-25 at 17:52 +0000, Athul Krishna wrote: > > > > > Device: Asus Zephyrus G14 GA402RJ > > > Kernel: 6.11 > > > CPU: R7 67800H > > > GPU: RX 6700S > > > > > > Hello Kristen, > > > > > > I'd like provide feedback on the acpiphp module. My laptop is all > > > AMD(CPU+GPU). So the discrete gpu: \SB.PCI0.GPP0.SWUS.SWDS.VGA_, > > > and the hotplug bridge: \SB.PCI0.GPP0. And there's two PCI-PCI > > > bridges: SWUS and SWDS. > > > > > > Eject notification on the discrete GPU, will remove the GPU, and the > > > two PCI bridges. > > > > > > The issue I've encountered is, Device check notification cannot reach > > > GPU, as it's hotplug context is lost, with the current implementation > > > of acpiphp(acpiphp_glue.c) module. > > > > > > I hope this helps. Also a small disclaimer: I'm a newbie to Linux > > > kernel internals. So I might be limited in the help I can provide. > > > I can provide dmesg logs or ACPI tables if required. > > > > > > Thanks & Regards, > > > Athul > > > > Hi Athul, > > I think that Rafael might be maintaining this driver these days. I've > > copied him on this reply. > > > I don't maintain it (Bjorn does that AFAICS), but I may be one of the > developers who have touched it most recently. > > In any case, I don't think it is at fault here, but firmware > expectations that go beyond provisions made by the ACPI specification: > > https://uefi.org/specs/ACPI/6.5/05_ACPI_Software_Programming_Model.html#device-object-notifications > > because it seems to really want to trigger a bus rescan starting from > a device that has been discovered already that will lead to a > discovery of a specific "new" device along with its parent. Sending a > device check notification on a device that has not been discovered yet > and whose parent has not been discovered yet either may reasonably be > regarded as unsuitable for this purpose. > > That said, it appears to be possible to adjust the generic ACPI device > notification handling code to take this firmware behavior into account > kind of as expected. That is, if a device check notification is > received on a device object without a hotplug context, look for its > closest ancestor that has a hotplug context or otherwise can handle > hotplug and trigger a bus check from it as though it got a bus check > notification. > > Please check the attached (completely untested) patch. Hello Rafael, I've patched the kernel and tested it. In the dmesg log, you can see: [ 77.467946] ACPI: \_SB_.PCI0.GPP0.SWUS: Bus check in hotplug_event() bridge: 0 I've modified the debug message to: acpi_handle_debug(handle, "Bus check in %s() bridge: %d\n", __func__, bridge ? true : false); It seems acpi hotplug context exists for bridge \_SB_.PCI0.GPP0.SWUS. But acpiphp_bridge for the context is NULL. I do see when free_bridge() is called, context->bridge = NULL. Thanks, Athul
Attachment:
dmesg
Description: Binary data
