From: Will Deacon <will@kernel.org>
To: Jeremy Linton <jeremy.linton@arm.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
Jon Masters <jcm@jonmasters.org>,
mark.rutland@arm.com, linux-pci@vger.kernel.org,
sudeep.holla@arm.com, linux-kernel@vger.kernel.org,
catalin.marinas@arm.com, bhelgaas@google.com,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] arm64: PCI: Enable SMC conduit
Date: Tue, 26 Jan 2021 22:54:54 +0000 [thread overview]
Message-ID: <20210126225454.GB30941@willie-the-truck> (raw)
In-Reply-To: <4c2db08d-ccc4-05eb-6b7b-5fd7d07dd11e@arm.com>
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
> > sense.
>
> 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.
> > Seriously.
>
> 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.
Ok.
> > 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.
> > > 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.
Will
next prev parent reply other threads:[~2021-01-27 12:27 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 [this message]
2021-01-28 18:50 ` Jeremy Linton
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
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210126225454.GB30941@willie-the-truck \
--to=will@kernel.org \
--cc=bhelgaas@google.com \
--cc=catalin.marinas@arm.com \
--cc=jcm@jonmasters.org \
--cc=jeremy.linton@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=mark.rutland@arm.com \
--cc=sudeep.holla@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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).