Hi Ard, Jon

-----Original Message-----
From: Ard Biesheuvel [mailto:ard.biesheuvel at linaro.org]
Sent: 20 May 2016 08:38
To: Jon Masters
Cc: Tomasz Nowicki; Gabriele Paoloni; helgaas at kernel.org; arnd at arndb.de;
will.deacon at arm.com; catalin.marinas at arm.com; rafael at kernel.org;
hanjun.guo at linaro.org; Lorenzo.Pieralisi at arm.com; okaya at codeaurora.org;
jchandra at broadcom.com; linaro-acpi at lists.linaro.org; linux-
pci at vger.kernel.org; dhdang at apm.com; Liviu.Dudau at arm.com;
ddaney at caviumnetworks.com; jeremy.linton at arm.com; linux-
kernel at vger.kernel.org; linux-acpi at vger.kernel.org;
robert.richter at caviumnetworks.com; Suravee.Suthikulpanit at amd.com;
msalter at redhat.com; Wangyijing; mw at semihalf.com;
andrea.gallo at linaro.org; linux-arm-kernel at lists.infradead.org
Subject: Re: [PATCH V7 00/11] Support for generic ACPI based PCI host
controller

On 20 May 2016 at 06:41, Jon Masters [off-list ref] wrote:

quoted

Hi Tomasz, all,

On 05/11/2016 07:08 AM, Tomasz Nowicki wrote:

quoted

On 11.05.2016 12:41, Gabriele Paoloni wrote:

quoted

quoted

quoted

v6 -> v7
- drop quirks handling

Maybe I missed something in the v6 discussion thread; when was it
decided to drop quirk handling?

I had such requests in previous series.

A quick note on quirk handling. This, I believe, applies post-merge

of

quoted

the base infrastructure, which I realize will likely not have quirks.

We've some "gen1" ARMv8 server platforms where we end up doing quirks
(for things like forcing 32-bit config space accessors and the like)

due

quoted

to people repurposing existing embedded PCIe IP blocks or using them

for

quoted

the first time (especially in servers), and those being involved in

the

quoted

design not necessarily seeing this problem ahead of time, or not
realizing that it would be an issue for servers. In the early days of
ARM server designs 3-4 years ago, many of us had never really played
with ECAM or realized how modern topologies are built.

Anyway. We missed this one in our SBSA requirements. They say (words

to

quoted

the effect of) "thou shalt do PCIe the way it is done on servers" but
they aren't prescriptive, and they don't tell people how that

actually

quoted

is in reality. That is being fixed. A lot of things are happening

behind

quoted

the scenes - especially with third party IP block providers (all of

whom

quoted

myself and others are speaking with directly about this) - to ensure
that the next wave of designs won't repeat these mistakes. We don't

have

quoted

a time machine, but we can contain this from becoming an ongoing mess
for upstream, and we will do so. It won't be a zoo.

Various proposals have arisen for how to handle quirks in the longer
term, including elaborate frameworks and tables to describe them
generically. I would like to caution against such approaches,

especially

quoted

in the case that they deviate from practice on x86, or prior to being
standardized fully with other Operating System vendors. I don't

expect

quoted

there to be too many more than the existing initial set of quirks we
have seen posted. A number of "future" server SoCs have already been
fixed prior to silicon, and new design starts are being warned not to
make this a problem for us to have to clean up later.

So, I would like to suggest that the eventual framework mirror the
existing approach on x86 systems (matching DMI, etc.) and not be made
into some kind of generic, utopia. This is a case where we want there

to

quoted

be pain involved (and upstream patches required) when people screw up,
so that they have a level of pain in response to ever making this
mistake in the future. If we try to create too grand a generic scheme
and make it too easy to handle this kind of situation beyond the

small

quoted

number of existing offenders, we undermine efforts to force vendors

to

quoted

ensure that their IP blocks are compliant going forward.

I understand that there is a desire from the RedHat side to mimic x86
as closely as possible, but I never saw any technical justification
for that. DMI contains strings that are visible to userland, and you
effectively lock those down to certain values just so that the kernel
can distinguish a broken PCIe root complex from a working one. Linux
on x86 had no choice, since the overwhelming majority of existing
hardware misrepresented itself as generic, and DMI was the only thing
available to actually distinguish these broken implementations from
one another. This does not mean we should allow and/or encourage this
first gen hardware to misrepresent non-compliant hardware as compliant
as well.

Since you are talking to all the people involved, how about you
convince them to put something in the ACPI tables that allows the
kernel to distinguish those non-standard PCIe implementations from
hardware that is really generic? This way, we can sidestep the quirks
debate entirely, since it will simply be a different device as far as
the kernel is concerned. This is no worse than a quirk from a
practical point of view, since an older OS will be equally unable to
run on newer hardware, but it is arguably more true to the standards
compliance you tend to preach about, especially since this small pool
of third party IP could potentially be identified directly rather than
based on some divination of the SoC we may or may not be running on. I
am also convinced that adding support for an additional HID() to the
ACPI ECAM driver with some special config space handling wired in is
an easier sell upstream than making the same ugly mess x86 has had to
make because they did not have any choice to begin with.

In our case (HiSilicon Hip05/Hip06) we are using the Designware IP
that unfortunately is non-ECAM for the RC config space.

A possible ACPI table solution was discussed already in this thread

https://lkml.org/lkml/2016/3/14/722

where <<Name (_CID, "PNP0C02")  // Motherboard reserved resource>>
is used to specify an Host Controller specific resource.
It looks to me that this can be an approach that can accommodate
different vendors/scenarios and Bjorn seemed to be quite ok with
it.

It comes without saying that for future HW releases we all should
make an effort to deliver fully ECAM compliant controllers.

What's your view about this approach?

Thanks

Gab

If we do need a quirks handling mechanism, I still don't see how the
x86 situation extrapolates to ARM. ACPI offers plenty of ways for a
SoC vendor to identify the make and particular revision, and quirks
could be keyed off of that.

--
Ard.