On 12 June 2017 at 18:55, Lorenzo Pieralisi <lorenzo.pieralisi@xxxxxxx> wrote: > On Wed, Jun 07, 2017 at 01:45:19PM +0000, Ard Biesheuvel wrote: >> On 6 June 2017 at 10:02, Lorenzo Pieralisi <lorenzo.pieralisi@xxxxxxx> wrote: >> > On Tue, Jun 06, 2017 at 09:14:26AM +0000, Ard Biesheuvel wrote: >> > >> > [...] >> > >> >> > Do you want me to create a branch out of these patches (inclusive of >> >> > another patch to fix this bus reallocation policy discrepancy) for >> >> > ARM64 folks to test ? Let me know, thanks ! >> >> > >> >> >> >> Hi Lorenzo, >> >> >> >> Bjorn has already picked up #1, which is now in -next. I will get back >> >> to this topic today or tomorrow, so let me respin (including the bus >> >> range fix) first, ok? >> > >> > Of course, I just want to help you make progress on this, I think >> > we need help for testing them on ARM64 systems to see how to proceed. >> > >> >> OK, so I am hitting another issue. While it is quite simple to do this >> >> """ >> diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c >> index c7e3e6387a49..9a529c6369ac 100644 >> --- a/arch/arm64/kernel/pci.c >> +++ b/arch/arm64/kernel/pci.c >> @@ -203,6 +203,9 @@ >> return NULL; >> } >> >> + /* ignore bus ranges assigned by the firmware */ >> + pci_add_flags(PCI_REASSIGN_ALL_BUS); >> + >> root_ops->release_info = pci_acpi_generic_release_info; >> root_ops->prepare_resources = pci_acpi_root_prepare_resources; >> root_ops->pci_ops = &ri->cfg->ops->pci_ops; >> """ >> >> and get the ACPI code to behave in the same way as the DT code, >> including the resulting quirks, i.e. >> >> pci_bus 0000:01: busn_res: can not insert [bus 01-ff] under [bus >> 00-0f] (conflicts with (null) [bus 00-0f]) >> >> there are two problems when we want to refine this to take _DSM #5 into account. >> >> 1) PCI_REASSIGN_ALL_BUS is a global flag, while _DSM is per PCI root >> 2) setting the flag conditionally on whether _DSM #5 allows it is >> difficult to achieve, given that the flag needs to be set before >> acpi_pci_root_create(), at which point we cannot access the _DSM yet > > (2) Why ? You have the ACPI root bridge handle at that point. Anyway > (1) makes (2) irrelevant unfortunately. > OK, it wasn't clear to me that the companion device has already been created at that point. But it doesn't matter, indeed ... >> So I can send out the above as a separate patch, but right now, I am >> not entirely sure how to proceed with conditionally preserving the >> firmware configuration. > > Yes, this definitely requires some focus because that's becoming a bit > unwieldy to manage consistently, I will look into this. > OK. I would still like to fix the EFI framebuffer issue, but given that the current code is no longer unsafe, it is no longer a priority for me, so I will revisit it when we have a better handle on this.
