On Tue, Jan 26, 2021 at 10:46:04AM -0600, Jeremy Linton wrote:

On 1/22/21 1:48 PM, Will Deacon wrote:

quoted

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.

quoted

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.

quoted

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.

quoted

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.

quoted

quoted

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel