Attention is currently required from: Cliff Huang, David Milosevic, Lance Zhao, Maximilian Brune, Naresh Solanki, Nico Huber, Patrick Rudolph.
Angel Pons has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/79096?usp=email )
Change subject: acpi: Enable 64bit ECAM resource ......................................................................
Patch Set 1:
(1 comment)
File src/acpi/dsdt_top.asl:
https://review.coreboot.org/c/coreboot/+/79096/comment/5c4688ff_cc22d526 : PS1, Line 64: ResourceProducer If you look at the ACPI spec, it *seems* to suggest that "Producer" is the right thing: https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/19_ASL_Reference/ACPI_Source_L...
ResourceUsage specifies whether the Memory range is consumed by this device (ResourceConsumer) or passed on to child devices (ResourceProducer). If nothing is specified, then ResourceConsumer is assumed.
But the Linux doc linked in the comment (https://www.kernel.org/doc/Documentation/PCI/acpi-info.rst) says the following:
ACPI defines a Consumer/Producer bit to distinguish the bridge registers
("Consumer") from the bridge apertures ("Producer") [4, 5], but early BIOSes didn't use that bit correctly. The result is that the current ACPI spec defines Consumer/Producer only for the Extended Address Space descriptors; the bit should be ignored in the older QWord/DWord/Word Address Space descriptors. Consequently, OSes have to assume all QWord/DWord/Word descriptors are windows.
Which suggests that this distinction is irrelevant, and:
PNP0C02 "motherboard" devices are basically a catch-all. There's no
programming model for them other than "don't use these resources for anything else." So a PNP0C02 _CRS should claim any address space that is (1) not claimed by _CRS under any other device object in the ACPI namespace and (2) should not be assigned by the OS to something else.
Which says this is just a catch-all in the form of a motherboard resource.
TL;DR I think ResourceConsumer may be more accurate.
-
Angel Pons (Code Review)