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
ThunderX.
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
case
PCI: thunder: Enable ACPI PCI controller for ThunderX pass2.x
silicon
version
PCI: thunder: Enable ACPI PCI controller for ThunderX pass1.x
silicon
version
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
below.
Rebasing the following simple quirks framework user onto this branch,
I have some questions.
https://source.codeaurora.org/quic/server/kernel/commit/?h=cov/4.8-rc2-testing&id=83b766cafef11c107b10177d0626db311f382299
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), \
NULL, IORESOURCE_BUS)
-#define MCFG_BUS_ANY MCFG_BUS_RANGE(0x0, 0xff)
-#define MCFG_RES_EMPTY DEFINE_RES_NAMED(0, 0, NULL, 0)
+#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.
Thanks,
Cov
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
