From: Suravee Suthikulanit <suravee.suthikulpanit@amd.com>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Aravind Gopalakrishnan <aravind.gopalakrishnan@amd.com>,
kim.naru@amd.com,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>
Subject: Re: [PATCH 0/3] amd/pci: Add AMD hostbridge supports for newer AMD systems
Date: Wed, 5 Mar 2014 20:13:04 -0600 [thread overview]
Message-ID: <5317D9B0.1080502@amd.com> (raw)
In-Reply-To: <CAErSpo4MMJh9b0aivwGSbxCMVw24He1+Vo_LH0R0E+fYM5aThg@mail.gmail.com>
On 3/5/2014 3:24 PM, Bjorn Helgaas wrote:
> [+cc linux-acpi]
>
> On Wed, Mar 5, 2014 at 2:06 PM, <suravee.suthikulpanit@amd.com> wrote:
>> From: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
>>
>> The current code only supports upto AMD hostbridge for family11h.
>> This causes PCI numa_node information to be reported incorrectly
>> for newer family with multi sockets.
>
> Where is the incorrect reporting? In ACPI tables? Is this patch a
> way to cover up firmware defects in the ACPI description? Or is this
> for machines without ACPI (it seems unlikely that machines with new
> AMD processors would not have ACPI)?
This is incorrectly reported in the sysfs for each PCI device (e.g.
/devices/pci0000:50/0000:50:00.2/numa_node). Without the patch, they
return -1.
In file arch/x86/pci/acpi.c, in function pci_acpi_scan_root(), it is
queries the node information as following:
#ifdef CONFIG_ACPI_NUMA
pxm = acpi_get_pxm(device->handle);
if (pxm >= 0)
node = pxm_to_node(pxm);
if (node != -1)
set_mp_bus_to_node(busnum, node);
else
#endif
node = get_mp_bus_to_node(busnum);
In this case, I see that the acpi_get_pxm() returns -1. Therefore, it
falls back to using the node information in mp_bus_to_node[]. So,
without this patch, it would also returning -1.
Also, the spec mentioned that the _PXM is optional, so I am not sure if
this is a firmware bug.
Suravee
>
> The whole point of ACPI is that we shouldn't need to update the kernel
> for new hardware, so if there's a firmware bug, it should be fixed, or
> if the ACPI spec isn't powerful enough, it should be extended.
>
>> This patch set introduces the logic to discover AMD hostbridges.
>>
>> Note:
>> * Patch 1 and 2 are functional changes.
>> * Patch 3 is code clean up/restructuring
>>
>> Suravee Suthikulpanit (3):
>> amd/pci: Add supports for generic AMD hostbridges
>> amd/pci: Support additional MMIO ranges capabilities
>> amd/pci: Miscellaneous code clean up for early_fillup_mp_bus_info
>>
>> arch/x86/pci/amd_bus.c | 376 ++++++++++++++++++++++++++++++++----------------
>> 1 file changed, 251 insertions(+), 125 deletions(-)
>>
>> --
>> 1.7.10.4
>>
>>
>
WARNING: multiple messages have this Message-ID (diff)
From: Suravee Suthikulanit <suravee.suthikulpanit@amd.com>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Aravind Gopalakrishnan <aravind.gopalakrishnan@amd.com>,
<kim.naru@amd.com>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>
Subject: Re: [PATCH 0/3] amd/pci: Add AMD hostbridge supports for newer AMD systems
Date: Wed, 5 Mar 2014 20:13:04 -0600 [thread overview]
Message-ID: <5317D9B0.1080502@amd.com> (raw)
In-Reply-To: <CAErSpo4MMJh9b0aivwGSbxCMVw24He1+Vo_LH0R0E+fYM5aThg@mail.gmail.com>
On 3/5/2014 3:24 PM, Bjorn Helgaas wrote:
> [+cc linux-acpi]
>
> On Wed, Mar 5, 2014 at 2:06 PM, <suravee.suthikulpanit@amd.com> wrote:
>> From: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
>>
>> The current code only supports upto AMD hostbridge for family11h.
>> This causes PCI numa_node information to be reported incorrectly
>> for newer family with multi sockets.
>
> Where is the incorrect reporting? In ACPI tables? Is this patch a
> way to cover up firmware defects in the ACPI description? Or is this
> for machines without ACPI (it seems unlikely that machines with new
> AMD processors would not have ACPI)?
This is incorrectly reported in the sysfs for each PCI device (e.g.
/devices/pci0000:50/0000:50:00.2/numa_node). Without the patch, they
return -1.
In file arch/x86/pci/acpi.c, in function pci_acpi_scan_root(), it is
queries the node information as following:
#ifdef CONFIG_ACPI_NUMA
pxm = acpi_get_pxm(device->handle);
if (pxm >= 0)
node = pxm_to_node(pxm);
if (node != -1)
set_mp_bus_to_node(busnum, node);
else
#endif
node = get_mp_bus_to_node(busnum);
In this case, I see that the acpi_get_pxm() returns -1. Therefore, it
falls back to using the node information in mp_bus_to_node[]. So,
without this patch, it would also returning -1.
Also, the spec mentioned that the _PXM is optional, so I am not sure if
this is a firmware bug.
Suravee
>
> The whole point of ACPI is that we shouldn't need to update the kernel
> for new hardware, so if there's a firmware bug, it should be fixed, or
> if the ACPI spec isn't powerful enough, it should be extended.
>
>> This patch set introduces the logic to discover AMD hostbridges.
>>
>> Note:
>> * Patch 1 and 2 are functional changes.
>> * Patch 3 is code clean up/restructuring
>>
>> Suravee Suthikulpanit (3):
>> amd/pci: Add supports for generic AMD hostbridges
>> amd/pci: Support additional MMIO ranges capabilities
>> amd/pci: Miscellaneous code clean up for early_fillup_mp_bus_info
>>
>> arch/x86/pci/amd_bus.c | 376 ++++++++++++++++++++++++++++++++----------------
>> 1 file changed, 251 insertions(+), 125 deletions(-)
>>
>> --
>> 1.7.10.4
>>
>>
>
next prev parent reply other threads:[~2014-03-06 2:13 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-05 21:06 [PATCH 0/3] amd/pci: Add AMD hostbridge supports for newer AMD systems suravee.suthikulpanit
2014-03-05 21:06 ` [PATCH 1/3] amd/pci: Add supports for generic AMD hostbridges suravee.suthikulpanit
2014-03-05 21:06 ` [PATCH 2/3] amd/pci: Support additional MMIO ranges capabilities suravee.suthikulpanit
2014-03-20 17:33 ` Bjorn Helgaas
2014-03-05 21:06 ` [PATCH 3/3] amd/pci: Miscellaneous code clean up for early_fillup_mp_bus_info suravee.suthikulpanit
2014-03-05 21:24 ` [PATCH 0/3] amd/pci: Add AMD hostbridge supports for newer AMD systems Bjorn Helgaas
2014-03-06 2:13 ` Suravee Suthikulanit [this message]
2014-03-06 2:13 ` Suravee Suthikulanit
2014-03-06 6:30 ` Suravee Suthikulpanit
2014-03-06 6:30 ` Suravee Suthikulpanit
2014-03-06 17:40 ` Bjorn Helgaas
2014-03-06 20:03 ` Suravee Suthikulpanit
2014-03-06 20:03 ` Suravee Suthikulpanit
2014-03-11 18:12 ` Bjorn Helgaas
2014-03-12 21:13 ` Bjorn Helgaas
2014-03-13 1:30 ` Myron Stowe
2014-03-14 2:06 ` Suravee Suthikulpanit
2014-03-14 2:06 ` Suravee Suthikulpanit
2014-03-17 17:18 ` Bjorn Helgaas
2014-03-20 17:42 ` Bjorn Helgaas
2014-04-19 2:53 ` [PATCH v2 0/5] x86/PCI: Add AMD hostbridge support " Myron Stowe
2014-04-19 2:53 ` [PATCH v2 1/5] x86/PCI: Add support for generic AMD hostbridges Myron Stowe
2014-04-19 11:31 ` Borislav Petkov
2014-04-28 21:10 ` Myron Stowe
2014-04-19 2:53 ` [PATCH v2 2/5] x86/PCI: Support additional MMIO range capabilities Myron Stowe
2014-04-19 13:52 ` Borislav Petkov
2014-04-20 7:59 ` Borislav Petkov
2014-04-25 22:24 ` Myron Stowe
2014-04-26 9:10 ` Borislav Petkov
2014-04-28 20:50 ` Bjorn Helgaas
2014-04-28 21:40 ` Borislav Petkov
2014-04-28 21:40 ` Borislav Petkov
2014-04-29 7:33 ` Andreas Herrmann
2014-04-29 10:20 ` Borislav Petkov
2014-04-29 13:07 ` Steffen Persvold
2014-04-29 15:16 ` Suravee Suthikulanit
2014-04-29 15:16 ` Suravee Suthikulanit
2014-04-29 19:14 ` Borislav Petkov
2014-04-29 21:40 ` Myron Stowe
2014-04-30 7:00 ` Robert Richter
2014-04-30 7:50 ` Suravee Suthikulpanit
2014-04-30 7:50 ` Suravee Suthikulpanit
2014-04-30 9:51 ` Robert Richter
2014-04-30 23:03 ` Myron Stowe
2014-04-29 11:19 ` Robert Richter
2014-04-29 7:06 ` Jan Beulich
2014-04-29 7:06 ` Jan Beulich
2014-04-29 3:04 ` Suravee Suthikulanit
2014-04-29 3:04 ` Suravee Suthikulanit
2014-04-28 21:19 ` Myron Stowe
2014-04-29 2:47 ` Suravee Suthikulanit
2014-04-29 2:47 ` Suravee Suthikulanit
2014-04-29 17:17 ` Robert Richter
2014-04-30 6:41 ` Robert Richter
2014-04-19 2:53 ` [PATCH v2 3/5] x86/PCI: Miscellaneous code clean up for early_fillup_mp_bus_info Myron Stowe
2014-04-20 8:02 ` Borislav Petkov
2014-04-28 21:21 ` Myron Stowe
2014-04-19 2:53 ` [PATCH v2 4/5] ACPI/PCI: Warn if we have to "guess" host bridge node information Myron Stowe
2014-04-20 10:21 ` Borislav Petkov
2014-04-28 21:24 ` Myron Stowe
2014-04-29 19:16 ` Borislav Petkov
2014-04-19 2:53 ` [PATCH v2 5/5] PCI: Remove redundant 'quirk_amd_nb_node' Myron Stowe
2014-04-20 10:54 ` Borislav Petkov
2014-04-20 13:44 ` Myron Stowe
2014-04-21 16:53 ` Daniel J Blueman
2014-04-29 2:02 ` Suravee Suthikulanit
2014-04-29 2:02 ` Suravee Suthikulanit
2014-04-29 19:29 ` Bjorn Helgaas
2014-04-28 21:28 ` Myron Stowe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5317D9B0.1080502@amd.com \
--to=suravee.suthikulpanit@amd.com \
--cc=aravind.gopalakrishnan@amd.com \
--cc=bhelgaas@google.com \
--cc=kim.naru@amd.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.