On 28 March 2017 at 22:27, Sinan Kaya <okaya@xxxxxxxxxxxxxx> wrote: > Hi Lorenzo, > > On 3/23/2017 6:57 AM, Lorenzo Pieralisi wrote: >>> Correct. But on x86 (or rather, on a PC), you can be sure that UEFI >>> (or the legacy PCI bios) performed the resource assignment already. >>> One could argue that this is equally the case when running arm64 in >>> ACPI mode, but in general, you cannot assume the presence of firmware >>> on ARM/arm64 that has already taken care of this, and so the state of >>> the BARs has to be presumed invalid. >> The story is a bit more convoluted than that owing to x86 (and other >> arches) legacy. >> >> x86 tries to claim all PCI resources (in two passes - first enabled >> devices, second disabled devices) and that predates ACPI/UEFI. >> >> Mind, x86 reassign resources that can't be claimed too, the only >> difference with ARM64 is that, for the better or the worse, we >> have decided not to claim the FW PCI set-up on ARM64 even if it >> is sane, we do not even try, it was a deliberate choice. >> >> This patch should be harmless on x86 since if the FB PCI BAR is set >> up sanely, claiming it again should be a nop (to be checked). >> >> For all the talk about PCI being arch agnostic as I said manifold >> times before, that's just theory. In practice different arches >> treat PCI FW set-up differently, it would be ideal to make them >> uniform but legacy is huge and there is a massive risk of triggering >> regressions, it is no mean feat (if achievable at all). > > Can we explore having a uniform behavior across ALL ACPI bases systems > by trying to reuse the resources assigned by firmware first and reassign > them only if something is wrong? > > There are protocols like hotplug reservation in UEFI. It looks like Linux > is not honoring any of these protocols by being too smart. > Could you be more specific? Which protocol do you mean exactly, and how does not reusing resources interfere with it? -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
