On 28 March 2017 at 22:49, Sinan Kaya [off-list ref] wrote:

On 3/28/2017 5:39 PM, Ard Biesheuvel wrote:

quoted

On 28 March 2017 at 22:27, Sinan Kaya [off-list ref] wrote:

quoted

Hi Lorenzo,

On 3/23/2017 6:57 AM, Lorenzo Pieralisi wrote:

quoted

quoted

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.