[RFC PATCH V5 3/5] PCI: Check platform specific ECAM quirks
Tomasz Nowicki
tn at semihalf.com
Tue Sep 6 10:49:49 PDT 2016
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 at semihalf.com>
>> Signed-off-by: Dongdong Liu <liudongdong3 at huawei.com>
>> Signed-off-by: Christopher Covington <cov at codeaurora.org>
>> ---
>> 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
More information about the linux-arm-kernel
mailing list