Re: [PATCH V6 3/5] PCI: thunder-pem: Allow to probe PEM-specific register range for ACPI case

From: Bjorn Helgaas <helgaas@kernel.org>
To: Gabriele Paoloni <gabriele.paoloni@huawei.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Rafael Wysocki <rafael@kernel.org>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	Will Deacon <will.deacon@arm.com>,
	Sinan Kaya <okaya@codeaurora.org>,
	Wangyijing <wangyijing@huawei.com>,
	Andrea Gallo <andrea.gallo@linaro.org>,
	Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>,
	Jeff Hugo <jhugo@codeaurora.org>,
	Tomasz Nowicki <tn@semihalf.com>,
	Linaro ACPI Mailman List <linaro-acpi@lists.linaro.org>,
	David Daney <ddaney@caviumnetworks.com>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	Robert Richter <robert.richter@caviumnetworks.com>,
	"liudongdong \(C\)" <liudongdong3@huawei.com>,
	Mark Salter <msalter@redhat.com>,
	Liviu Dudau <Liviu.Dudau@arm.com>, Arnd Bergmann <arnd@arndb.de>,
	Jon Masters <jcm@redhat.com>,
	Christopher Covington <cov@codeaurora.org>,
	Marcin Wojtas <mw@semihalf.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Jayachandran C <jchandra@broadcom.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Duc Dang <dhdang@apm.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Jeremy Linton <jeremy.linton@arm.com>,
	Hanjun Guo <hanjun.guo@linaro.org>
Subject: Re: [PATCH V6 3/5] PCI: thunder-pem: Allow to probe PEM-specific register range for ACPI case
Date: Wed, 21 Sep 2016 13:59:20 -0500	[thread overview]
Message-ID: <20160921185920.GC20006@localhost> (raw)
In-Reply-To: <EE11001F9E5DDD47B7634E2F8A612F2E1F87CF8F@lhreml507-mbx>

On Wed, Sep 21, 2016 at 02:10:55PM +0000, Gabriele Paoloni wrote:
> Hi Bjorn
> 
> [...]
> 
> 
> > 
> > If future hardware is completely ECAM-compliant and we don't need any
> > 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
> > on my x86 laptop), we'd be all set.
> > 
> > If we need to work around firmware in the field that doesn't do that,
> > 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.

> Before Tomasz came up with this patchset we had a call between the vendors
> 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
> IMHO it would be good to have a last call including also you (Bjorn) so
> that we can all agree on what to do and we avoid changing our drivers again
> 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.

Bjorn

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