From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Return-Path: Date: Wed, 21 Sep 2016 13:59:20 -0500 From: Bjorn Helgaas To: Gabriele Paoloni Subject: Re: [PATCH V6 3/5] PCI: thunder-pem: Allow to probe PEM-specific register range for ACPI case Message-ID: <20160921185920.GC20006@localhost> References: <1473449047-10499-1-git-send-email-tn@semihalf.com> <1473449047-10499-4-git-send-email-tn@semihalf.com> <20160919180900.GB13775@localhost> <49f53bfc-4421-a8b0-694c-bce7e61e1c9e@semihalf.com> <20160920133327.GB13855@localhost> <20160920140518.GD13855@localhost> <20160920191744.GA4941@localhost> MIME-Version: 1.0 In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Catalin Marinas , Rafael Wysocki , "linux-pci@vger.kernel.org" , Will Deacon , Sinan Kaya , Wangyijing , Andrea Gallo , Lorenzo Pieralisi , Jeff Hugo , Tomasz Nowicki , Linaro ACPI Mailman List , David Daney , "linux-acpi@vger.kernel.org" , Robert Richter , "liudongdong \(C\)" , Mark Salter , Liviu Dudau , Arnd Bergmann , Jon Masters , Christopher Covington , Marcin Wojtas , "linux-arm-kernel@lists.infradead.org" , Jayachandran C , Ard Biesheuvel , Duc Dang , "Rafael J. Wysocki" , "linux-kernel@vger.kernel.org" , Jeremy Linton , Hanjun Guo Content-Type: text/plain; charset="us-ascii" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+bjorn=helgaas.com@lists.infradead.org List-ID: 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