lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABhMZUWDngY6jL8jkxQ+SHzEHqTS4i3DqtCD7DUBtL4QS58ovA@mail.gmail.com>
Date:	Tue, 6 Mar 2012 20:49:33 -0700
From:	Bjorn Helgaas <bjorn.helgaas@...il.com>
To:	Yinghai Lu <yinghai@...nel.org>
Cc:	Bjorn Helgaas <bhelgaas@...gle.com>,
	Jesse Barnes <jbarnes@...tuousgeek.org>, x86 <x86@...nel.org>,
	linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 23/23] x86, PCI: add pcibios_root_rescan

[Sorry, gmail made this HTML, so LKML rejected it.  Sigh.  Please
respond to this one, not the HTML one.]

On Tue, Mar 6, 2012 at 5:09 PM, Yinghai Lu <yinghai@...nel.org> wrote:
> On Tue, Mar 6, 2012 at 3:13 PM, Bjorn Helgaas <bhelgaas@...gle.com> wrote:
>> On Tue, Mar 6, 2012 at 12:14 AM, Yinghai Lu <yinghai@...nel.org> wrote:
>>> need use it to rescan root bus that was not added via acpi probe.
>>>
>>> Signed-off-by: Yinghai Lu <yinghai@...nel.org>
>>> ---
>>>  arch/x86/pci/legacy.c |   25 +++++++++++++++++++++++++
>>>  1 files changed, 25 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/arch/x86/pci/legacy.c b/arch/x86/pci/legacy.c
>>> index aab0e41..7a7c78f 100644
>>> --- a/arch/x86/pci/legacy.c
>>> +++ b/arch/x86/pci/legacy.c
>>> @@ -79,3 +79,28 @@ int __init pci_subsys_init(void)
>>>        return 0;
>>>  }
>>>  subsys_initcall(pci_subsys_init);
>>> +
>>> +void __devinit pcibios_root_rescan(void)
>>> +{
>>> +       int busn;
>>> +       struct pci_bus *bus;
>>> +
>>> +       if (pcibios_last_bus <= 0 || pcibios_last_bus > 0xff)
>>> +               return;
>>> +
>>> +       for (busn = 0; busn <= pcibios_last_bus; busn++) {
>>> +               bus = pci_find_bus(0, busn);
>>> +
>>> +               if (bus)
>>> +                       continue;
>>> +
>>> +               bus = __pcibios_scan_specific_bus(busn, false);
>>> +
>>> +               if (!bus)
>>> +                       continue;
>>> +
>>> +               pci_assign_unassigned_bus_resources(bus);
>>> +
>>> +               pci_bus_add_devices(bus);
>>> +       }
>>> +}
>>
>> Do we need it?  I assume we only care about host bridge hotplug via ACPI on x86.
>
> my sandbridge system has cpu bus 0x7f, and 0xff in DSDT.
>
> but nehalem and westmere system does not have cpu bus 0xf8, ... 0xff.

I think you're saying that on some machines, the BIOS decided not to
expose host bridges leading to CPU devices, and you want to discover
those devices anyway.  (What's the reason you want to discover them?)

I guess that's OK for now, but I don't like this strategy in general.
The expectation of BIOS writers is that the OS will discover things
using the ACPI namespace and not go grubbing around outside that.
Sometimes the BIOS has good reasons to hide things from the OS, e.g.,
to keep the OS from tripping over hardware defects, to reduce support
calls by preventing users from making dangerous changes, etc.

Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ