From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
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>,
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.infradead.org>,
"linaro-acpi@lists.linaro.org" <linaro-acpi@lists.linaro.org>,
Jon Masters <jcm@redhat.com>,
Andrea Gallo <andrea.gallo@linaro.org>,
Jeremy Linton <jeremy.linton@arm.com>,
Dongdong Liu <liudongdong3@huawei.com>,
Gabriele Paoloni <gabriele.paoloni@huawei.com>,
Jeff Hugo <jhugo@codeaurora.org>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCHv2] PCI: QDF2432 32 bit config space accessors
Date: Thu, 10 Nov 2016 13:57:33 +0000 [thread overview]
Message-ID: <20161110135733.GA20403@red-moon> (raw)
In-Reply-To: <CAKv+Gu9_sdcoN7rjQp-R=2vKY3rECt0BC3eWGpse32o2Q4LHXg@mail.gmail.com>
On Thu, Nov 10, 2016 at 06:25:16PM +0800, Ard Biesheuvel wrote:
> On 10 November 2016 at 06:49, Bjorn Helgaas <helgaas@kernel.org> wrote:
> > 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.
> >
>
> I think I misunderstood the purpose of the example: that should only
> be necessary if the _CRS methods are missing from the firmware, right?
> If we update the firmware to cover all non-enumerable resources by
> such a method, we shouldn't need any such quirks at all IIUC
Yes that's correct you need a quirk to fabricate a PNP0c02 motherboard
resource if it is not present in FW.
Lorenzo
next prev parent reply other threads:[~2016-11-10 13:57 UTC|newest]
Thread overview: 82+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-09 19:24 [PATCH V6 0/5] ECAM quirks handling for ARM64 platforms Tomasz Nowicki
2016-09-09 19:24 ` [PATCH V6 1/5] PCI/ACPI: Extend pci_mcfg_lookup() responsibilities Tomasz Nowicki
2016-09-09 19:24 ` [PATCH V6 2/5] PCI/ACPI: Check platform specific ECAM quirks Tomasz Nowicki
2016-09-12 22:24 ` Duc Dang
2016-09-12 22:47 ` Duc Dang
2016-09-13 5:58 ` Tomasz Nowicki
2016-09-13 6:37 ` Tomasz Nowicki
2016-09-13 2:36 ` Dongdong Liu
2016-09-13 6:32 ` Tomasz Nowicki
2016-09-13 11:38 ` Dongdong Liu
2016-09-14 12:40 ` Lorenzo Pieralisi
2016-09-15 10:58 ` Lorenzo Pieralisi
2016-09-16 9:02 ` Gabriele Paoloni
2016-09-16 12:27 ` Christopher Covington
2016-09-16 13:42 ` Gabriele Paoloni
2016-09-09 19:24 ` [PATCH V6 3/5] PCI: thunder-pem: Allow to probe PEM-specific register range for ACPI case Tomasz Nowicki
2016-09-19 18:09 ` Bjorn Helgaas
2016-09-20 7:23 ` Tomasz Nowicki
2016-09-20 13:33 ` Bjorn Helgaas
2016-09-20 13:40 ` Ard Biesheuvel
2016-09-20 14:05 ` Bjorn Helgaas
2016-09-20 15:09 ` Ard Biesheuvel
2016-09-20 19:17 ` Bjorn Helgaas
2016-09-21 14:05 ` Lorenzo Pieralisi
2016-09-21 18:04 ` Bjorn Helgaas
2016-09-21 18:58 ` Duc Dang
2016-09-21 19:18 ` Bjorn Helgaas
2016-09-23 10:53 ` Tomasz Nowicki
2016-09-22 9:49 ` Lorenzo Pieralisi
2016-09-22 11:10 ` Gabriele Paoloni
2016-09-22 12:44 ` Lorenzo Pieralisi
2016-09-22 18:31 ` Bjorn Helgaas
2016-09-22 22:10 ` Bjorn Helgaas
2016-09-23 10:11 ` Lorenzo Pieralisi
2016-09-23 10:58 ` Gabriele Paoloni
2017-09-14 14:06 ` Ard Biesheuvel
2017-09-26 8:23 ` Gabriele Paoloni
2016-09-22 14:20 ` Christopher Covington
2016-09-21 14:10 ` Gabriele Paoloni
2016-09-21 18:59 ` Bjorn Helgaas
2016-09-22 11:12 ` Gabriele Paoloni
2016-09-09 19:24 ` [PATCH V6 4/5] PCI: thunder: Enable ACPI PCI controller for ThunderX pass2.x silicon version Tomasz Nowicki
2016-09-19 15:45 ` Bjorn Helgaas
2016-09-20 7:06 ` Tomasz Nowicki
2016-09-20 13:08 ` Bjorn Helgaas
2016-09-21 8:05 ` Tomasz Nowicki
2016-09-09 19:24 ` [PATCH V6 5/5] PCI: thunder: Enable ACPI PCI controller for ThunderX pass1.x " Tomasz Nowicki
2016-09-09 19:30 ` [PATCH V6 0/5] ECAM quirks handling for ARM64 platforms Tomasz Nowicki
2016-09-20 19:26 ` Bjorn Helgaas
2016-09-21 1:15 ` cov
2016-09-21 13:11 ` Bjorn Helgaas
2016-09-21 14:07 ` Sinan Kaya
2016-09-21 17:31 ` Bjorn Helgaas
2016-09-21 17:34 ` Sinan Kaya
2016-09-21 22:38 ` [PATCHv2] PCI: QDF2432 32 bit config space accessors Christopher Covington
2016-10-31 21:48 ` Bjorn Helgaas
2016-11-01 13:06 ` cov
2016-11-02 16:08 ` Bjorn Helgaas
2016-11-02 16:36 ` Sinan Kaya
2016-11-03 14:00 ` Bjorn Helgaas
2016-11-03 16:58 ` Sinan Kaya
2016-11-03 17:06 ` Sinan Kaya
2016-11-03 20:43 ` Bjorn Helgaas
2016-11-03 23:49 ` Sinan Kaya
2016-12-02 4:58 ` Jon Masters
2016-11-02 16:41 ` Bjorn Helgaas
2016-11-09 19:25 ` Christopher Covington
2016-11-09 20:06 ` Bjorn Helgaas
2016-11-09 20:29 ` Ard Biesheuvel
2016-11-09 22:49 ` Bjorn Helgaas
2016-11-10 10:25 ` Ard Biesheuvel
2016-11-10 13:57 ` Lorenzo Pieralisi [this message]
2016-11-10 17:42 ` Bjorn Helgaas
2016-12-02 5:12 ` Jon Masters
2016-09-21 22:40 ` [PATCH V6 0/5] ECAM quirks handling for ARM64 platforms Christopher Covington
2016-09-22 23:08 ` Bjorn Helgaas
2016-09-23 18:41 ` Christopher Covington
2016-09-23 19:17 ` Bjorn Helgaas
2016-09-23 19:22 ` Christopher Covington
2016-09-28 16:44 ` Christopher Covington
2016-11-24 11:05 ` [PATCH V6 1/1] ARM64/PCI: Manage controller-specific information on the host controller basis Tomasz Nowicki
2016-11-29 23:40 ` Bjorn Helgaas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161110135733.GA20403@red-moon \
--to=lorenzo.pieralisi@arm.com \
--cc=Liviu.Dudau@arm.com \
--cc=andrea.gallo@linaro.org \
--cc=ard.biesheuvel@linaro.org \
--cc=arnd@arndb.de \
--cc=catalin.marinas@arm.com \
--cc=cov@codeaurora.org \
--cc=ddaney@caviumnetworks.com \
--cc=dhdang@apm.com \
--cc=gabriele.paoloni@huawei.com \
--cc=hanjun.guo@linaro.org \
--cc=helgaas@kernel.org \
--cc=jchandra@broadcom.com \
--cc=jcm@redhat.com \
--cc=jeremy.linton@arm.com \
--cc=jhugo@codeaurora.org \
--cc=linaro-acpi@lists.linaro.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=liudongdong3@huawei.com \
--cc=msalter@redhat.com \
--cc=mw@semihalf.com \
--cc=okaya@codeaurora.org \
--cc=rafael@kernel.org \
--cc=robert.richter@caviumnetworks.com \
--cc=tn@semihalf.com \
--cc=wangyijing@huawei.com \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).