linux-kernel - Re: [PATCH 2/2][RESEND] x86/pci/amd: Enable early_fill_mp_bus_to

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: <20120504132549.GD12199@alberich.amd.com>
Date:	Fri, 4 May 2012 15:25:49 +0200
From:	Andreas Herrmann <andreas.herrmann3@....com>
To:	Bjorn Helgaas <bhelgaas@...gle.com>
CC:	<linux-kernel@...r.kernel.org>, <linux-pci@...r.kernel.org>,
	Ingo Molnar <mingo@...nel.org>
Subject: Re: [PATCH 2/2][RESEND] x86/pci/amd: Enable
 early_fill_mp_bus_to_node on AMD family 15h models 0-0xf

On Wed, May 02, 2012 at 11:34:15AM -0600, Bjorn Helgaas wrote:
> On Fri, Apr 27, 2012 at 8:37 AM, Andreas Herrmann
> <andreas.herrmann3@....com> wrote:
> >
> > While at it avoid calling this function on family 11h (aka Griffin)
> > which was a mobile part and doesn't support NUMA.
> 
> This changelog doesn't seem like it goes with this patch.  It looks
> more related to the first patch (though that affects family 11h and
> greater, not just family 11h).

So maybe I should repeat the contents of the subject line in the
changelog.

The first patch restores the function to set the NUMA node info for
busses. Linux behaviour shouldn't change after the first patch at all.

This (the second) patch will enable node detection for AMD CPU family
15h model 00-0fh (with 0x1600 as device id for NB function 0). (see
subject line) In addition it removes the NB id for CPU family 11h from
this code.  That CPU was used only in Laptops (single socket). A
mapping of bus to node is not required there. And also figuring out
MMIO and I/O port apertures while ignoring _CRS shouldn't be a use
case for such systems.

I think Device ID 0x1300 was added with commit
35ddd068fb94b187e94a3fc497ccecf27bdda9ae (x86: use bus conf in NB conf
fun1 to get bus range on, on 64-bit)

But unfortunately the changelog of this patch doesn't mention why this
is strictly req'd.


HTH,

Andreas

> >  arch/x86/pci/amd_bus.c |    2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/arch/x86/pci/amd_bus.c b/arch/x86/pci/amd_bus.c
> > index 0384e69..d552b29 100644
> > --- a/arch/x86/pci/amd_bus.c
> > +++ b/arch/x86/pci/amd_bus.c
> > @@ -27,7 +27,7 @@ static struct pci_hostbridge_probe pci_probes[] __initdata = {
> >        { 0, 0x18, PCI_VENDOR_ID_AMD, 0x1100 },
> >        { 0, 0x18, PCI_VENDOR_ID_AMD, 0x1200 },
> >        { 0xff, 0, PCI_VENDOR_ID_AMD, 0x1200 },
> > -       { 0, 0x18, PCI_VENDOR_ID_AMD, 0x1300 },
> > +       { 0, 0x18, PCI_VENDOR_ID_AMD, 0x1600 },
> >  };
> >
> >  /**
> > --
> > 1.7.8.5
> >
> >
> >
> 


--
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/