From: msalter@redhat.com (Mark Salter)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors against platfrom specific quirks.
Date: Fri, 08 Jan 2016 11:07:16 -0500 [thread overview]
Message-ID: <1452269236.31901.46.camel@redhat.com> (raw)
In-Reply-To: <20160108151216.GJ3097@leverpostej>
On Fri, 2016-01-08 at 15:12 +0000, Mark Rutland wrote:
> On Fri, Jan 08, 2016 at 03:01:37PM +0000, Mark Rutland wrote:
> > On Fri, Jan 08, 2016 at 09:16:21AM -0500, Mark Salter wrote:
> > > On Wed, 2015-12-16 at 16:16 +0100, Tomasz Nowicki wrote:
> > > > Some platforms may not be fully compliant with generic set of PCI config
> > > > accessors. For these cases we implement the way to overwrite accessors
> > > > set before PCI buses enumeration. Algorithm that overwrite accessors
> > > > matches against platform ID (DMI), domain and bus number, hopefully
> > > > enough for all cases. All quirks can be defined using:
> > > > DECLARE_ACPI_MCFG_FIXUP() and keep self contained.
> > > >
> > > > example:
> > > >
> > > > static const struct dmi_system_id yyy[] = {
> > > > ????????{
> > > > ????????????????.ident = "<Platform ident string>",
> > > > ????????????????.callback = <handler>,
> > > > ????????????????.matches = {
> > > > ????????????????????????DMI_MATCH(DMI_SYS_VENDOR, "<system vendor>"),
> > > > ????????????????????????DMI_MATCH(DMI_PRODUCT_NAME, "<product name>"),
> > > > ????????????????????????DMI_MATCH(DMI_PRODUCT_VERSION, "product version"),
> > > > ????????????????},
> > > > ????????},
> > > > ????????{ }
> > > > };
> > > >
> > >
> > > This seems awkward to me in the case where the quirk is SoC-based and there
> > > may be multiple platforms affected. Needing a DECLARE_ACPI_MCFG_FIXUP for
> > > each platform using such a SoC (i.e. Mustang and Moonshot) doesn't seem
> > > right. In that case, I think it'd be better to check CPUID and possibly
> > > some SoC register to cover all platforms affected.
> >
> > CPUs get reused across SoCs, so as you've implicitly noted, the CPUID
> > alone is insufficient.
> >
> > Given that IP blocks get moved around between SoC variants, I don't
> > think you can check "some SoC register" based on the CPU ID -- you can
> > end up bringing the board down at that point.
> >
> > If the CPU ID alone is insufficient to tell you about a component, it
> > cannot give you enough information about a component you can use to
> > query more information from.
> >
> > If your platform requires a quirk, it's always going to be painful (and
> > to some extent, rightfulyl so). We should aim for correctness here with
> > explicit matching.
>
> Further, if there is going to be an ever-expanding set of platforms
> requring quirks, then we need a standard mechanism in ACPI to enable the
> platform to tell us explicitly either which specific PCI implementation
> is used, or which common quirk is necessary.
>
No, an ever-expanding set is exactly what we don't want. I think you've convinced
me that I'm taking a wrong view of the problem. Putting something in the ACPI
standard would be going too far and I think a hard sell to the standards folk.
There really is no foolproof way to match a plug and play ACPI PCIe root to
specific hardware without considering the exact platform and/or BIOS info. So
yeah, it should be painful in order to give incentive to the silicon vendors to
get it right.
next prev parent reply other threads:[~2016-01-08 16:07 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-16 15:16 [PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI Tomasz Nowicki
2015-12-16 15:16 ` [PATCH V2 01/23] x86, pci: Reorder logic of pci_mmconfig_insert() function Tomasz Nowicki
2015-12-16 15:16 ` [PATCH V2 02/23] x86, pci, acpi: Move arch-agnostic MMCONFIG (aka ECAM) and ACPI code out of arch/x86/ directory Tomasz Nowicki
2015-12-16 15:16 ` [PATCH V2 03/23] pci, acpi, mcfg: Provide generic implementation of MCFG code initialization Tomasz Nowicki
2015-12-16 15:16 ` [PATCH V2 04/23] x86, pci: mmconfig_{32, 64}.c code refactoring - remove code duplication Tomasz Nowicki
2015-12-16 15:16 ` [PATCH V2 05/23] x86, pci, ecam: mmconfig_64.c becomes default implementation for ECAM driver Tomasz Nowicki
2015-12-16 15:16 ` [PATCH V2 06/23] XEN / PCI: Remove the dependence on arch x86 when PCI_MMCONFIG=y Tomasz Nowicki
2015-12-17 10:25 ` Tomasz Nowicki
2015-12-17 10:40 ` Tomasz Nowicki
2015-12-21 18:12 ` Stefano Stabellini
2015-12-22 8:34 ` Tomasz Nowicki
2015-12-16 15:16 ` [PATCH V2 07/23] pci, acpi, mcfg: Provide default RAW ACPI PCI config space accessors Tomasz Nowicki
2015-12-16 15:16 ` [PATCH V2 08/23] arm64, acpi: Use empty PCI config space accessors from mcfg.c file Tomasz Nowicki
2015-12-16 15:16 ` [PATCH V2 09/23] pci, acpi, ecam: Add flag to indicate whether ECAM region was hot added or not Tomasz Nowicki
2015-12-16 15:16 ` [PATCH V2 10/23] x86, pci: Cleanup platform specific MCFG data using previously added ECAM hot_added flag Tomasz Nowicki
2015-12-16 15:16 ` [PATCH V2 11/23] arm64, pci: Remove useless boot time IRQ assignment when booting with DT Tomasz Nowicki
2016-01-12 13:50 ` Lorenzo Pieralisi
2016-01-12 16:13 ` Tomasz Nowicki
2016-01-12 17:56 ` David Daney
2016-01-13 9:43 ` Tomasz Nowicki
2015-12-16 15:16 ` [PATCH V2 12/23] pci, acpi: Move ACPI host bridge device companion assignment to core code Tomasz Nowicki
2015-12-16 15:16 ` [PATCH V2 13/23] x86, ia64, pci: Remove ACPI companion device from platform specific data Tomasz Nowicki
2015-12-16 15:16 ` [PATCH V2 14/23] pci, acpi: Provide generic way to assign bus domain number Tomasz Nowicki
2015-12-16 15:16 ` [PATCH V2 15/23] x86, ia64, pci: Convert arches to use PCI_DOMAINS_GENERIC Tomasz Nowicki
2015-12-16 15:16 ` [PATCH V2 16/23] x86, ia64: Include acpi_pci_{add|remove}_bus to the default pcibios_{add|remove}_bus implementation Tomasz Nowicki
2015-12-16 15:16 ` [PATCH V2 17/23] acpi, mcfg: Implement two calls that might be used to inject/remove MCFG region Tomasz Nowicki
2015-12-16 15:16 ` [PATCH V2 18/23] x86, acpi, pci: Use equivalent function introduced in previous patch Tomasz Nowicki
2015-12-16 15:16 ` [PATCH V2 19/23] acpi, mcfg: Add default PCI config accessors implementation and initial support for related quirks Tomasz Nowicki
2015-12-16 15:16 ` [PATCH V2 20/23] ACPI, PCI: Refine the way to handle translation_offset for ACPI resources Tomasz Nowicki
2015-12-16 15:16 ` [PATCH V2 21/23] pci, acpi: Support for ACPI based PCI hostbridge init Tomasz Nowicki
2015-12-18 12:40 ` Arnd Bergmann
2015-12-21 10:21 ` Tomasz Nowicki
2015-12-16 15:16 ` [PATCH V2 22/23] pci, acpi: Match PCI config space accessors against platfrom specific quirks Tomasz Nowicki
2015-12-21 11:47 ` Gabriele Paoloni
2015-12-21 14:10 ` Arnd Bergmann
2015-12-21 17:29 ` David Daney
2015-12-21 22:42 ` Arnd Bergmann
2015-12-21 23:24 ` Jon Masters
2015-12-21 23:10 ` Jon Masters
2015-12-22 8:45 ` Tomasz Nowicki
2015-12-22 9:29 ` Gabriele Paoloni
2015-12-22 16:36 ` Jon Masters
2015-12-22 16:45 ` Jon Masters
2015-12-22 17:49 ` Gabriele Paoloni
2015-12-22 10:20 ` Tomasz Nowicki
2015-12-22 14:48 ` Gabriele Paoloni
2015-12-23 9:38 ` Hanjun Guo
2016-01-08 14:16 ` Mark Salter
2016-01-08 14:36 ` Tomasz Nowicki
2016-01-08 14:51 ` Mark Salter
2016-01-08 14:42 ` Jeremy Linton
2016-01-08 15:01 ` Mark Rutland
2016-01-08 15:12 ` Mark Rutland
2016-01-08 16:07 ` Mark Salter [this message]
2015-12-16 15:16 ` [PATCH V2 23/23] arm64, pci, acpi: Start using ACPI based PCI host bridge driver for ARM64 Tomasz Nowicki
2015-12-17 21:24 ` [PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI Sinan Kaya
2015-12-18 12:26 ` Tomasz Nowicki
2015-12-18 18:56 ` okaya at codeaurora.org
2015-12-21 10:37 ` Tomasz Nowicki
2015-12-21 12:10 ` Lorenzo Pieralisi
2015-12-21 12:42 ` Tomasz Nowicki
2015-12-21 14:15 ` Arnd Bergmann
2015-12-21 15:26 ` Okaya at codeaurora.org
2015-12-21 22:39 ` Arnd Bergmann
2016-01-11 15:39 ` Lorenzo Pieralisi
2016-01-11 15:56 ` Sinan Kaya
2016-01-12 14:30 ` Arnd Bergmann
2016-01-12 18:38 ` Lorenzo Pieralisi
2016-01-12 21:37 ` Arnd Bergmann
2016-01-11 16:09 ` Lorenzo Pieralisi
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=1452269236.31901.46.camel@redhat.com \
--to=msalter@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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).