> 2024年12月5日 18:54，Rafael J. Wysocki <rafael@xxxxxxxxxx> 写道： > >> >> Maybe we can prioritize the initialization of the PCI host bridge to >> fully eliminate this issue? > > The problem with this is that the current code requires struct > acpi_device objects to be present for all PCI devices that have > corresponding objects in the ACPI Namespace at the time when the host > bridge is initialized because that causes the PCI bus to be scanned > for devices and struct acpi_device objects are looked up from there. > > To make this work, the "ACPI companion lookup" code needs to be > changed and that would be kind of a heavy lifting and it may introduce > some unexpected enumeration ordering issues. > > Alternatively, the PCI host bridge could be initialized early, but > without scanning the PCI bus which would be scanned at the time when > all of the struct acpi_device objects are present. It looks like this > could be made work, but it would require some investigation and code > refactoring. Thanks again for your explanation on this. I understand that it may need lots of work. I think it would be better if the fix would become as minor as possible, because it would be easier to backport and more importantly, the case where legacy IO device is used on non-x86 ACPI-enabled architectures is really rare. I'm currently running out of better ideas, due to my limited experience on this part of code. I suppose maybe we can scan the ACPI device tree in three passes, adding one in the beginning to pick out the PCI Host. But we should deal with the case where evaluating the _CRS of the PCI Host itself requires reading IO ports, since it seems that the specification does not forbid this... If you are familiar with someone in the UEFI forum, maybe this problem can be raised to them and a clarification can be requested. Cheers, Miao Wang
