Hi Bjorn

-----Original Message-----
From: Bjorn Helgaas [mailto:helgaas at kernel.org]
Sent: 21 September 2016 19:59
To: Gabriele Paoloni
Cc: Ard Biesheuvel; Tomasz Nowicki; David Daney; Will Deacon; Catalin
Marinas; Rafael Wysocki; Lorenzo Pieralisi; Arnd Bergmann; Hanjun Guo;
Sinan Kaya; Jayachandran C; Christopher Covington; Duc Dang; Robert
Richter; Marcin Wojtas; Liviu Dudau; Wangyijing; Mark Salter; linux-
pci at vger.kernel.org; linux-arm-kernel at lists.infradead.org; Linaro ACPI
Mailman List; Jon Masters; Andrea Gallo; Jeremy Linton; liudongdong
(C); Jeff Hugo; linux-acpi at vger.kernel.org; linux-
kernel at vger.kernel.org; Rafael J. Wysocki
Subject: Re: [PATCH V6 3/5] PCI: thunder-pem: Allow to probe PEM-
specific register range for ACPI case

On Wed, Sep 21, 2016 at 02:10:55PM +0000, Gabriele Paoloni wrote:

quoted

Hi Bjorn

[...]

quoted

If future hardware is completely ECAM-compliant and we don't need

any

quoted

quoted

more MCFG quirks, that would be great.

But we'll still need to describe that memory-mapped config space
somewhere.  If that's done with PNP0C02 or similar devices (as is

done

quoted

quoted

on my x86 laptop), we'd be all set.

If we need to work around firmware in the field that doesn't do

that,

quoted

quoted

one possibility is a PNP quirk along the lines of
quirk_amd_mmconfig_area().

So, if my understanding is correct, for platforms that have not been
shipped yet you propose to use PNP0C02 in the ACPI table in order to
declare a motherboard reserved resource whereas for shipped platforms
you propose to have a quirk along pnp_fixups in order to track the
resource usage even if values are hardcoded...correct?

Yes.  I'm open to alternate proposals, but x86 uses PNP0C02, and
following existing practice seems reasonable.

quoted

Before Tomasz came up with this patchset we had a call between the

vendors

quoted

involved in this PCI quirks saga and other guys from Linaro and ARM.

Lorenzo summarized the outcome as in the following link
http://lkml.iu.edu/hypermail/linux/kernel/1606.2/03344.html

Since this quirks mechanism has been discussed for quite a long time

now

quoted

IMHO it would be good to have a last call including also you (Bjorn)

so

quoted

that we can all agree on what to do and we avoid changing our drivers

again

quoted

and again...

I think we're converging pretty fast.  As far as I'm concerned, the
v6 ECAM quirks implementation is perfect.  The only remaining issue is
reporting the ECAM resources, and I haven't seen objections to using
PNP0C02 + PNP quirks for broken firmware.

There is the question of how or whether to associate a PNP0A03 PCI
bridge with resources from a different PNP0C02 device, but that's not
super important.  If the hard-coded resources appear both in a quirk
and in the PCI bridge driver, it's ugly but not the end of the world.
We've still achieved the objective of avoiding landmines in the
address space.

Ok got it many thanks

Gab

Bjorn