On 05.09.2016 04:25, Bjorn Helgaas wrote:
On Mon, Aug 08, 2016 at 03:05:39PM +0200, 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. Algorithm traverses available quirk list (static array),
matches against <oem_id, oem_table_id, rev, domain, bus number range> and
returns pci_config_window structure with fancy PCI config ops.
oem_id, oem_table_id and rev come from MCFG table standard header.
It is possible to define custom init call which is responsible for
setting up PCI configuration access accordingly to quirk requirements.
If custom init call is not defined, use standard pci_acpi_setup_ecam_mapping().
pci_generic_ecam_ops will be used for platforms free from quirks.
Signed-off-by: Tomasz Nowicki <tn@xxxxxxxxxxxx>
Signed-off-by: Dongdong Liu <liudongdong3@xxxxxxxxxx>
Signed-off-by: Christopher Covington <cov@xxxxxxxxxxxxxx>
---
drivers/pci/host/Makefile | 1 +
drivers/pci/host/mcfg-quirks.c | 86 ++++++++++++++++++++++++++++++++++++++++++
drivers/pci/host/mcfg-quirks.h | 20 ++++++++++
include/linux/pci-acpi.h | 2 +
4 files changed, 109 insertions(+)
create mode 100644 drivers/pci/host/mcfg-quirks.c
create mode 100644 drivers/pci/host/mcfg-quirks.h
If the object is to work around defects in the ACPI MCFG table, I
think I'd put the quirks closer to drivers/acpi/pci_mcfg.c, where we
parse that table. What if we actually put them directly *in*
drivers/acpi/pci_mcfg.c?
Then we need to export quirk init calls or ecam ops from
drivers/pci/host/* directory.
Currently we keep mcfg quirk handling code and related drivers in one
place drivers/pci/host/
Tomasz
--
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
