On 28 March 2017 at 22:49, Sinan Kaya <okaya@xxxxxxxxxxxxxx> wrote: > On 3/28/2017 5:39 PM, Ard Biesheuvel wrote: >> 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? >> > > Let's assume for the moment that if ARM64 adaptation of PCIE reused the firmware > assigned BAR addresses, would you still have this problem that you are trying to > fix by a quirk? > Probably not. Although I should point out that the same issue exists on DT systems, and so we will need this patch regardless. > The protocol that I was looking at specifically is called hotplug reservation > protocol. > > http://www.intel.com/content/www/us/en/architecture-and-technology/unified-extensible-firmware-interface/efi-hot-plug-pci-initialization-protocol-specification.html > > The idea is to pad the PCIe bridge window by some amount in UEFI. You boot the > system without any cards present. when you do to hotplug, OS uses the range > reserved by the BIOS for inserting the new card. > > what I see is that the bridge windows get overridden by the OS. > > I'm asking why we don't fix the actual problem in PCIe ARM64 adaptation instead > of working around it by quirks. > > I don't see any reason why ACPI ARM64 should carry the burden of legacy systems. > > Legacy only applies to DT based systems. > I fully agree with this point: ACPI implies firmware, and so we should be able to rely on firmware to have initialized the PCIe subsystem by the time the kernel gets to access it. > If there is still a legacy problem in ACPI ARM64, generic Linux code deals with > this using some DMI/SMBIOS and setting a time bomb like products after this date > shall follow the new behavior. > > We are not in a very hardened position when it comes to changes for ACPI based > systems. > > Sinan > > -- > Sinan Kaya > Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. > Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. -- 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
