ACPI / platform: Pay attention to parent device's resources
Given following simplified device hierarchy: // PCI device having BAR0 (RMEM) split between 4 GPIO devices. Device (P2S) { Name (_ADR, 0x000d0000) Device (GPO0) { Name (_HID, "INT3452") Name (_UID, 1) Name (_CRS, ResourceTemplate () { Memory32Fixed (ReadWrite, 0, 0x4000, RMEM + 0x0000) }) } Device (GPO1) { Name (_HID, "INT3452") Name (_UID, 2) Name (_CRS, ResourceTemplate () { Memory32Fixed (ReadWrite, 0, 0x4000, RMEM + 0x4000) }) } Device (GPO2) { Name (_HID, "INT3452") Name (_UID, 3) Name (_CRS, ResourceTemplate () { Memory32Fixed (ReadWrite, 0, 0x4000, RMEM + 0x8000) }) } Device (GPO3) { Name (_HID, "INT3452") Name (_UID, 4) Name (_CRS, ResourceTemplate () { Memory32Fixed (ReadWrite, 0, 0x4000, RMEM + 0xc000) }) } } The current ACPI platform enumeration code allocates resources from the global MMIO resource pool (/proc/iomem) for all the four GPIO devices. After this PCI core calls pcibios_resource_survey() to allocate resources for all PCI devices including the parent device for these GPIO devices (P2S). Since that resource range has already been reserved the allocation fails. The reason for this is that we never bother with parent device's resources when ACPI platform devices are created. Fix this by checking whether there is a parent device and in that case make sure we assign correct parent resource to the resources for the child ACPI platform device. Currently we only deal with parent devices if they are PCI devices but we may expand this later to cover other bus types as well. Reported-by: Aaron Durbin <adurbin@google.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Showing
Please register or sign in to comment