Re: [PATCH V6 0/5] ECAM quirks handling for ARM64 platforms

From: cov
Date: Tue Sep 20 2016 - 21:15:25 EST

Hi Bjorn, Thomasz,

On 2016-09-20 15:26, Bjorn Helgaas wrote:
On Fri, Sep 09, 2016 at 09:24:02PM +0200, Tomasz Nowicki wrote:
Quirk handling relies on an idea of simple static array which contains
quirk enties. Each entry consists of identification information (IDs from
standard header of MCFG table) along with custom pci_ecam_ops structure and
configuration space resource structure. This way it is possible find
corresponding quirk entries and override pci_ecam_ops and PCI configuration
space regions.

As an example, the last 3 patches present quirk handling mechanism usage for

v5 -> v6
- rebase against v4.8-rc5
- drop patch 1 form previous series
- keep pci_acpi_setup_ecam_mapping() in ARM64 arch directory
- move quirk code to pci_mcfg.c
- restrict quirk to override pci_ecam_ops and CFG resource structure
only, no init call any more
- split ThunderX quirks into the smaller chunks
- add ThunderX pass1.x silicon revision support

v4 -> v5
- rebase against v4.8-rc1
- rework to exact MCFG OEM ID, TABLE ID, rev match
- use memcmp instead of strncmp
- no substring match
- fix typos and dmesg message

Tomasz Nowicki (5):
PCI/ACPI: Extend pci_mcfg_lookup() responsibilities
PCI/ACPI: Check platform specific ECAM quirks
PCI: thunder-pem: Allow to probe PEM-specific register range for ACPI
PCI: thunder: Enable ACPI PCI controller for ThunderX pass2.x silicon
PCI: thunder: Enable ACPI PCI controller for ThunderX pass1.x silicon

arch/arm64/kernel/pci.c | 17 ++--
drivers/acpi/pci_mcfg.c | 168 +++++++++++++++++++++++++++++++++++-
drivers/pci/host/pci-thunder-ecam.c | 2 +-
drivers/pci/host/pci-thunder-pem.c | 63 +++++++++++---
include/linux/pci-acpi.h | 4 +-
include/linux/pci-ecam.h | 7 ++
6 files changed, 230 insertions(+), 31 deletions(-)

I'm not quite ready to merge these because we haven't resolved the
question of how to expose the resources used by the memory-mapped
config space. I'm fine with the first two patches (I did make a
couple trivial changes, see below), but there's no point in merging
them until we merge a user for them.

I pushed the series to pci/ecam-v6 for build testing and discussion.
The diff (the changes I made locally) from v6 as posted by Tomasz is

Rebasing the following simple quirks framework user onto this branch,
I have some questions.

diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
index eb14f74..bb3b8ad 100644
--- a/drivers/acpi/pci_mcfg.c
+++ b/drivers/acpi/pci_mcfg.c
@@ -42,86 +42,59 @@ struct mcfg_fixup {
struct resource cfgres;

-#define MCFG_DOM_ANY (-1)

Did you delete this because there were no current users, because you'd
prefer users just use "-1", or for some other reason?

#define MCFG_BUS_RANGE(start, end) DEFINE_RES_NAMED((start), \
((end) - (start) + 1), \
-#define MCFG_BUS_ANY MCFG_BUS_RANGE(0x0, 0xff)
+#define MCFG_BUS_ANY MCFG_BUS_RANGE(0x0, 0xff)

static struct mcfg_fixup mcfg_quirks[] = {
-/* { OEM_ID, OEM_TABLE_ID, REV, DOMAIN, BUS_RANGE, cfgres, ops }, */
+/* { OEM_ID, OEM_TABLE_ID, REV, SEGMENT, BUS_RANGE, cfgres, ops }, */

This comment appears to have the order of cfgres and ops reversed.

Am I correct in reading that if a user of the framework does not wish to
override cfgres they must place a struct resource with .start = 0 at the
end of their mcfg_quirks entry? If so, I guess I have the same questions
about removing MCFG_RES_EMPTY as I do about removing MCFG_DOM_ANY.