Hi Bjorn > -----Original Message----- > From: Bjorn Helgaas [mailto:helgaas@xxxxxxxxxx] > 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@xxxxxxxxxxxxxxx; linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; Linaro ACPI > Mailman List; Jon Masters; Andrea Gallo; Jeremy Linton; liudongdong > (C); Jeff Hugo; linux-acpi@xxxxxxxxxxxxxxx; linux- > kernel@xxxxxxxxxxxxxxx; 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: > > 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. Ok got it many thanks Gab > > Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
