Re: [PATCHv2] PCI: QDF2432 32 bit config space accessors

From: Bjorn Helgaas <helgaas@kernel.org>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Christopher Covington <cov@codeaurora.org>,
	Sinan Kaya <okaya@codeaurora.org>,
	Tomasz Nowicki <tn@semihalf.com>,
	Will Deacon <will.deacon@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>,
	Arnd Bergmann <arnd@arndb.de>, Hanjun Guo <hanjun.guo@linaro.org>,
	Jayachandran C <jchandra@broadcom.com>, Duc Dang <dhdang@apm.com>,
	Robert Richter <robert.richter@caviumnetworks.com>,
	Marcin Wojtas <mw@semihalf.com>,
	Liviu Dudau <Liviu.Dudau@arm.com>,
	David Daney <ddaney@caviumnetworks.com>,
	"wangyijing@huawei.com" <wangyijing@huawei.com>,
	Mark Salter <msalter@redhat.com>,
	linux-pci@vger.kernel.org,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infr>
Subject: Re: [PATCHv2] PCI: QDF2432 32 bit config space accessors
Date: Wed, 9 Nov 2016 16:49:55 -0600	[thread overview]
Message-ID: <20161109224955.GO14322@bhelgaas-glaptop.roam.corp.google.com> (raw)
In-Reply-To: <CAKv+Gu82+5oHMeSvcOL1VG4vw-kVnhq4LjCRtLMw4Nmn0rK2CA@mail.gmail.com>

On Wed, Nov 09, 2016 at 08:29:23PM +0000, Ard Biesheuvel wrote:
> Hi Bjorn,
> 
> On 9 November 2016 at 20:06, Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Wed, Nov 09, 2016 at 02:25:56PM -0500, Christopher Covington wrote:
> >> Hi Bjorn,
> >>
> [...]
> >>
> >> We're working to add the PNP0C02 resource to future firmware, but it's
> >> not in the current firmware. Are dmesg and /proc/iomem from the
> >> current firmware interesting or should we wait for the update to file?
> >
> > Note that the ECAM space is not the only thing that should be
> > described via these PNP0C02 devices.  *All* non-enumerable resources
> > should be described by the _CRS method of some ACPI device.  Here's a
> > sample from my laptop:
> >
> >   PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem 0xf8000000-0xfbffffff] (base 0xf8000000)
> >   system 00:01: [io  0x1800-0x189f] could not be reserved
> >   system 00:01: [io  0x0800-0x087f] has been reserved
> >   system 00:01: [io  0x0880-0x08ff] has been reserved
> >   system 00:01: [io  0x0900-0x097f] has been reserved
> >   system 00:01: [io  0x0980-0x09ff] has been reserved
> >   system 00:01: [io  0x0a00-0x0a7f] has been reserved
> >   system 00:01: [io  0x0a80-0x0aff] has been reserved
> >   system 00:01: [io  0x0b00-0x0b7f] has been reserved
> >   system 00:01: [io  0x0b80-0x0bff] has been reserved
> >   system 00:01: [io  0x15e0-0x15ef] has been reserved
> >   system 00:01: [io  0x1600-0x167f] has been reserved
> >   system 00:01: [io  0x1640-0x165f] has been reserved
> >   system 00:01: [mem 0xf8000000-0xfbffffff] could not be reserved
> >   system 00:01: [mem 0xfed10000-0xfed13fff] has been reserved
> >   system 00:01: [mem 0xfed18000-0xfed18fff] has been reserved
> >   system 00:01: [mem 0xfed19000-0xfed19fff] has been reserved
> >   system 00:01: [mem 0xfeb00000-0xfebfffff] has been reserved
> >   system 00:01: [mem 0xfed20000-0xfed3ffff] has been reserved
> >   system 00:01: [mem 0xfed90000-0xfed93fff] has been reserved
> >   system 00:01: [mem 0xf7fe0000-0xf7ffffff] has been reserved
> >   system 00:01: Plug and Play ACPI device, IDs PNP0c02 (active)
> >
> > Do you have firmware in the field that may not get updated?  If so,
> > I'd like to see the whole solution for that firmware, including the
> > MCFG quirk (which tells the PCI core where the ECAM region is) and
> > whatever PNP0C02 quirk you figure out to actually reserve the region.
> >
> > I proposed a PNP0C02 quirk to Duc along these lines of the below.  I
> > don't actually know if it's feasible, but it didn't look as bad as I
> > expected, so I'd kind of like somebody to try it out.  I think you
> > would have to call this via a DMI hook (do you have DMI on arm64?),
> > maybe from pnp_init() or similar.
> 
> We do have SMBIOS/DMI on arm64, but we have been successful so far not
> to rely on it for quirks, and we'd very much like to keep it that way.
> 
> Since this ACPI _CRS method has nothing to do with SMBIOS/DMI, surely
> there is a better way to wire up the reservation code to the
> information exposed by ACPI?

I'm open to other ways, feel free to propose one :)

If you do a quirk, you need some way to identify the machine/firmware
combination, because you don't want to apply the quirk on every
machine.  You're trying to work around a firmware issue, so you
probably want something tied to the firmware version.  On x86, that's
typically done with DMI.

Bjorn