archive mirror
 help / color / mirror / Atom feed
From: Jon Masters <>
To: Will Deacon <>, Jeremy Linton <>
Subject: Re: [PATCH] arm64: PCI: Enable SMC conduit
Date: Thu, 7 Jan 2021 16:05:48 -0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <20210107181416.GA3536@willie-the-truck>

Hi will, everyone,

On 1/7/21 1: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 @
> 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...

I agree with Will on this. I think we want to find a way to address some 
of the non-compliance concerns through quirks in Linux. However...

Several folks here (particularly Lorenzo) have diligently worked hard 
over the past few years - and pushed their patience - to accommodate 
hardware vendors with early "not quite compliant" systems. They've taken 
lots of quirks that frankly shouldn't continue to be necessary were it 
even remotely a priority in the vendor ecosystem to get a handle on 
addressing PCIe compliance once and for all. But, again frankly, it 
hasn't been enough of a priority to get this fixed. The third party IP 
vendors *need* to address this, and their customers *need* to push back.

We can't keep having a situation in which kinda-sorta compliant stuff 
comes to market that would work out of the box but for whatever the 
quirk is this time around. There have been multiple OS releases for the 
past quite a few years on which this stuff could be tested prior to ever 
taping out a chip, and so it ought not to be possible to come to market 
now with an excuse that it wasn't tested. And yet here we still are. All 
these years and still the message isn't quite being received properly. I 
do know it takes time to make hardware, and some of it was designed 
years before and is still trickling down into these threads. But I also 
think there are cases where much more could have been done earlier.

None of these vendors can possibly want this deep down. Their engineers 
almost certainly realize that just having compliant ECAM would mean that 
the hardware was infinitely more valuable being able to run out of the 
box software that much more easily. And it's not just ECAM. Inevitably, 
that is just the observable syndrome for worse issues, often with the 
ITS and forcing quirked systems to have lousy legacy interrupts, etc. 
Alas, this level of nuance is likely lost by the time it reaches upper 
management, where "Linux" is all the same to them. I would hope that can 
change. I would also remind them that if they want to run non-Linux 
OSes, they will also want to be actually compliant. The willingness of 
kind folks like Lorenzo and others here to entertain quirks is not 
necessarily something you will find in every part of the industry.

But that all said, we have a situation in which there are still 
platforms out there that aren't fully compliant and something has to be 
done to support them because otherwise it's going to be even more ugly 
with vendor trees, distro hacks, and other stuff.

Some of you in recent weeks have asked what I and others can do to help 
from the distro and standardization side of things. To do my part, I'm 
going to commit to reach out to assorted vendors and have a heart to 
heart with them about really, truly fully addressing their compliance 
issues. That includes Cadence, Synopsys, and others who need to stop 
shipping IP that requires quirks, as well as SoC vendors who need to do 
more to test their silicon with stock kernels prior to taping out. And I 
would like to involve the good folks here who are trying to navigate.

I would also politely suggest that we collectively consider how much 
wiggle room there can be to use quirks for what we are stuck with rather 
than an SMC-based solution. We all know that quirks can't be a free ride 
forever. Those who need them should offer something strong in return. A 
firm commitment that they will never come asking for the same stuff in 
the future. Is there a way we can do something like that?


Computer Architect

  parent reply	other threads:[~2021-01-07 21:06 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-05  4:57 [PATCH] arm64: PCI: Enable SMC conduit Jeremy Linton
2021-01-07 15:28 ` Rob Herring
2021-01-07 16:23   ` Jeremy Linton
2021-01-07 17:36     ` Rob Herring
2021-01-07 19:45       ` Jeremy Linton
2021-01-07 20:35         ` Rob Herring
2021-01-07 18:14 ` Will Deacon
2021-01-07 19:18   ` Jeremy Linton
2021-01-07 21:05   ` Jon Masters [this message]
2021-01-07 21:49     ` Rob Herring
2021-01-08 10:32     ` Lorenzo Pieralisi
2021-01-22 19:48       ` Will Deacon
2021-01-26 16:46         ` Jeremy Linton
2021-01-26 22:54           ` Will Deacon
2021-01-28 18:50             ` Jeremy Linton
2021-01-28 23:31           ` Bjorn Helgaas
     [not found]             ` <>
2021-02-25  9:30               ` Lorenzo Pieralisi
2021-02-25 22:31                 ` Jeremy Linton
2021-01-26 17:08         ` Vikram Sethi
2021-01-26 22:53           ` Will Deacon
2021-03-25 13:12             ` Lorenzo Pieralisi
2021-03-25 20:45               ` Marcin Wojtas
2021-03-25 21:12                 ` Jon Masters
2021-03-26  9:27                   ` Marcin Wojtas
2021-06-16 17:36               ` Jason Gunthorpe
     [not found]                 ` <>
2021-06-18 14:05                   ` Jason Gunthorpe
2021-06-19 16:34                     ` Jon Masters
2021-06-19 16:38                       ` Jon Masters
2021-06-20  0:26                       ` Jason Gunthorpe
2021-06-18 15:10               ` Jeremy Linton
2021-01-12 16:16 ` Vidya Sagar
2021-01-12 16:57   ` Jeremy Linton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).