Re: [PATCH] x86/pci: derive pcibios_last_bus from ACPI MCFG

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, May 21, 2011 at 10:01 AM, Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx> wrote:
> On Wed, 23 Feb 2011 10:08:10 +0000
> "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:
>
>> On various newer Intel systems the PCI bus(ses) the non-core devices
>> live on aren't getting announced by ACPI except through the bus range
>> covered by mmconfig. At least the i7core-edac driver depends on these
>> devices getting detected.
>>
>> Mauro, could you check whether with this change the Xeon 55xx hack in
>> that driver can go away altogether, and with it the bogus exporting of
>> pcibios_scan_specific_bus()?
>>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
>> Cc: Mauro Carvalho Chehab <mchehab@xxxxxxxxxx>
>> Cc: Aristeu Sergio <arozansk@xxxxxxxxxx>
>>
>> ---
>>  arch/x86/pci/mmconfig-shared.c |   10 ++++++++++
>>  1 file changed, 10 insertions(+)
>>
>> --- 2.6.38-rc6/arch/x86/pci/mmconfig-shared.c
>> +++ 2.6.38-rc6-x86-mmconfig-last-bus/arch/x86/pci/mmconfig-shared.c
>> @@ -606,6 +606,16 @@ static void __init __pci_mmcfg_init(int
>>       if (list_empty(&pci_mmcfg_list))
>>               return;
>>
>> +     if (pcibios_last_bus < 0) {
>> +             const struct pci_mmcfg_region *cfg;
>> +
>> +             list_for_each_entry(cfg, &pci_mmcfg_list, list) {
>> +                     if (cfg->segment)
>> +                             break;
>> +                     pcibios_last_bus = cfg->end_bus;
>> +             }
>> +     }
>> +
>>       if (pci_mmcfg_arch_init())
>>               pci_probe = (pci_probe & ~PCI_PROBE_MASK) |
>> PCI_PROBE_MMCONF; else {
>
> I never got the info I was looking for internally; we'll give this a
> try this cycle and see how well it works.

I want to reiterate that I think this is a gross hack, since we have a
clearly architected PCI discovery mechanism, and this is subverting
it.  If we have to do it, I think we should at least put a clear
warning in dmesg.  The "PCI: Discovered peer bus" message doesn't
count.  It's likely the BIOS hid these devices for its own reasons,
and the user deserves to know that we're doing something that's
unintended and unsupported by the OEM.

I would even go so far as to consider whether we should just leave
EDAC disabled on machines that don't properly expose the devices, or
possibly require a command-line switch to enable it.  If EDAC is truly
valuable, OEMs will be motivated to fix the BIOS to make it work
correctly.

I think we have the potential for hard-to-reproduce, hard-to-debug
unpleasant interactions between the BIOS and the OS when we do this.

Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux