Message ID | 4FDB2192.5070709@huawei.com |
---|---|
State | Changes Requested |
Headers | show |
On Fri, Jun 15, 2012 at 4:50 AM, Jiang Liu <jiang.liu@huawei.com> wrote: > Hi Yinghai, > A formal patch to fix "here cache cfg too early. should do > that after pci_mmcfg_reject_broken()". This patch also improves > readability and fixes two condition compilation issues reported by > Fengguang. If you are ok with it, I will fold it into > "[PATCH v7 08/10] PCI, x86: add MMCFG information on demand". > Thanks! > Gerry > > --- > diff --git a/arch/x86/include/asm/pci_x86.h b/arch/x86/include/asm/pci_x86.h > index 7eae174..5eb2ac9 100644 > --- a/arch/x86/include/asm/pci_x86.h > +++ b/arch/x86/include/asm/pci_x86.h > @@ -142,7 +142,7 @@ extern int __devinit pci_mmconfig_insert(struct device *dev, > u16 seg, u8 start, u8 end, > phys_addr_t addr); > extern int pci_mmconfig_delete(u16 seg, u8 start, u8 end); > -#ifdef CONFIG_ACPI > +#if defined(CONFIG_ACPI) && defined(CONFIG_PCI_MMCONFIG) > extern void pci_mmconfig_probe(u8 start); > #else > static inline void pci_mmconfig_probe(u8 start) { } > diff --git a/arch/x86/pci/mmconfig-shared.c b/arch/x86/pci/mmconfig-shared.c > index 20ab4f5..636de35 100644 > --- a/arch/x86/pci/mmconfig-shared.c > +++ b/arch/x86/pci/mmconfig-shared.c > @@ -636,13 +636,6 @@ static int __init pci_parse_mcfg(struct acpi_table_header *header) > } > } > > - i = entries * sizeof(*cfg_table); > - pci_acpi_mcfg_array = kmalloc(i, GFP_KERNEL); > - if (pci_acpi_mcfg_array) { > - memcpy(pci_acpi_mcfg_array, cfg_table, i); > - pci_acpi_mcfg_entries = entries; > - } > - > return 0; > } > > @@ -699,8 +692,11 @@ out: > * Free all MCFG entries if ACPI is enabled. MCFG information will > * be added back on demand by the pci_root driver later. > */ > - if (!early && !acpi_disabled && !known_bridge && pci_acpi_mcfg_array) > - free_all_mmcfg(); > + if (!early && !acpi_disabled && !known_bridge && > + !pci_mmcfg_arch_init_failed) { > + if (!acpi_pci_cache_mcfg()) > + free_all_mmcfg(); > + } > } > > void __init pci_mmcfg_early_init(void) > diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c > index f5d2157..93e0f91 100644 > --- a/drivers/pci/pci-acpi.c > +++ b/drivers/pci/pci-acpi.c > @@ -163,8 +163,34 @@ acpi_status pci_acpi_remove_pm_notifier(struct acpi_device *dev) > } > > /* acpi_table_parse() is marked as __init, so cache MCFG info at boot time */ > -int pci_acpi_mcfg_entries; > -struct acpi_mcfg_allocation *pci_acpi_mcfg_array; > +static int pci_acpi_mcfg_entries; > +static struct acpi_mcfg_allocation *pci_acpi_mcfg_array; > + > +static int __init pci_cache_mcfg(struct acpi_table_header *header) > +{ > + u32 sz; > + void *ptr; > + > + if (!header || (header->length <= sizeof(struct acpi_table_mcfg))) > + return -EINVAL; > + > + sz = (header->length - sizeof(struct acpi_table_mcfg)); > + pci_acpi_mcfg_array = kmalloc(sz, GFP_KERNEL); > + if (!pci_acpi_mcfg_array) > + return -ENOMEM; > + > + ptr = (void *)header + sizeof(struct acpi_table_mcfg); > + memcpy(pci_acpi_mcfg_array, ptr, sz); > + pci_acpi_mcfg_entries = sz / sizeof (struct acpi_mcfg_allocation); > + > + return 0; > +} > + > +int __init acpi_pci_cache_mcfg(void) > +{ > + acpi_table_parse(ACPI_SIG_MCFG, pci_cache_mcfg); > + return pci_acpi_mcfg_array ? 0 : -EINVAL; > +} still have some problem: pci_mmcfg_check_reserved==>is_mmconf_reserved will update cfg->end_bus. Thanks Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 2012-6-16 0:51, Yinghai Lu wrote: > > still have some problem: > pci_mmcfg_check_reserved==>is_mmconf_reserved > > will update cfg->end_bus. Hi Yinghai, How about following patch for this issue? I guess we need to keep current behavior at boot time for backward compatibility, right? --- @@ -472,6 +472,14 @@ static int __devinit is_mmconf_reserved(check_reserved_t is_reserved, break; } + /* + * For backward compatibility, we will adjust the MMCONFIG region + * at boot time if it's only partially reserved by firmware. + * For PCI host bridge hotplug at runtime, just reject it. + */ + if (pci_mmcfg_running_state && old_size != size) + return 0; + if (size < (16UL<<20) && size != old_size) return 0; --- > > Thanks > > Yinghai > > . > -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Jun 16, 2012 at 2:23 AM, Jiang Liu <jiang.liu@huawei.com> wrote: > On 2012-6-16 0:51, Yinghai Lu wrote: >> >> still have some problem: >> pci_mmcfg_check_reserved==>is_mmconf_reserved >> >> will update cfg->end_bus. > Hi Yinghai, > How about following patch for this issue? I guess we need to > keep current behavior at boot time for backward compatibility, right? We'd better to make all path share as most code as possible. 1. hostbridge scanning during boot -- early, it will check chipset and e820 2. MCFG checking during boot -- early, it will check e820 3. MCFG checking during boot -- late, it will check acpi pnp 4. _CBA checking for hotplug-able pci root bus but it is installed during boot. 5. _CBA checking for hotplug-able pci root bus during run time. please keep mapping for all entries in MCFG table. aka 1, 2, 3. I have some local patches that will read ext pci conf space before scan pci bus. please check attached one for nehalem-ioh. for case 4, 5: only need to add one bool in acpi_pci_root to record if mmconf list and mapping is touched. Thanks Yinghai
On Sat, Jun 16, 2012 at 2:08 PM, Yinghai Lu <yinghai@kernel.org> wrote: > On Sat, Jun 16, 2012 at 2:23 AM, Jiang Liu <jiang.liu@huawei.com> wrote: >> On 2012-6-16 0:51, Yinghai Lu wrote: >>> >>> still have some problem: >>> pci_mmcfg_check_reserved==>is_mmconf_reserved >>> >>> will update cfg->end_bus. >> Hi Yinghai, >> How about following patch for this issue? I guess we need to >> keep current behavior at boot time for backward compatibility, right? > > We'd better to make all path share as most code as possible. > 1. hostbridge scanning during boot -- early, it will check chipset and e820 > 2. MCFG checking during boot -- early, it will check e820 > 3. MCFG checking during boot -- late, it will check acpi pnp > 4. _CBA checking for hotplug-able pci root bus but it is installed during boot. > 5. _CBA checking for hotplug-able pci root bus during run time. > > please keep mapping for all entries in MCFG table. aka 1, 2, 3. > I have some local patches that will read ext pci conf space before scan pci bus. > please check attached one for nehalem-ioh. I don't think it's a requirement that Gerry keep your Nehalem patch working. Your intel_bus.c is not in the tree and you haven't provided an explanation for why it should be. The only requirement I'm aware of for PCI config access before we discover the host bridges via ACPI is for segment group 0, bus 0, as mentioned in ACPI spec 5.0, sec 5.2.3.1, PDF page 143, and I think that applies only to the first 0x100 bytes of config space. I don't think there's a requirement for access to the extended configuration space (bytes 0x100-0xFFF). I do not see a requirement that this pre-host bridge access happen via MMCONFIG; as far as I can tell, we can use the legacy 0xCF8/0xCFC mechanism. > for case 4, 5: only need to add one bool in acpi_pci_root to record if > mmconf list and mapping is touched. > > Thanks > > Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Jun 16, 2012 at 2:48 PM, Bjorn Helgaas <bhelgaas@google.com> wrote: >> >> We'd better to make all path share as most code as possible. >> 1. hostbridge scanning during boot -- early, it will check chipset and e820 >> 2. MCFG checking during boot -- early, it will check e820 >> 3. MCFG checking during boot -- late, it will check acpi pnp >> 4. _CBA checking for hotplug-able pci root bus but it is installed during boot. >> 5. _CBA checking for hotplug-able pci root bus during run time. >> >> please keep mapping for all entries in MCFG table. aka 1, 2, 3. >> I have some local patches that will read ext pci conf space before scan pci bus. >> please check attached one for nehalem-ioh. > > I don't think it's a requirement that Gerry keep your Nehalem patch > working. Your intel_bus.c is not in the tree and you haven't provided > an explanation for why it should be. > > The only requirement I'm aware of for PCI config access before we > discover the host bridges via ACPI is for segment group 0, bus 0, as > mentioned in ACPI spec 5.0, sec 5.2.3.1, PDF page 143, and I think > that applies only to the first 0x100 bytes of config space. I don't > think there's a requirement for access to the extended configuration > space (bytes 0x100-0xFFF). I do not see a requirement that this > pre-host bridge access happen via MMCONFIG; as far as I can tell, we > can use the legacy 0xCF8/0xCFC mechanism. that one shot for intel host bridge resource discovery before root bus scanning, will need to access registers above 0x100. Current MCFG handling have some sanitary checking during probing. Now Jiang is trying to free result and cache it for two MCFG path 2/3. and later use cached and map again for entries from cached entries. but when use those cached entries sanitary of those entries are lost. so choice would be 1. cache all checked MMCFG result and use that later 2. or just leave current MCFG handling alone, just add _CBA support. like Jiang -v4 version. Thanks Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Jun 16, 2012 at 3:44 PM, Yinghai Lu <yinghai@kernel.org> wrote: > Current MCFG handling have some sanitary checking during probing. > > Now Jiang is trying to free result and cache it for two MCFG path 2/3. > and later use cached and map again for entries from cached entries. > but when use those cached entries sanitary of those entries are lost. > > so choice would be > 1. cache all checked MMCFG result and use that later > 2. or just leave current MCFG handling alone, just add _CBA support. > like Jiang -v4 version. > I have used updated jiang's -v4 version for a while. Yinghai
On Sat, Jun 16, 2012 at 4:44 PM, Yinghai Lu <yinghai@kernel.org> wrote: > On Sat, Jun 16, 2012 at 2:48 PM, Bjorn Helgaas <bhelgaas@google.com> wrote: >>> >>> We'd better to make all path share as most code as possible. >>> 1. hostbridge scanning during boot -- early, it will check chipset and e820 >>> 2. MCFG checking during boot -- early, it will check e820 >>> 3. MCFG checking during boot -- late, it will check acpi pnp >>> 4. _CBA checking for hotplug-able pci root bus but it is installed during boot. >>> 5. _CBA checking for hotplug-able pci root bus during run time. >>> >>> please keep mapping for all entries in MCFG table. aka 1, 2, 3. >>> I have some local patches that will read ext pci conf space before scan pci bus. >>> please check attached one for nehalem-ioh. >> >> I don't think it's a requirement that Gerry keep your Nehalem patch >> working. Your intel_bus.c is not in the tree and you haven't provided >> an explanation for why it should be. >> >> The only requirement I'm aware of for PCI config access before we >> discover the host bridges via ACPI is for segment group 0, bus 0, as >> mentioned in ACPI spec 5.0, sec 5.2.3.1, PDF page 143, and I think >> that applies only to the first 0x100 bytes of config space. I don't >> think there's a requirement for access to the extended configuration >> space (bytes 0x100-0xFFF). I do not see a requirement that this >> pre-host bridge access happen via MMCONFIG; as far as I can tell, we >> can use the legacy 0xCF8/0xCFC mechanism. > > that one shot for intel host bridge resource discovery before root bus > scanning, > will need to access registers above 0x100. I don't understand what you're saying. Are you disagreeing with something I said above? As far as I know, we can rely on ACPI _CRS completely for host bridge resources. Are there exceptions? What does "one shot for intel host bridge resource discovery" mean? Are there machines that are broken because we don't have intel_bus.c? > Current MCFG handling have some sanitary checking during probing. > > Now Jiang is trying to free result and cache it for two MCFG path 2/3. > and later use cached and map again for entries from cached entries. > but when use those cached entries sanitary of those entries are lost. > > so choice would be > 1. cache all checked MMCFG result and use that later > 2. or just leave current MCFG handling alone, just add _CBA support. > like Jiang -v4 version. Choice 2 sounds like a possibility. I probably encouraged mucking around in the current MCFG handling, but if we're not going to actually clean anything up, there's not much point in touching it. -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 2012-6-17 9:55, Bjorn Helgaas wrote: > On Sat, Jun 16, 2012 at 4:44 PM, Yinghai Lu <yinghai@kernel.org> wrote: >> On Sat, Jun 16, 2012 at 2:48 PM, Bjorn Helgaas <bhelgaas@google.com> wrote: >>>> >>>> We'd better to make all path share as most code as possible. >>>> 1. hostbridge scanning during boot -- early, it will check chipset and e820 >>>> 2. MCFG checking during boot -- early, it will check e820 >>>> 3. MCFG checking during boot -- late, it will check acpi pnp >>>> 4. _CBA checking for hotplug-able pci root bus but it is installed during boot. >>>> 5. _CBA checking for hotplug-able pci root bus during run time. >>>> >>>> please keep mapping for all entries in MCFG table. aka 1, 2, 3. >>>> I have some local patches that will read ext pci conf space before scan pci bus. >>>> please check attached one for nehalem-ioh. >>> >>> I don't think it's a requirement that Gerry keep your Nehalem patch >>> working. Your intel_bus.c is not in the tree and you haven't provided >>> an explanation for why it should be. >>> >>> The only requirement I'm aware of for PCI config access before we >>> discover the host bridges via ACPI is for segment group 0, bus 0, as >>> mentioned in ACPI spec 5.0, sec 5.2.3.1, PDF page 143, and I think >>> that applies only to the first 0x100 bytes of config space. I don't >>> think there's a requirement for access to the extended configuration >>> space (bytes 0x100-0xFFF). I do not see a requirement that this >>> pre-host bridge access happen via MMCONFIG; as far as I can tell, we >>> can use the legacy 0xCF8/0xCFC mechanism. >> >> that one shot for intel host bridge resource discovery before root bus >> scanning, >> will need to access registers above 0x100. > > I don't understand what you're saying. Are you disagreeing with > something I said above? > > As far as I know, we can rely on ACPI _CRS completely for host bridge > resources. Are there exceptions? What does "one shot for intel host > bridge resource discovery" mean? Are there machines that are broken > because we don't have intel_bus.c? I have consulted Bob Moore about this topic before and Bob said that they hasn't encountered a system on which the ACPICA has dependency on extended PCI configuration space yet. >> Current MCFG handling have some sanitary checking during probing. >> >> Now Jiang is trying to free result and cache it for two MCFG path 2/3. >> and later use cached and map again for entries from cached entries. >> but when use those cached entries sanitary of those entries are lost. >> >> so choice would be >> 1. cache all checked MMCFG result and use that later >> 2. or just leave current MCFG handling alone, just add _CBA support. >> like Jiang -v4 version. > > Choice 2 sounds like a possibility. I probably encouraged mucking > around in the current MCFG handling, but if we're not going to > actually clean anything up, there's not much point in touching it. I prefer the second choice too. Backward compatibility is really important on x86, so don't want to break anything here. I could help to split the patch set into two parts: one for root bridge hotplug and the other for cleanup. This time we could focus on the first patch to prepare for host bridge hotplug, and have more time to discuss about the cleanup work. On the other hand, BIOS should report MMCONFIG information by _CBA if a host bridge supports physical hotplug. So the cleanup only benefits two cases: 1) BIOS reports MMCONFIG information for hot-pluggable host bridges in MCFG table. This is really a BIOS bug. Currently we have no really x86 platforms in the field which support PCI host bridge hotplug yet. So it may be acceptable for OS to report such bugs and let BIOS people to fix them. 2) Account MMCONFIG information to specific host bridges. It does give better representation about the MMCONFIG resource usages, but it's on risk of breaking backward compatibilities. So should we adopt the second solution here? Thanks! Gerry -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Jun 17, 2012 at 7:21 PM, Jiang Liu <jiang.liu@huawei.com> wrote: > On 2012-6-17 9:55, Bjorn Helgaas wrote: >> On Sat, Jun 16, 2012 at 4:44 PM, Yinghai Lu <yinghai@kernel.org> wrote: >>> On Sat, Jun 16, 2012 at 2:48 PM, Bjorn Helgaas <bhelgaas@google.com> wrote: >>>>> >>>>> We'd better to make all path share as most code as possible. >>>>> 1. hostbridge scanning during boot -- early, it will check chipset and e820 >>>>> 2. MCFG checking during boot -- early, it will check e820 >>>>> 3. MCFG checking during boot -- late, it will check acpi pnp >>>>> 4. _CBA checking for hotplug-able pci root bus but it is installed during boot. >>>>> 5. _CBA checking for hotplug-able pci root bus during run time. >>>>> >>>>> please keep mapping for all entries in MCFG table. aka 1, 2, 3. >>>>> I have some local patches that will read ext pci conf space before scan pci bus. >>>>> please check attached one for nehalem-ioh. >>>> >>>> I don't think it's a requirement that Gerry keep your Nehalem patch >>>> working. Your intel_bus.c is not in the tree and you haven't provided >>>> an explanation for why it should be. >>>> >>>> The only requirement I'm aware of for PCI config access before we >>>> discover the host bridges via ACPI is for segment group 0, bus 0, as >>>> mentioned in ACPI spec 5.0, sec 5.2.3.1, PDF page 143, and I think >>>> that applies only to the first 0x100 bytes of config space. I don't >>>> think there's a requirement for access to the extended configuration >>>> space (bytes 0x100-0xFFF). I do not see a requirement that this >>>> pre-host bridge access happen via MMCONFIG; as far as I can tell, we >>>> can use the legacy 0xCF8/0xCFC mechanism. >>> >>> that one shot for intel host bridge resource discovery before root bus >>> scanning, >>> will need to access registers above 0x100. >> >> I don't understand what you're saying. Are you disagreeing with >> something I said above? >> >> As far as I know, we can rely on ACPI _CRS completely for host bridge >> resources. Are there exceptions? What does "one shot for intel host >> bridge resource discovery" mean? Are there machines that are broken >> because we don't have intel_bus.c? > > I have consulted Bob Moore about this topic before and Bob said that > they hasn't encountered a system on which the ACPICA has dependency > on extended PCI configuration space yet. > >>> Current MCFG handling have some sanitary checking during probing. >>> >>> Now Jiang is trying to free result and cache it for two MCFG path 2/3. >>> and later use cached and map again for entries from cached entries. >>> but when use those cached entries sanitary of those entries are lost. >>> >>> so choice would be >>> 1. cache all checked MMCFG result and use that later >>> 2. or just leave current MCFG handling alone, just add _CBA support. >>> like Jiang -v4 version. >> >> Choice 2 sounds like a possibility. I probably encouraged mucking >> around in the current MCFG handling, but if we're not going to >> actually clean anything up, there's not much point in touching it. > I prefer the second choice too. Backward compatibility is really > important on x86, so don't want to break anything here. I could > help to split the patch set into two parts: one for root bridge > hotplug and the other for cleanup. This time we could focus on > the first patch to prepare for host bridge hotplug, and have > more time to discuss about the cleanup work. > > On the other hand, BIOS should report MMCONFIG information by _CBA > if a host bridge supports physical hotplug. So the cleanup only > benefits two cases: > 1) BIOS reports MMCONFIG information for hot-pluggable host bridges > in MCFG table. This is really a BIOS bug. Currently we have no > really x86 platforms in the field which support PCI host bridge > hotplug yet. So it may be acceptable for OS to report such bugs > and let BIOS people to fix them. > 2) Account MMCONFIG information to specific host bridges. It does > give better representation about the MMCONFIG resource usages, > but it's on risk of breaking backward compatibilities. > > So should we adopt the second solution here? Yes, let's try that. I'm sorry I encouraged you to go on a wild goose chase. -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/x86/include/asm/pci_x86.h b/arch/x86/include/asm/pci_x86.h index 7eae174..5eb2ac9 100644 --- a/arch/x86/include/asm/pci_x86.h +++ b/arch/x86/include/asm/pci_x86.h @@ -142,7 +142,7 @@ extern int __devinit pci_mmconfig_insert(struct device *dev, u16 seg, u8 start, u8 end, phys_addr_t addr); extern int pci_mmconfig_delete(u16 seg, u8 start, u8 end); -#ifdef CONFIG_ACPI +#if defined(CONFIG_ACPI) && defined(CONFIG_PCI_MMCONFIG) extern void pci_mmconfig_probe(u8 start); #else static inline void pci_mmconfig_probe(u8 start) { } diff --git a/arch/x86/pci/mmconfig-shared.c b/arch/x86/pci/mmconfig-shared.c index 20ab4f5..636de35 100644 --- a/arch/x86/pci/mmconfig-shared.c +++ b/arch/x86/pci/mmconfig-shared.c @@ -636,13 +636,6 @@ static int __init pci_parse_mcfg(struct acpi_table_header *header) } } - i = entries * sizeof(*cfg_table); - pci_acpi_mcfg_array = kmalloc(i, GFP_KERNEL); - if (pci_acpi_mcfg_array) { - memcpy(pci_acpi_mcfg_array, cfg_table, i); - pci_acpi_mcfg_entries = entries; - } - return 0; } @@ -699,8 +692,11 @@ out: * Free all MCFG entries if ACPI is enabled. MCFG information will * be added back on demand by the pci_root driver later. */ - if (!early && !acpi_disabled && !known_bridge && pci_acpi_mcfg_array) - free_all_mmcfg(); + if (!early && !acpi_disabled && !known_bridge && + !pci_mmcfg_arch_init_failed) { + if (!acpi_pci_cache_mcfg()) + free_all_mmcfg(); + } } void __init pci_mmcfg_early_init(void) diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c index f5d2157..93e0f91 100644 --- a/drivers/pci/pci-acpi.c +++ b/drivers/pci/pci-acpi.c @@ -163,8 +163,34 @@ acpi_status pci_acpi_remove_pm_notifier(struct acpi_device *dev) } /* acpi_table_parse() is marked as __init, so cache MCFG info at boot time */ -int pci_acpi_mcfg_entries; -struct acpi_mcfg_allocation *pci_acpi_mcfg_array; +static int pci_acpi_mcfg_entries; +static struct acpi_mcfg_allocation *pci_acpi_mcfg_array; + +static int __init pci_cache_mcfg(struct acpi_table_header *header) +{ + u32 sz; + void *ptr; + + if (!header || (header->length <= sizeof(struct acpi_table_mcfg))) + return -EINVAL; + + sz = (header->length - sizeof(struct acpi_table_mcfg)); + pci_acpi_mcfg_array = kmalloc(sz, GFP_KERNEL); + if (!pci_acpi_mcfg_array) + return -ENOMEM; + + ptr = (void *)header + sizeof(struct acpi_table_mcfg); + memcpy(pci_acpi_mcfg_array, ptr, sz); + pci_acpi_mcfg_entries = sz / sizeof (struct acpi_mcfg_allocation); + + return 0; +} + +int __init acpi_pci_cache_mcfg(void) +{ + acpi_table_parse(ACPI_SIG_MCFG, pci_cache_mcfg); + return pci_acpi_mcfg_array ? 0 : -EINVAL; +} phys_addr_t acpi_pci_root_get_mcfg_addr(acpi_handle handle, u16 seg, u8 start, int *endp) diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h index 946789f..e03207c 100644 --- a/include/linux/pci-acpi.h +++ b/include/linux/pci-acpi.h @@ -11,15 +11,13 @@ #include <linux/acpi.h> #ifdef CONFIG_ACPI -extern int pci_acpi_mcfg_entries; -extern struct acpi_mcfg_allocation *pci_acpi_mcfg_array; - extern acpi_status pci_acpi_add_bus_pm_notifier(struct acpi_device *dev, struct pci_bus *pci_bus); extern acpi_status pci_acpi_remove_bus_pm_notifier(struct acpi_device *dev); extern acpi_status pci_acpi_add_pm_notifier(struct acpi_device *dev, struct pci_dev *pci_dev); extern acpi_status pci_acpi_remove_pm_notifier(struct acpi_device *dev); +extern int acpi_pci_cache_mcfg(void); extern phys_addr_t acpi_pci_root_get_mcfg_addr(acpi_handle handle, u16 seg, u8 start, int *endp); @@ -40,6 +38,8 @@ static inline acpi_handle acpi_pci_get_bridge_handle(struct pci_bus *pbus) return acpi_get_pci_rootbridge_handle(pci_domain_nr(pbus), pbus->number); } +#else +static inline int acpi_pci_cache_mcfg(void) { return -EINVAL; } #endif #ifdef CONFIG_ACPI_APEI