Hi,
On 1/7/21 12:14 PM, Will Deacon wrote:
On Mon, Jan 04, 2021 at 10:57:35PM -0600, Jeremy Linton wrote:
Given that most arm64 platform's PCI implementations needs quirks
to deal with problematic config accesses, this is a good place to
apply a firmware abstraction. The ARM PCI SMMCCC spec details a
standard SMC conduit designed to provide a simple PCI config
accessor. This specification enhances the existing ACPI/PCI
abstraction and expects power, config, etc functionality is handled
by the platform. It also is very explicit that the resulting config
space registers must behave as is specified by the pci specification.
Lets hook the normal ACPI/PCI config path, and when we detect
missing MADT data, attempt to probe the SMC conduit. If the conduit
exists and responds for the requested segment number (provided by the
ACPI namespace) attach a custom pci_ecam_ops which redirects
all config read/write requests to the firmware.
This patch is based on the Arm PCI Config space access document @
https://developer.arm.com/documentation/den0115/latest
Why does firmware need to be involved with this at all? Can't we just
quirk Linux when these broken designs show up in production? We'll need
to modify Linux _anyway_ when the firmware interface isn't implemented
correctly...
IMHO, The short answer is that having the quirk in the firmware keeps it
centralized over multiple OSs and linux distro versions and avoids a lot
of costly kernel->distro churning to backport/maintain quirks over a
dozen distro versions.
There is also a long-term maintenance advantage since its hard for the
kernel community as a whole to have a good view of how long a
particular model of machine is actually in use. For example, today we
could ask are any of those xgene1's still in use and remove their
quirks, but no one really has a clear view.
As far as working around the firmware, that is of course potentially
problematic, but I think it is easier to say "fix the firmware if you
want/need linux support" than it is to get people to fix their ECAM
implementations. Hypothetically, if at some point there is a broken
version of this interface in firmware, the kernel could choose to bypass
it entirely and talk to whatever broken config space method the hardware
implements. At which point we aren't any worse off than the situation
today.
The flip side of this is that a fair number of these platforms have open
source firmware as well, so it may be trivial to fix the firmware.
Thanks for looking a this!
