From: Jeremy Linton <firstname.lastname@example.org>
To: Will Deacon <email@example.com>
Cc: Lorenzo Pieralisi <firstname.lastname@example.org>,
Jon Masters <email@example.com>,
Subject: Re: [PATCH] arm64: PCI: Enable SMC conduit
Date: Thu, 28 Jan 2021 12:50:15 -0600 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
On 1/26/21 4:54 PM, Will Deacon wrote:
> On Tue, Jan 26, 2021 at 10:46:04AM -0600, Jeremy Linton wrote:
>> On 1/22/21 1:48 PM, Will Deacon wrote:
>>> This isn't like the usual fragmentation problems, where firmware swoops in
>>> to save the day; CPU onlining, spectre mitigations, early entropy etc. All
>>> of these problems exist because there isn't a standard method to implement
>>> them outside of firmware, and so adding a layer of abstraction there makes
>> There are a lot of parallels with PSCI here because there were existing
>> standards for cpu online.
> I don't recall anything that I would consider a standard at the time.
>>> But PCIe is already a standard!
>> And it says that ECAM is optional, particularly if there are
>> firmware/platform standardized ways of accessing the config space.
> Nice loophole; I haven't checked.
>>> We shouldn't paper over hardware designers' inability to follow a ~20 year
>>> old standard by hiding it behind another standard that is hot off the press.
>> No disagreement, but its been more than half a decade and there are some
>> high (millions!) volume parts, that still don't have kernel support.
>>> There is not a scrap of evidence to suggest that the firmware
>>> implementations will be any better, but they will certainly be harder to
>>> debug and maintain. I have significant reservations about Arm's interest in
>>> maintaining the spec as both more errata appear and the PCIe spec evolves
>>> (after all, this is outside of SBSA, no?). The whole thing stinks of "if all
>>> you have is a hammer, then everything looks like a nail". But this isn't the
>>> sort of problem that is solved with yet another spec -- instead, how about
>>> encouraging vendors to read the specs that already exist?
>> PSCI, isn't a good example of a firmware interface that works?
> Not sure what you're getting at here.
Simply, that PSCI is working fairly well today, and that hopefully this
specification will similarly mature.
Right now, there are at least three prongs for assuring compliance. The
TF-A core service is being written to assure parameter validation and
error checking is common across all the platforms. That code is
attempting to cover every case called out by the SMC/PCI spec. The
kernel is now utilizing the entire API service and cross validating the
ACPI/SMC bus values and function existence. Lastly, but most important,
there is the ACS PCI compliance suite*. That suite attempts to validate,
among other things, config space behavior. When run on top of the SMC
conduit, it provides assurance that root port registers/etc behave as
the PCIe standard dictates.
>>>> The SMC is an olive branch and just to make sure it is crystal clear
>>>> there won't be room for adding quirks if the implementation turns out
>>>> to be broken, if a line in the sand is what we want here it is.
>>> I appreciate the sentiment, but you're not solving the problem here. You're
>>> moving it somewhere else. Somewhere where you don't have to deal with it
>>> (and I honestly can't blame you for that), but also somewhere where you
>>> _can't_ necessarily deal with it. The inevitable outcome is an endless
>>> succession of crappy, non-compliant machines which only appear to operate
>>> correctly with particularly kernel/firmware combinations. Imagine trying to
>>> use something like that?
>>> The approach championed here actively discourages vendors from building
>>> spec-compliant hardware and reduces our ability to work around problems
>>> on such hardware at the same time.
>>> So I won't be applying these patches, sorry.
>> Does that mean its open season for ECAM quirks, and we can expect them to
>> start being merged now?
> That's not for me to say.
next prev parent reply other threads:[~2021-01-28 18:56 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
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 [this message]
2021-01-28 23:31 ` Bjorn Helgaas
[not found] ` <CACCGGCc3zULqHgUh3Q9wA5WtPBnQ4eq_v2+1qA8bOBCQZJ5YoQ@mail.gmail.com>
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] ` <CA+kK7ZijdNERQSauEvAffR7JLbfZ512na2-9cJrU0vFbNnDGwQ@mail.gmail.com>
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
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).